Visual code operation debugging method and device

Abstract

The invention discloses a visual code operation debugging method and device. The method comprises the following steps: dynamically adding or deleting breakpoints in a code editing area in an integrated debugging environment, and automatically adjusting the positions of the breakpoints when codes are changed so as to keep logic consistency; and executing the code of the code editing area, highlighting and displaying the currently executed code line in the execution control area, dynamically indicating an execution path through a visual mark, and meanwhile, displaying the states of the local variable and the global variable in the variable monitoring area in real time. The technical problem that code debugging is complex in the prior art is solved.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular, to a method and device for visual code running and debugging. Background Art

[0002] Traditional debugging methods rely on breakpoint operations and manual printing of variables, making it difficult to intuitively understand the code execution process and the variable change rules. The present invention specifically proposes a visual debugging solution, which effectively reduces the cognitive load of learners by synchronously displaying the code execution trajectory, variable state changes, and graphical output effects. Based on the dual coding theory and the principle of cognitive load optimization, the system realizes three innovative functions: code-graph double-highlight linkage, intelligent variable tracking, and education-specific error diagnosis. Through actual measurement, it can increase the concept understanding speed by 45% and reduce the debugging time by 58%, significantly improving the learning efficiency and emotional motivation, and is particularly suitable for teaching scenarios of abstract programming concepts such as loops and recursions.

[0003] However, existing debugging technologies rely on breakpoints to split the execution process, and the variable states are presented fragmentarily; the code, variables, and output effects are displayed separately, forcing learners to switch between multiple windows frequently, with a heavy cognitive burden; in complex scenarios (such as recursions and multi-threads), variable tracking relies on artificial memory, and the dynamic changes are difficult to intuitively trace; the error prompts lack educational pertinence, cannot identify the typical logical misunderstandings of learners, and only provide technical error messages.

[0004] For the above problems, no effective solution has been proposed yet. Summary of the Invention

[0005] Embodiments of the present invention provide a method and device for visual code running and debugging to at least solve the technical problem of complex code debugging existing in the prior art.

[0006] According to one aspect of the embodiments of the present invention, a method for visual code running and debugging is provided, including: in an integrated debugging environment, dynamically adding or deleting breakpoints in a code editing area, and automatically adjusting the breakpoint positions when the code changes to maintain logical consistency; executing the code in the code editing area, highlighting the currently executed code line in an execution control area, and dynamically indicating the execution path through a visual marker. At the same time, the states of local variables and global variables are displayed in real time in the variable monitoring area.

[0007] According to another aspect of the embodiments of the present invention, there is also provided a visual code running and debugging device, including: a breakpoint management module configured to dynamically add or delete breakpoints in the code editing area in an integrated debugging environment, and automatically adjust the breakpoint positions to maintain logical consistency when the code changes; a code execution module configured to execute the code in the code editing area, highlight the currently executed code line in the execution control area, and dynamically indicate the execution path through visual markers. At the same time, the status of local variables and global variables is displayed in real time in the variable monitoring area.

[0008] In the embodiments of the present invention, visual code running and debugging is adopted. In an integrated debugging environment, breakpoints are dynamically added or deleted in the code editing area, and the breakpoint positions are automatically adjusted to maintain logical consistency when the code changes. The code in the code editing area is executed, the currently executed code line is highlighted in the execution control area, and the execution path is dynamically indicated through visual markers. At the same time, the status of local variables and global variables is displayed in real time in the variable monitoring area. Through the above solution, the technical problem of complex code debugging in the prior art is solved. Description of the Drawings

[0009] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation to the present invention. In the drawings:

[0010] Figure 1 is a flowchart of a visual code running and debugging method according to an embodiment of the present invention;

[0011] Figure 2 is a schematic structural diagram of a visual Python code running and debugging system according to an embodiment of the present invention;

[0012] Figure 3 is a code schematic diagram according to an embodiment of the present invention;

[0013] Figure 4 is a flowchart of a user's debugging operation according to an embodiment of the present invention;

[0014] Figure 5 is a flowchart of a visual Python code running and debugging method according to an embodiment of the present invention;

[0015] Figure 6 is a flowchart of an implementation of an intelligent dynamic adjustment algorithm according to an embodiment of the present invention;

[0016] Figure 7 is a flowchart of an implementation of a precise execution control method according to an embodiment of the present invention;

[0017] Figure 8 The structural schematic diagram of an electronic device suitable for implementing the embodiments of the present disclosure is shown. Specific embodiments

[0018] In order to enable those skilled in the art to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0019] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present invention described here can be implemented in an order different from those illustrated or described here. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units does not have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0020] According to an embodiment of the present invention, a method embodiment of a visual code running and debugging method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that here.

[0021] Figure 1 is a visual code running and debugging method according to an embodiment of the present invention, as Figure 1 shown, the method includes the following steps:

[0022] Step S102, in the integrated debugging environment, dynamically add or delete breakpoints in the code editing area, and automatically adjust the breakpoint positions when the code changes to keep the logic consistent.

[0023] First, set breakpoints. Set the upper limit of the number of breakpoints to the total number of lines of the current code and set breakpoints; cache the set breakpoint positions when exiting the debugging mode, automatically load the set breakpoint positions when re-entering the debugging mode, and clear all cached breakpoint positions when exiting the current work.

[0024] Next, detect the change operations of the code, where the change operations include inserting, deleting, or modifying code lines; traverse all the set breakpoints, and determine whether their original line numbers are affected by the change operations; for the affected breakpoints, adjust their line numbers from top to bottom to point to the corresponding logical code segment after the change, update all breakpoint position information, and synchronize it to the debugging environment.

[0025] Step S104, execute the code in the code editing area, highlight the currently executed code line in the execution control area, and dynamically indicate the execution path through visual markers. At the same time, display the status of local variables and global variables in real time in the variable monitoring area.

[0026] First, execute the code in the code editing area, and highlight the currently executed code line in the execution control area.

[0027] During the execution of the code, receive operation instructions through operation buttons, where the operation instructions include at least one of the following: continue, pause, next step, reset, and end; control the execution flow of the code based on the operation instructions; when an error occurs during program operation, automatically pause the debugging and perform the following operations; highlight the code line that triggers the error; display the error type, detailed description, and call stack trace information.

[0028] If the current execution point is a complete statement, execute the statement and jump to the next complete statement; if the current execution point is a function call, jump to the inside of the function definition and execute step by step, and resume execution at the call point after the function returns.

[0029] Next, dynamically indicate the execution path through visual markers.

[0030] Finally, display the status of local variables and global variables in real time in the variable monitoring area. For example, when executing inside a function, the local variable list within the current function scope is expanded by default; when executing in the global code block, the global variable list is collapsed by default, and the global variable status is expanded after receiving a manual expansion instruction.

[0031] The present invention also provides a visual Python code running and debugging system, as Figure 2 shown, including a breakpoint management module 22, a debugging and running module 24, and a data observation module 26.

[0032] The breakpoint management module 22 is used for program execution control. It can achieve precise pauses through preset breakpoints and can also manually interrupt the program execution at any time. The upper limit of the number of breakpoints is the upper limit of the current number of program lines, ensuring that breakpoint settings do not exceed the code range. When exiting the debug mode, all set breakpoint positions are automatically cached and displayed when re-entering the debug mode. When the user exits the current work, all cached breakpoint data is automatically discarded to avoid data pollution. By default, the breakpoint positions are recorded according to the line numbers of the code. The code is as follows Figure 3 As shown, when the code changes (such as inserting, deleting, or modifying code lines), the following steps are taken to adjust the breakpoint positions: Starting from the top, sequentially determine whether the position of each breakpoint is affected, and adjust the affected breakpoint positions to ensure that they still point to the correct logical code segment. After all breakpoint positions are confirmed, the breakpoint information is uniformly updated and applied to the debug environment.

[0033] The debug run module 24 is used to provide fine-grained control of the execution process, including the functions of continuing execution and single-step debugging of each statement / each function. The user can trigger the single-step execution operation through shortcut keys or interface buttons. The system executes step by step according to the current code line or the complete statement, and highlights the code segment being executed. When a function is called in the code, the system automatically jumps to the function definition and executes step by step inside the function. After execution is completed, the system returns to the function call point and continues the debugging of the subsequent code. If a breakpoint becomes invalid (such as the line number being misaligned due to code changes), the system will prompt the user to reset the breakpoint. If a runtime error occurs during code execution, the system will pause the debugging and display the error message and stack trace.

[0034] Among them, the user's debug operation process is as follows Figure 4 As shown, including the following steps:

[0035] Step S402, Next Step.

[0036] The user can select the "Next Step" operation to make the program move forward only one step. One step is defined as one line of code or one complete statement. If the current program has executed to the last line, the system will automatically exit the debug mode and display "The program has run to completion and has exited the debug mode" through a Toast prompt box.

[0037] Step S404, Continue Execution.

[0038] In the state where the program is paused, the user can select the "Continue" operation. The system will continue to execute the program from the current paused position until the next breakpoint is encountered or the program runs to completion. If the program runs to completion and no other breakpoints are encountered, the system will automatically exit the debug mode and display "The program has run to completion and has exited the debug mode" through a Toast prompt box.

[0039] Step S406, Pause Operation.

[0040] During the program debugging process, the user can trigger the "pause" operation at any time. The system will pause at the current code execution point and highlight the pause position. The user can observe the execution status of the program through the debugging interface, including information such as variable values and call stacks.

[0041] Step S408, reset operation.

[0042] The user can select the "reset" operation to return the debugger to the initialization state. The initialization state refers to the state when the program has not started executing. If the current state is already the initialization state, the "reset" button will be disabled to avoid repeated operations.

[0043] Step S410, end debugging.

[0044] The user can select the "end" operation to terminate the debugging process. The system will clear the current debugging state and exit the debugging mode.

[0045] The data observation module 36 constructs a multi-dimensional real-time monitoring system, which can synchronously view the variable status, console output, and graphics rendering effects at each step of execution. When executing inside a function, all stored variables within the current function scope are dynamically displayed, expanded by default. The user can observe the values and changes of local variables in real time through the debugging interface. When executing in the global code block, all stored global variables are displayed, collapsed by default. The user can view their values and changes by expanding the global variable list. The debugger dynamically updates and displays the corresponding variable information according to the currently executed function or code block. If the current execution point is inside a function, the local variables of that function are preferentially displayed. If the current execution point is in the global code block, only global variables are displayed. The variable display interface supports real-time updates to ensure that users can accurately understand the state changes during the program execution process.

[0046] The present invention significantly improves the transparency, controllability, and user experience of the code debugging process by providing a Python code running and debugging solution based on a visual interface. Developers can quickly locate problems, analyze variable states, and optimize code logic through an intuitive interface, thereby improving development efficiency and code quality. This method and system are applicable to various development scenarios and have broad application prospects. In particular, it reduces the need for frequent code modifications in traditional debugging methods and provides a more efficient and user-friendly debugging experience. At the same time, by real-time displaying variable states and execution paths, it greatly simplifies the process of understanding and troubleshooting complex logic.

[0047] In addition, the present invention particularly emphasizes the application in the educational scenario. By utilizing the dual coding theory and the cognitive load optimization principle, learners can understand and master programming concepts more quickly. Especially when dealing with abstract programming concepts such as loops and recursions, the performance is particularly prominent. This improvement not only enhances the learning efficiency but also strengthens the learners' emotional motivation, making the entire learning process more enjoyable and productive.

[0048] This application also provides a method for visualizing the running and debugging of Python code, as Figure 5 shown, including the following operation processes:

[0049] Step S502, intelligently and dynamically adjust breakpoints.

[0050] In this embodiment, an intelligent dynamic adjustment algorithm for breakpoint positions is adopted in the code change scenario. This algorithm is significantly different from the inefficient mode of manually maintaining breakpoints in the prior art. The specific implementation process is as Figure 6 shown, including:

[0051] Step S5022, record the breakpoint positions.

[0052] The system uses a hash table (Hash Table) to store breakpoint information. The key is the unique identifier of the code file, and the value is an ordered linked list (Linked List). Each node in the linked list contains the following metadata: line_number, the line number where the breakpoint is located (the line number based on the initial code version); logical_block_id, the unique identifier of the logical code block to which the breakpoint belongs (such as a function body, a loop body, etc.); checksum, the hash checksum of this line of code (used to detect whether the code content has changed).

[0053] Next, mark the logical code blocks. When the user sets breakpoints, the system performs static analysis on the current code through a syntax parser (such as an AST parser) to determine the logical attribution of the line where the breakpoint is located (for example, it belongs to line 3 of function funcA or line 5 of a for loop). This information is recorded together with the line number, providing a semantic basis for subsequent intelligent adjustment.

[0054] Step S5024, detect the type and scope of code changes.

[0055] When the user performs an editing operation (inserting, deleting, modifying lines) on the code, the system triggers incremental code difference analysis: The Myers' Diff Algorithm based on lines is used to compare the old and new code, generate a difference report (Diff Report), and clarify the types (inserted, deleted, modified) and positions of the changed lines. The change types are classified as follows: Inserted lines: Insert M lines at line number N, causing the subsequent line numbers to shift backward by M as a whole. Deleted lines: Delete the code from line number N to N+K, causing the subsequent line numbers to shift forward by K as a whole. Modified lines: Only modify the code content of line number N without changing the line number structure.

[0056] In the scenario of inserted lines, if the insertion position is before the line number of a breakpoint, the line number of that breakpoint needs to be increased by the number of inserted lines M. In the scenario of deleted lines, if the deletion range includes the line number of a breakpoint, that breakpoint becomes invalid; if the deletion range is before the breakpoint line number, the breakpoint line number needs to be decreased by the number of deleted lines K. In the scenario of modified lines, if the checksum of the modified line changes but the logical_block_id remains unchanged, only the checksum is updated; if the logical_block_id changes (such as the function name is modified), the breakpoint needs to be remapped to the new logical block.

[0057] Step S5026, adaptively adjust the breakpoint position.

[0058] Based on the difference report and logical block identifier, the system traverses all breakpoints in a top-down order and performs the following operations:

[0059] 1) Compensate for line number offset. For the line_number of each breakpoint, dynamically calculate the line number offset according to the position and quantity of inserted / deleted lines. For example, if 3 lines are inserted at line number 5, the breakpoint line numbers originally at line number 6 and later are increased by 3.

[0060] 2) Verify the logical block ownership. Use the AST parser to re-analyze the logical block where the adjusted line number is located, and verify whether the logical_block_id is consistent with the original record. If it is inconsistent (such as the function body is refactored), re-allocate the logical_block_id according to the syntax tree and prompt the user to confirm the validity of the breakpoint.

[0061] 3) Check content consistency. Compare the code checksum of the adjusted line number with the original record. If they are consistent, keep the breakpoint; if they are inconsistent (the code content is modified), then judge whether this line is still an executable statement (such as a non-empty line, a non-comment line) according to semantic analysis. If so, keep the breakpoint and update the checksum, otherwise mark it as invalid.

[0062] 4) Synchronize breakpoint status. Batch update the adjusted breakpoint information to the debugging environment to ensure that the debugger uses the latest line numbers and logic block information. Inactive breakpoints are displayed as gray icons, and a one-click delete or reposition function is provided.

[0063] Step S5028, breakpoint caching and isolation.

[0064] All breakpoint information is cached only in the current debugging session and is automatically cleared when the user exits the work to avoid cross-work data contamination. A version snapshot is generated each time the code is saved, and the breakpoint information is bound to the snapshot. When the user rolls back to a historical version, the system automatically loads the breakpoint data of the corresponding snapshot to ensure version consistency.

[0065] Step S504, control the debugging execution flow.

[0066] This embodiment is based on the statement-by-statement execution and function jump mechanism of logic blocks. This technology achieves precise execution control through the combination of code semantic analysis. Specifically, as Figure 7 shown, it includes:

[0067] Step S5042, determine the granularity of the execution unit.

[0068] The code is divided into atomic units according to complete statements (such as if-else blocks, loop bodies, function calls), rather than simply executed by line. For example, for the multi-line statement for i in range(10):\n print(i), it is regarded as one atomic unit during single-step execution to avoid interruption at the colon (:) line.

[0069] When executing a function call statement (such as result = funcA(arg1)): If the function funcA is defined, it will automatically jump to its definition location and execute statement by statement inside the function; if it is a built-in function or an undefined function, it will be directly executed and the result will be returned without entering the function interior.

[0070] Step S5044, synchronize the execution status.

[0071] The currently executing statement is highlighted with a dynamic arrow icon, and an execution path trace line is drawn on the left side of the code editing area. The color of the trace line changes according to the execution stage (such as blue for normal execution and red for error locations).

[0072] Each time a function call is entered, a new stack frame is added to the call stack panel, showing the function name, parameter values, and return address. The user can click on the stack frame to quickly jump to the execution location of the corresponding function.

[0073] Step S506, multi-dimensional real-time monitoring of variable status.

[0074] This step elaborates in depth on the variable hierarchical display and dynamic update algorithm based on the scope chain in the data observation module.

[0075] First, construct the scope chain. When the debugging starts, the system captures the current scope chain in real time through the injected Debug Hook and constructs a tree structure: the root node is the global scope (globals()); the child nodes are the nested function scopes (locals()).

[0076] Next, take variable snapshots. Every time a step is executed, the system makes a deep copy (DeepCopy) of the variables within the current scope, stores them as snapshots, and binds them to the execution position. Users can view the historical variable states by sliding the timeline.

[0077] Then, visually expand data structures. For composite type variables such as dictionaries, lists, and objects, provide hierarchical expansion buttons: by default, expand the first-level keys / properties; click the + icon to recursively expand the child elements, and the depth can be configured (default is 3 levels).

[0078] If a variable changes between two executions, the system highlights the different parts in green (newly added), red (deleted), and yellow (modified).

[0079] In the embodiment of this application, by combining line number offset compensation, logical block ownership verification, and content consistency check, the accuracy of breakpoint position adjustment is significantly improved in the scenario of code changes. Moreover, the statement-by-statement execution based on atomic units reduces the number of invalid interruptions. In addition, this embodiment supports the dynamic capture of the scope chain and the interactive expansion of complex data structures, reducing the time-consuming for variable state analysis.

[0080] This application also provides a visual code running and debugging device, including: a breakpoint management module, configured to dynamically add or delete breakpoints in the code editing area in an integrated debugging environment, and automatically adjust the breakpoint positions to maintain logical consistency when the code changes; a code execution module, configured to execute the code in the code editing area, highlight the currently executed code line in the execution control area, and dynamically indicate the execution path through visual markers. At the same time, the states of local variables and global variables are displayed in real time in the variable monitoring area.

[0081] It should be noted that: for the visual code running and debugging device provided in the above embodiment, only the above-mentioned division of each functional module is used for illustration. In actual applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the visual code running and debugging device provided in the above embodiment and the embodiment of the visual code running and debugging method belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0082] Figure 8 The structural schematic diagram of an electronic device suitable for implementing the embodiments of the present disclosure is shown. It should be noted that Figure 8 The shown electronic device is only an example and should not impose any limitations on the functions and usage scope of the embodiments of the present disclosure.

[0083] As Figure 8 shown, the electronic device includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1002 or the program loaded from the storage section 1008 into the random access memory (RAM) 1003. In the RAM 1003, various programs and data required for system operation are also stored. The CPU 1001, ROM 1002, and RAM 1003 are connected to each other via a bus 1004. The input / output (I / O) interface 1005 is also connected to the bus 1004.

[0084] The following components are connected to the I / O interface 1005: an input section 1006 including a keyboard, a mouse, etc.; an output section 1007 including such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, a modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the I / O interface 1005 as required. A removable medium 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1010 as required so that the computer program read from it can be installed into the storage section 1008 as required.

[0085] The above description is only the preferred embodiment of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and refinements can still be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. A method for visualizing code running and debugging, characterized in that including: In an integrated debugging environment, breakpoints are dynamically added or deleted in the code editing area, and the breakpoint positions are automatically adjusted when the code changes to maintain logical consistency; Execute the code in the code editing area, highlight the currently executed code line in the execution control area, and dynamically indicate the execution path through visual markers. At the same time, the status of local variables and global variables is displayed in real time in the variable monitoring area.

2. The method according to claim 1, wherein During the execution of the code, the method includes: Receiving an operation instruction through an operation button, where the operation instruction includes at least one of the following: continue, pause, next step, reset, and end; controlling the execution flow of the code based on the operation instruction; and / or When an error occurs during program operation, automatically pause debugging and perform the following operations; highlight the code line that triggers the error; display the error type, detailed description, and call stack trace information.

3. The method according to claim 1, wherein Display the status of local variables and global variables in real time in the variable monitoring area, including: When executing inside a function, by default, expand the list of local variables within the current function scope; and / or When executing in the global code block, by default, collapse the global variable list, and expand the global variable status after receiving a manual expansion instruction.

4. The method according to claim 1, wherein Automatically adjust the breakpoint positions, including: Detecting the change operation of the code, where the change operation includes inserting, deleting, or modifying a code line; Traversing all set breakpoints and determining whether their original line numbers are affected by the change operation; For the affected breakpoints, adjust their line numbers from top to bottom to point to the corresponding logical code segment after the change, update all breakpoint position information, and synchronize it to the debugging environment.

5. The method according to claim 1, wherein Execute the code in the code editing area, including: If the current execution point is a complete statement, execute the statement and jump to the next complete statement; If the current execution point is a function call, jump to the inside of the function definition and execute step by step, and resume execution at the call point after the function returns.

6. The method according to claim 1, wherein Before executing the code, the method further includes: Setting the upper limit of the number of breakpoints to the total number of lines of the current code; Caching the set breakpoint positions when exiting the debugging mode, automatically loading the set breakpoint positions when re-entering the debugging mode, and clearing all cached breakpoint positions when exiting the current work.

7. A visual code running and debugging device, characterized in that, including: A breakpoint management module configured to dynamically add or delete breakpoints in the code editing area in an integrated debugging environment, and automatically adjust the breakpoint positions when the code changes to maintain logical consistency; A code execution module configured to execute the code in the code editing area, highlight the currently executed code line in the execution control area, and dynamically indicate the execution path through visual markers. At the same time, the status of local variables and global variables is displayed in real time in the variable monitoring area.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, where when the program runs, it controls the device where the computer-readable storage medium is located to execute the method according to any one of claims 1 to 6.

9. A computer device, characterized in that, including: A memory and a processor, The memory stores a computer program; The processor is configured to execute the computer program stored in the memory, and when the computer program runs, the processor is caused to execute the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images