Method for automatically generating dependencies between visual blocks in a low-code development platform
By automatically generating dependencies between visual blocks in the low-code development platform and using multi-tree data structures to define dependency rules, the complexity of dependency relationships between controls is solved, and development efficiency and error detection capabilities are improved.
Patent Information
- Application Number
- CN202210210629.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-03-03
- Publication Date
- 2025-10-17
- Estimated Expiration
- 2042-03-03
AI Technical Summary
In low-code development platforms, the dependency relationships between controls are complex to handle, resulting in a heavy cognitive burden on users. As the complexity of automated applications increases, dependency selection becomes difficult, and traditional methods cannot effectively manage the dependencies between controls.
By automatically generating visual dependencies between blocks in the low-code development platform, using multi-tree data structure to define dependency rules, and automatically processing dependencies between controls, including parent-child, sibling, and ancestor relationships, it supports common and array dependency types and provides dependency query and management functions.
It implements intelligent dependency management, improves development efficiency, reduces low-level errors, detects dependency loss issues in a timely manner, and reduces debugging time.
Smart Images
Figure CN114911469B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of robotic process automation technology, and in particular to a method for automatically generating dependencies between visual blocks in a low-code development platform. Background Art
[0002] With the application of LCDP in the RPA field, many users will use visualization to build automated processes. During process writing, one unavoidable issue is the use of dependencies between controls. The traditional solution is to not handle dependencies between controls, leaving full control to the user. This has its advantages, allowing users to configure dependencies more flexibly. However, it also brings the disadvantage of increasing the cognitive burden on users. As automated applications grow larger and more complex, this negative impact will become increasingly significant, and the selection of dependencies between controls will become increasingly difficult to handle. Summary of the Invention
[0003] In view of this, the present invention provides a method for automatically generating dependencies between visual blocks in a low-code development platform to solve the problems existing in the above-mentioned background technology.
[0004] A method for automatically generating dependencies between visual blocks in a low-code development platform, specifically comprising the following steps:
[0005] S1, automatically generates a multi-tree data structure with linked list properties based on the dependency rules defined between visual blocks in the low-code development platform;
[0006] S2, when it is necessary to query the dependent visualization blocks of the target visualization block, starting from the target visualization block, traverse the multi-tree data structure according to the dependency rule to find all its dependent visualization blocks;
[0007] S3, based on the type of dependency of the target visualization block, filter out visualization blocks with the same dependency type from all its dependent visualization blocks, and the filtered visualization blocks are the visualization blocks on which the target visualization block depends.
[0008] Preferably, if a certain visualization block in the multi-tree data structure needs to be deleted, the multi-tree data structure is traversed from the visualization block as the starting point to determine whether there are sibling blocks and descendant blocks that depend on the visualization block. If so, the visualization block and all sibling blocks and descendant blocks that depend on the visualization block are deleted.
[0009] Preferably, if a visualization block in a multi-tree data structure needs to be annotated, the multi-tree data structure is traversed from the annotated visualization block as a starting point, and visualization blocks that have a direct dependency relationship with the annotated visualization block are found from unannotated visualization blocks and the dependency relationship is deleted.
[0010] Preferably, if the type of a visual block changes, first determine whether the type change is narrowing or expanding, if the type expands, the original multi-tree data structure remains unchanged, if the type narrows, determine whether the original dependency relationship is established, if yes, continue to maintain the original dependency relationship, otherwise delete the original dependency relationship.
[0011] Preferably, if a visual block needs to be moved, before moving, take the to-be-moved visual block as the starting point, traverse the multi-tree data structure backward, find all visual blocks dependent on the to-be-moved visual block, after the to-be-moved visual block is moved, determine whether the dependency relationship between these visual blocks and the to-be-moved visual block is established, if yes, continue to maintain the original dependency relationship, otherwise delete the original dependency relationship.
[0012] Preferably, if a visual block needs to be copied and pasted, all visual blocks dependent on the to-be-copied visual block are copied together, and if there is a dependency between the copied new visual block and the original visual block in the cross-tree data structure, the dependency relationship is maintained.
[0013] Preferably, the dependency rules defined between the visual blocks in step S1 include dependency relationships between two visual blocks and a dependency scope,
[0014] When there is a dependency relationship between two visual blocks, the return value of one visual block can be referenced by the other visual block,
[0015] The dependency scope is used to limit the query direction of the dependency relationship, when querying the visual blocks dependent on the target visual block, the multi-tree data structure can only be traversed forward to the root node.
[0016] Preferably, the dependency relationship between two visual blocks includes parent-child relationship, sibling relationship and ancestor relationship.
[0017] Preferably, the type of visual block dependency includes normal dependency type and array dependency type.
[0018] Preferably, the visual block includes a normal visual block, a composite visual block and a limited visual block.
[0019] The beneficial effects of the present application are:
[0020] 1、The present application can output a return value for each visual block by establishing a dependency relationship between the visual blocks, and then make the visual blocks behind reference the variable, thereby connecting two visual blocks in series, combining to form a business logic with higher complexity, forming a logic closed loop with more practical practical significance, and automatically performing dependency matching, more intelligently assisting the developer to process dependency, thereby improving the efficiency of writing the process.
[0021] 2. When a dependency loss problem occurs, the present invention can prompt in time and also detect errors early, thus reducing low-level errors and shortening debugging time. BRIEF DESCRIPTION OF THE DRAWINGS
[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0023] Figure 1 is a schematic diagram of a common visualization block.
[0024] Figure 2 is a schematic diagram of a composite visualization block.
[0025] Figure 3 It is a schematic diagram that limits the visualization block.
[0026] Figure 4 This is a diagram of the dependency relationship between the [Launch Browser] visualization block and the [Open Web Page] visualization block.
[0027] Figure 5 This is a diagram of the dependency relationship between the [Launch Browser] visualization block and the [Open Web Page] visualization block.
[0028] Figure 6 It is a diagram of a tree structure of visualization blocks.
[0029] Figure 7 It is a schematic diagram of a multi-tree data structure with linked list properties.
[0030] Figure 8 It is a flow chart of the method of the present invention. DETAILED DESCRIPTION
[0031] In order to better understand the technical solution of the present invention, the embodiments of the present invention are described in detail below with reference to the accompanying drawings.
[0032] It should be understood that the embodiments described are only a portion of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.
[0033] The present application is further described in detail below through specific embodiments and in conjunction with the accompanying drawings.
[0034] The present invention provides a method for automatically generating dependencies between visual blocks in a low-code development platform, which specifically includes the following steps:
[0035] S1, automatically generating a multi-way tree data structure with a linked list property according to a dependency rule defined between visual blocks in a low-code development platform.
[0036] The visual block refers to the smallest unit in visual dragging formed by integrating a code segment with executable specific functions and its operation form.
[0037] When generating a visual block, first, the code segment with executable specific functions needs to be encapsulated; then, the operation form for changing the parameters of the code segment is provided; and then, the code segment and the operation form for changing the parameters are integrated to form the smallest unit in visual dragging.
[0038] Specifically, the visual block is divided into three types, namely, a normal visual block, a composite visual block, and a limited visual block.
[0039] The normal visual block is the most common visual block, and one block completes one specific function, for example,
start the browser and open the Excel document
[0040] The composite visual block refers to a visual block nested with other visual blocks, which has the ability to nest other visual blocks, for example,
conditional judgment, loop traversal
[0041] The limited visual block is a visual block that can only be used in a specific composite visual block, for example,
continue the loop, jump out of the loop
continue the loop, jump out of the loop
[0042] Due to the existence of the composite visual block, there is a basis for mutual nesting between visual blocks, and therefore, the dependency relationship between visual blocks can be established according to the defined dependency rule.
[0043] The dependency rule defined between the visual blocks includes the dependency relationship between each two visual blocks and the scope of the dependency.
[0044] The dependency relationship between each two visual blocks includes the parent-child relationship, the sibling relationship, and the ancestor relationship.
[0045] When there is a dependency between two visualization blocks, the return value of one visualization block can be referenced by the other visualization block, for example: the return value of the
start browser
open webpage
start browser
open webpage
open webpage
start browser
[0046] Each visualization block can be regarded as a Block, and the data structure of a certain visualization block can be simplified as follows:
[0047]
[0048] Wherein, return represents the return value of the visualization block, and the return value can be referenced by another control. The return value can be empty, indicating that the visualization block has no return value, for example: the
print log
[0049] fields represent a set of attribute values in the visualization block, and the item in the set can reference the return value of another visualization block, thereby establishing a dependency between two visualization blocks.
[0050] The dependency rules defined between the visualization blocks not only define the dependency between two visualization blocks, but also define the scope of the dependency.
[0051] The scope of the dependency is used to limit the query direction of the dependency relationship, and when querying the visualization block depended by the target visualization block, the multi-way tree data structure can only be traversed in the direction of the root node. For example, the
start browser
open webpage
open webpage
start browser
start browser
[0052] In this embodiment, the type of dependency of each visualization block is also defined, and the type of dependency of the visualization block includes a normal dependency type and an array dependency type.
[0053] The normal dependency type includes:
[0054] Boolean (Boolean)
[0055] String (string)
[0056] Int (integer)
[0057] • Float (float)
[0058] • Date (date)
[0059] • Browser (browser)
[0060] • WebPage (webpage)
[0061] • Excel (excel)
[0062] • Word (word)
[0063] • PDF (pdf)
[0064] For example, the value returned by the
Launch Browser
Open Webpage
[0065] In addition to the normal dependency types listed above, there is a very special dependency type - Any. Any can represent any type, and if a visual block returns a value of this type, it means that it can be depended on by any other visual block in the scope. If a visual block's property needs a dependency of type Any, it means that it can depend on the value of any visual block in the scope. In other words, Any is a superset of all other types.
[0066] The normal dependency types listed above also have some array variants. These array dependency types are:
[0067] • Array>Boolean (boolean array)
[0068] • Array>String (string array)
[0069] • Array>Int (integer array)
[0070] • Array>Float (float array)
[0071] • Array>Date (date array)
[0072] • Array>Any (any value array)
[0073] For array dependency types, Array>Any is a superset of all other array dependency types, and Any is a superset of Array>Any and all other array dependency types.
[0074] The dependency rule defined above can automatically generate the multi-way tree data structure of the visualization block with the linked list property.
[0075] S2, when the dependent visualization blocks of the target visualization block need to be queried, the target visualization block is taken as the starting point, the multi-way tree data structure is traversed according to the dependency rule, and all dependent visualization blocks of the target visualization block are found.
[0076] S3, according to the type of the target visualization block, the dependent visualization blocks of the target visualization block are filtered from all the dependent visualization blocks of the target visualization block, and the filtered visualization blocks are the dependent visualization blocks of the target visualization block.
[0077] When the tree structure of the visualization block changes, the dependency relationship between the visualization blocks also changes accordingly.
[0078] For example, if a visualization block in the multi-way tree data structure needs to be deleted, the visualization block is taken as the starting point, and the multi-way tree data structure is traversed backward to determine whether there are sibling blocks and descendant blocks dependent on the visualization block. If there are, the visualization block and all the sibling blocks and descendant blocks dependent on the visualization block are deleted.
[0079] If the deleted visualization block is a composite visualization block, the descendant blocks of the deleted visualization block do not need to be detected, because when the composite visualization block is deleted, the child blocks of the composite visualization block are also deleted.
[0080] As shown in the tree structure in Figure 6 If the visualization block b2 needs to be deleted, it is detected that the visualization block b2 has the sibling block b3 and the child block c1, but the sibling block b3 does not depend on the visualization block b2, and only the child block c1 depends on the visualization block b2. Therefore, when the visualization block b2 is deleted, the child block c1 also needs to be deleted, and when the child block c1 is deleted, the child blocks of the child block c1 are also deleted.
[0081] The time complexity here depends on the number of visualization blocks to be detected, and the worst case is to detect all the visualization blocks, and the time complexity is O(n), where n is the number of visualization blocks.
[0082] If a visualization block in the multi-way tree data structure needs to be annotated, the visualization block to be annotated is taken as the starting point, the multi-way tree data structure is traversed backward, and the visualization blocks directly dependent on the visualization block to be annotated are found from the unannotated visualization blocks and the dependency relationship is deleted.
[0083] If multiple visualization blocks are annotated, and there is a dependency relationship between the multiple visualization blocks, the dependency relationship between the multiple visualization blocks remains valid after the annotation.
[0084] As shown in the tree structure in Figure 6If the visualization block b2 is annotated, the dependency relationship between the unannotated visualization block c1 and the visualization block b2 is detected by traversing the multi-tree data structure from the visualization block b2 as a starting point, and the visualization block c1 and the dependency relationship thereof need to be deleted.
[0085] If the visualization blocks b2 and b3 are both annotated, the dependency relationship between the unannotated visualization block c1 and the visualization block b2 and the dependency relationship between the unannotated visualization block c2 and the visualization block b3 are detected by traversing the multi-tree data structure from the visualization blocks b2 and b3 as starting points, respectively, and the visualization blocks c1 and c2 and the dependency relationship thereof need to be deleted.
[0086] If the visualization blocks b2 and b3 are both annotated and there is a dependency relationship between the visualization blocks b2 and b3 (which does not exist in the example shown), the dependency relationship between the visualization blocks b2 and b3 still exists after the visualization blocks b2 and b3 are annotated. Figure 6
[0087] If the type of a certain visualization block changes, it is first determined whether the type change is narrowing or expanding. If the type is expanded, the original multi-tree data structure remains unchanged. If the type is narrowed, it is determined whether the original dependency relationship is valid. If the original dependency relationship is valid, the original dependency relationship is maintained. Otherwise, the original dependency relationship is deleted.
[0088] For example, if the type of the visualization block c1 in Figure 6 is changed from Browser to Any, the type is expanded, and since the properties dependent on the Browser type are also dependent on the Any type, no monitoring operation is needed, and the dependency relationship between the visualization block c1 and the visualization block b2 still exists. Similarly, if the type of Array>Float is changed to Array>Any, no monitoring operation is needed, and the original dependency relationship still exists. If the type is narrowed, it is determined whether the original dependency relationship is valid. If the original dependency relationship is valid, the original dependency relationship is maintained. Otherwise, the original dependency relationship is deleted.
[0089] If a certain visualization block needs to be moved, the multi-tree data structure is traversed from the visualization block to be moved as a starting point, and all visualization blocks dependent on the visualization block to be moved are found. After the visualization block to be moved is moved, it is determined whether the dependency relationship between these visualization blocks and the visualization block to be moved is valid. If the dependency relationship is valid, the original dependency relationship is maintained. Otherwise, the original dependency relationship is deleted.
[0090] If a certain visualization block needs to be copied and pasted, all visualization blocks dependent on the visualization block to be copied are also copied. If there is a dependency relationship between the new visualization block copied and an original visualization block in the multi-tree data structure, the dependency relationship is maintained.
[0091] When copying and pasting a visualization block, since there can be multiple visualization blocks pasted at the same time, the dependencies within the pasted visualization can continue to exist, which is somewhat similar to the scenario when annotating a visualization block. The specific operation logic is as follows:
[0092] 1. The dependencies within the copied visualization block continue to exist in the corresponding dependencies of the new visualization block 2. The dependencies outside the copied visualization block, if the dependencies continue to exist, are not changed 3. The dependencies outside the copied visualization block, if the dependencies no longer exist, the corresponding dependency value is set to an empty string.
[0093] As shown in the tree structure Figure 6 If only visualization block c1 needs to be copied, visualization blocks d1 and d2 that depend on visualization block c1 are also copied, and it is determined whether the dependencies between the copied new visualization block c1' and visualization block b2 continue to exist. If the dependencies exist, the dependency relationship between the visualization block c1' and the visualization block b2 is not changed, and if the dependencies do not exist, the dependency value is set to an empty string.
[0094] The above only describes the preferred embodiments of the present application and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.
Claims
1. A method for automatically generating dependencies between visual blocks in a low-code development platform, characterized in that: The specific steps include: S1, automatically generates a multi-tree data structure with linked list properties based on the dependency rules defined between visual blocks in the low-code development platform; The dependency rules defined between the visualization blocks include the dependency relationship between two visualization blocks, the dependency scope, and the dependency type of each visualization block. Each visualization block in the multitree data structure can output a return value. The return value of a visualization block can be referenced by the visualization block behind it, thus connecting the two in series. The dependency scope is used to limit the query direction of the dependency relationship. When querying the visualization blocks that the target visualization block depends on, the multitree data structure can only be traversed forward in the direction of the root node. S2, when it is necessary to query the dependent visualization blocks of the target visualization block, starting from the target visualization block, traverse the multi-tree data structure according to the dependency rule to find all its dependent visualization blocks; S3, based on the type of dependency of the target visualization block, filter out visualization blocks with the same dependency type from all its dependent visualization blocks, and the filtered visualization blocks are the visualization blocks on which the target visualization block depends.
2. The method for automatically generating dependencies between visual blocks in a low-code development platform according to claim 1 is characterized in that: If a visual block in the multi-tree data structure needs to be deleted, the multi-tree data structure is traversed from the visual block as the starting point to determine whether there are sibling blocks and descendant blocks that depend on the visual block. If so, the visual block and all sibling blocks and descendant blocks that depend on the visual block are deleted.
3. The method for automatically generating dependencies between visual blocks in a low-code development platform according to claim 1 is characterized in that: If a visual block in a multi-tree data structure needs to be annotated, the multi-tree data structure is traversed from the annotated visual block as a starting point, and visual blocks that have a direct dependency relationship with the annotated visual block are found from unannotated visual blocks, and the dependency relationship is deleted.
4. The method for automatically generating dependencies between visual blocks in a low-code development platform according to claim 1 is characterized in that: If the type of a visualization block dependency changes, first determine whether the type change is narrowing or expanding. If the type is expanding, the original multi-tree data structure remains unchanged; if the type is narrowing, determine whether its original dependency relationship is established. If so, continue to maintain the original dependency relationship; otherwise, delete the original dependency relationship.
5. The method for automatically generating dependencies between visual blocks in a low-code development platform according to claim 1 is characterized in that: If a visualization block needs to be moved, before the move, the multi-tree data structure is traversed backwards with the visualization block to be moved as the starting point to find all visualization blocks that depend on the visualization block to be moved. After the visualization block to be moved, it is determined whether the dependency relationship between these visualization blocks and the visualization block to be moved is established. If so, the original dependency relationship is maintained; otherwise, the original dependency relationship is deleted.
6. The method for automatically generating dependencies between visual blocks in a low-code development platform according to claim 1 is characterized in that: If a visualization block needs to be copied and pasted, all visualization blocks that depend on the visualization block to be copied are copied together, and if there is a dependency between the copied new visualization block and the original visualization block in the cross-tree data structure, the dependency relationship remains valid.
7. The method for automatically generating dependencies between visual blocks in a low-code development platform according to claim 1 is characterized in that: The dependency relationships between two visual blocks include parent-child relationship, sibling relationship, and ancestor relationship.
8. The method for automatically generating dependencies between visual blocks in a low-code development platform according to claim 1 is characterized in that: The types of visual block dependencies include common dependency types and array dependency types.
9. The method for automatically generating dependencies between visual blocks in a low-code development platform according to claim 1 is characterized in that: The visualization blocks include common visualization blocks, composite visualization blocks and limited visualization blocks.
Citation Information
Patent Citations
Code moving method based on complementary predicates
CN103617049A
Microservice application arrangement and deployment method and device and computer terminal
CN108762769A