Method for converting building block language into easy-to-audit language

Abstract

The invention relates to a method for converting a building block language into an easy-to-check language, which belongs to the field of computers and comprises the following steps of: 1, analyzing an sb3 file structure, and extracting target node information in a file project; 2, constructing a syntax tree structure, and analyzing a code block of each target node by adopting a depth-first traversal algorithm; 3, establishing an operation code mapping table, and mapping operation codes in the sb3 file into corresponding easy-to-check language description through a dynamic reflection mechanism; step 4, according to a predefined language template, converting the parsed code block into a structured language easy to audit; and 5, organizing an output format, and grouping according to roles to generate a final easy-to-check language document. According to the method, a standardized scheme is provided for graphic programming homework correction, and programming education automation evaluation development is promoted.

Description

Technical Field

[0001] This invention relates to the field of computers, and in particular to a method for converting a block-based language into an easily auditable language. Background Technology

[0002] With the popularization of programming education, graphical programming languages ​​such as Scratch are widely used in programming education for teenagers. Scratch uses a block-based programming approach, presenting code logic in the form of visual building blocks, thus lowering the barrier to entry for learning programming. Scratch project files are saved in .sb3 format and contain complete project information, such as roles, code blocks, variables, audio, etc.

[0003] In educational applications, teachers need to grade and evaluate Scratch assignments submitted by students. Traditional manual grading methods suffer from low efficiency, high subjectivity, and difficulty in standardization. Therefore, using artificial intelligence technology to automate grading has become an urgent need.

[0004] However, existing technologies have the following problems:

[0005] 1) sb3 files are stored in JSON format, containing a large number of technical identifiers and nested structures, making it difficult for artificial intelligence models to directly understand their semantic content;

[0006] 2) Existing AI models have an accuracy rate of only about 50% in understanding sb3 files, which cannot meet the needs of practical applications;

[0007] 3) There is a lack of effective conversion methods to transform graphical programming languages ​​into natural language forms that AI can understand;

[0008] 4) Existing solutions fail to fully consider the stringent requirements for accuracy in grading within educational settings.

[0009] Invention Object

[0010] To address the aforementioned problems in the prior art, this invention provides a method for converting a block-based language into an easily auditable language.

[0011] A method for converting a block-based language into an easily auditable language includes:

[0012] Step 1: Parse the sb3 file structure and extract the target node information from the file project;

[0013] Step 2: Construct a syntax tree structure and parse the code block of each target node using a depth-first traversal algorithm;

[0014] Step 3: Establish an opcode mapping table and use a dynamic reflection mechanism to map the opcodes in the sb3 file to the corresponding Easy Audit Language descriptions.

[0015] Step 4: Convert the parsed code blocks into a structured, easily auditable language according to the predefined language template;

[0016] Step 5: Organize the output format and generate the final easy-to-audit language documents by grouping by role.

[0017] Furthermore, step 1 specifically includes:

[0018] Step 101: Parse the sb3 file structure and read the project.json file;

[0019] Step 102: Obtain the targets array from the project.json file to get all the target attributes;

[0020] Step 103: Extract the target node information from the file project.

[0021] Furthermore, the target node information includes the target name, code block, variables, sound, and appearance.

[0022] Furthermore, step 2 specifically includes:

[0023] Step 201: Identify the top-level code block;

[0024] Step 202: Recursively traverse the sub-blocks and subsequent blocks of each code block;

[0025] Step 203: During the recursive traversal process, a tree is gradually constructed with the event block as the root, next as the horizontal branch, and the child blocks in inputs as the vertical branches.

[0026] Furthermore, the dynamic reflection mechanism in step 3 specifically includes:

[0027] The corresponding processing method is dynamically invoked based on the opcode name, and each processing method is responsible for parsing the parameters and logic of a specific type of code block.

[0028] Furthermore, the opcode mapping table is used to establish the mapping relationship between Scratch opcodes and custom processing logic, and its data structure adopts a Map.<String,Handler> .

[0029] Furthermore, the structured, easily auditable language includes event descriptions, control structures, action descriptions, and conditional expressions.

[0030] The beneficial effects of this invention are reflected in:

[0031] 1) Significantly improved accuracy: The AI's accuracy in understanding sb3 files has been increased from 50% to 97%;

[0032] 2) Easy-to-Approve Language Conversion: Converts technical JSON format into easily understandable Chinese language for easy review;

[0033] 3) Educational Application Optimization: Specifically optimized for homework correction needs in educational scenarios;

[0034] 4) High-efficiency processing: It adopts depth-first traversal and dynamic reflection, resulting in high processing efficiency;

[0035] 5) Highly scalable: Supports various Scratch extension modules and custom blocks. Attached Figure Description

[0036] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

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

[0038] In this embodiment, as Figure 1 As shown, a method for converting a block-based language into an easily auditable language includes:

[0039] Step 1: Parse the sb3 file structure and extract the target node information from the file project (including target name, code block, variables, sounds, and appearances, etc.). Specifically:

[0040] Step 101: Parse the sb3 file structure and read the project.json file. The sb3 file is essentially a ZIP archive containing multiple JSON files, images, and audio resources. The core code structure information is stored in the project.json file. This step involves: 1) Uncompressing the .sb3 file. 2) Locating and reading the project.json file. 3) Parsing its contents into a workable JSON object or data structure.

[0041] Step 102: Retrieve the `targets` array from the `project.json` file to obtain all target attributes. Within the parsed `project.json` object, there exists a key array named `targets`. This array contains information about all sprites and stages in the project. Each target is a complex object containing all the sprite's primitive attributes, for example:

[0042] isStage: Boolean, indicates whether it is a stage;

[0043] name: String, the name of the character or stage;

[0044] variables:Object, a list of variables owned by this character;

[0045] lists:Object, a list of lists that this character owns;

[0046] broadcasts:Object, the list of broadcast messages owned by this character;

[0047] blocks:Object, the most important property, contains all the code block definitions for this role;

[0048] comments:Object, comments on a code block;

[0049] currentCostume: Integer, the index of the currently used costume;

[0050] costumes:Array, a list of all costumes (images) available for this character;

[0051] sounds:Array, a list of all the voices that this character possesses;

[0052] layerOrder: Integer, layer order;

[0053] volume: Integer, volume number; etc.

[0054] This step involves obtaining the `targets` array for subsequent processing.

[0055] Step 103: Extract target node information from the file project. This step transforms and extracts the raw target data obtained in Step 1.2 into target node (TargetNode) information defined internally by the system and easier to process. This process is a data structuring process.

[0056] Target node information includes:

[0057] Target name (name): Extracted from target.name.

[0058] Code blocks: Extracted from target.blocks. This is the core data and will be converted into a Map.<String,BlockNode> The key is the ID of the code block, and the value is a BlockNode object containing information such as opcode, inputs, next block, and parent block.

[0059] Variables: Extracted from target.variables and converted into a mapping from variable name to variable information.

[0060] Sounds: Extracted from target.sounds and converted into a list of sounds, including sound name, file MD5, etc.

[0061] Costumes: Extracted from target.costumes and converted into a list of costumes, including costume name, file MD5, resolution, etc.

[0062] Step 2: Construct a syntax tree structure. Parse the code blocks of each target node using a depth-first traversal algorithm. The purpose of this step is to organize the code blocks extracted in the previous step and stored in a Map structure into a tree structure based on their connections (next, parent, and child stacks in inputs) to visually represent the execution logic flow of the code. Construction goal: Organize the code blocks in each target into one or more syntax trees according to their execution flow. Each tree represents a complete execution flow (such as the complete response process after an event is triggered). The specific construction process is as follows:

[0063] Step 201: Identify the entry node (top-level code block); traverse all BlockNodes of a role (TargetNode); find code blocks without a parent block (parent is null or does not exist) whose opcodes belong to event types (such as event_whenflagclicked, event_whenkeypressed, event_whenthisspriteclicked). These event blocks are the starting point (root node) of the entire execution flow tree. A role may have multiple such event blocks, thus constructing multiple execution trees.

[0064] Step 202: Recursively traverse the sub-blocks and subsequent blocks of each code block; specifically:

[0065] 1) Starting from each found entry node (root node), perform a depth-first traversal (DFS);

[0066] 2) Traversing the "next" block (next: subsequent block): This is the sequential execution logic. If the current block has a next attribute pointing to the ID of another block, then that block is connected as the "next" node of the current block, and its next node is recursively traversed.

[0067] 3) Traversing sub-blocks (inputs) within the "input": This is the logic for handling nested structures (such as loops and conditional statements). Iterate through all inputs in the current block. Among them,

[0068] 3a) If the input type is SUBSTACK (e.g., the loop body of control_forever, control_repeat, or the execution body of control_if when the condition is true), then parse the ID of the sub-block from the input value;

[0069] 3b) If the input type is SUBSTACK2 (e.g., the "otherwise" body of control_if_else), the sub-block ID is also parsed out;

[0070] 3c) If the input type is CONDITION (e.g., the condition of control_if), parse out the block ID representing the conditional expression.

[0071] 4) Find the BlockNode corresponding to these sub-block IDs, connect them as "child nodes" of the current block, and recursively traverse these sub-blocks (i.e., enter the sub-block to continue processing its next and inputs).

[0072] Step 203, construct the tree node structure: Through the above recursive process, a tree is gradually constructed with the event block as the root, next as the horizontal branch (sibling node), and the child blocks in inputs as the vertical branch (child node); this tree clearly shows the complete process of the code "when an event occurs, execute A first, then execute B, and if condition C is true, then repeat D and E...".

[0073] Among them, special structures are handled as follows: a) Loop structures (such as control_forever, control_repeat): their child blocks are mounted as subtrees; b) Conditional branches (such as control_if, control_if_else): two branch subtrees are built respectively for "condition true" and "condition false"; c) Parallel execution (such as control_start_as_clone): marked as parallel branches, which do not affect the main process tree structure.

[0074] The generation of syntax tree objects involves organizing the traversal results into a tree structure, where each node is a BlockNode object containing references to all its child nodes. This ultimately forms one or more syntax trees, each representing a complete execution flow.

[0075] Step 3 involves establishing an opcode mapping table. This uses dynamic reflection to map opcodes in the sb3 file to their corresponding easily auditable language descriptions. This technique leverages the reflection capabilities of programming languages ​​to dynamically invoke the corresponding parsing method based on the opcode string name. Each processing method is responsible for parsing the parameters and logic of a specific type of code block. It also supports both Chinese and English bilingual output modes.

[0076] For example: Suppose we encounter a motion_movesteps block whose input STEPS value is 10.

[0077] 1) Obtain the opcode: The parser reads that the opcode field of the block has the value "motion_movesteps".

[0078] 2) Standardized method names: To make the method names more aesthetically pleasing, underscores are usually removed, resulting in "motionmovesteps".

[0079] 3) Dynamic lookup method: The parser uses the reflection API to search for a variable named motionmovesteps in the current class with a parameter list of (BlockNode, Map).<String,BlockNode> Methods for (String, Boolean, Integer). The code is as follows:

[0080]

[0081]

[0082] 4) Dynamic method invocation: After finding the method, pass in the current block and other parameters to invoke it.

[0083] 5) Execute a specific method: The call will jump to the specially written `motionmovesteps` method for execution. Its advantages are: no need for a large network of if-else or switch-case statements; when adding support for new opcodes, only a corresponding processing method needs to be created, and the system will automatically find it through reflection, greatly improving code maintainability and scalability.

[0084] The return value of this method, "move 10 steps", will be integrated into the final output of the easy-to-audit language.

[0085] Step 4: Convert the parsed code blocks into a structured, easily auditable language according to the predefined language template;

[0086] Step 5: Organize the output format and generate the final easy-to-review language documents by grouping by role. The structured easy-to-review language aims to convert graphical code into a natural language style text with a unified format, clear semantics, and ease of review by both humans and AI. Its components include:

[0087] (1) Event Description: Describes the conditions under which a program or a piece of logic is started. It corresponds to the event class block in Scratch.

[0088] For example: when the green flag is clicked, when the space bar is pressed, when the character is clicked, or when the message "Game Start" is received.

[0089] (2) Control Structures: These describe the program's flow control logic. They correspond to the control class blocks in Scratch.

[0090] For example: Repeat 10 times; Repeat; If <edge is hit> then, otherwise; Wait 1 second.

[0091] (3) Action Description: Describes the specific behavioral changes of a character or stage. It corresponds to the action, appearance, and sound blocks in Scratch.

[0092] For example: Move 10 steps, turn 15 degrees to the right, say "Hello!" for 2 seconds, switch to the "Style 2" look, and play the sound "Meow" until it finishes playing.

[0093] (4) Condition Expressions: These describe the conditions or operational logic in a program. They are usually nested within the parameters of control structures or other blocks. They correspond to the detection and operation blocks in Scratch.

[0094] For example: <touched the mouse pointer?>, <(score)>(10)>, <a random number between (x coordinate) and (50)>, connecting "Hello" and "World".

[0095] Ultimately, these components will be logically nested and combined according to the execution flow tree to form a complete and readable code description.

[0096] In this embodiment, the opcode mapping table is the core support and configuration foundation of the dynamic reflection mechanism. It is a data structure that establishes the mapping relationship between Scratch opcodes and custom processing logic. The structure of the mapping table: It is a Map.<String,Handler> (Mapping).

[0097] Key: The Scratch opcode string. For example: "motion_movesteps", "control_forever", "event_whenflagclicked".

[0098] Value: Handler. This "handler" can have various implementations, such as:

[0099] • MethodName: Stores the string representing the name of the corresponding processing method. The reflection mechanism uses this name to find the method.

[0100] • Function reference / pointer: In modern programming languages ​​(such as Java's MethodHandle, JavaScript's functions, and Python's function objects), a reference to a processing method can be stored directly, which is more efficient than reflection through a method name string.

[0101] • Strategy Object: For very complex opcodes, the handler might be an object that implements a unified interface (such as BlockHandler). The mapping table stores instances or classes of this object. This is a more object-oriented approach and easier to manage complex states.

[0102] The mapping table is created by hard-coded initialization, where a Map structure is manually populated during program initialization.

[0103] Applying this solution to actual education can achieve the following:

[0104] 1) Significantly improved accuracy: The AI's accuracy in understanding sb3 files has been increased from 50% to 97%;

[0105] 2) Easy-to-Approve Language Conversion: Converts technical JSON format into easily understandable Chinese language for easy review;

[0106] 3) Educational Application Optimization: Specifically optimized for homework correction needs in educational scenarios;

[0107] 4) Dual language support: Supports Chinese and English dual language output to meet different application scenarios;

[0108] 5) High-efficiency processing: It adopts depth-first traversal and dynamic reflection, resulting in high processing efficiency;

[0109] 6) Highly scalable: Supports various extension modules and custom blocks for Scratch.

[0110] In the description of embodiments of the present invention, the terms "first," "second," "third," and "fourth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," "third," or "fourth" may explicitly or implicitly include one or more of that feature. In the description of the present invention, unless otherwise stated, "a plurality of" means two or more.

[0111] In the description of embodiments of the present invention, the term "and / or" is used only to describe the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Additionally, the character " / " generally indicates that the preceding and following associated objects are in an "or" relationship.

[0112] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for converting a block-based language into an easily auditable language, characterized in that, include: Step 1: Parse the sb3 file structure and extract the target node information from the file project; Step 2: Construct a syntax tree structure and parse the code block of each target node using a depth-first traversal algorithm; Step 3: Establish an opcode mapping table and use a dynamic reflection mechanism to map the opcodes in the sb3 file to the corresponding Easy Audit Language descriptions. Step 4: Convert the parsed code blocks into a structured, easily auditable language according to the predefined language template; Step 5: Organize the output format and generate the final easy-to-audit language documents by grouping by role.

2. The method for converting a block-based language to an easily auditable language according to claim 1, characterized in that, Step 1 specifically includes: Step 101: Parse the sb3 file structure and read the project.json file; Step 102: Obtain the targets array from the project.json file to get all the target attributes; Step 103: Extract the target node information from the file project.

3. The method for converting a block-based language to an easily auditable language according to claim 1, characterized in that, The target node information includes the target name, code block, variables, sound, and appearance.

4. The method for converting a block-based language to an easily auditable language according to claim 1, characterized in that, Step 2 specifically involves: Step 201: Identify the top-level code block; Step 202: Recursively traverse the sub-blocks and subsequent blocks of each code block; Step 203: During the recursive traversal process, a tree is gradually constructed with the event block as the root, next as the horizontal branch, and the child blocks in inputs as the vertical branches.

5. The method for converting a block-based language to an easily auditable language according to claim 1, characterized in that, The dynamic reflection mechanism in step 3 is specifically as follows: The corresponding processing method is dynamically invoked based on the opcode name, and each processing method is responsible for parsing the parameters and logic of a specific type of code block.

6. The method for converting a block-based language to an easily auditable language according to claim 1, characterized in that, The opcode mapping table is used to establish the mapping relationship between Scratch opcodes and custom processing logic. Its data structure adopts a Map.<String,Handler> .

7. The method for converting a block-based language to an easily auditable language according to claim 1, characterized in that, The structured, easily auditable language includes event descriptions, control structures, action descriptions, and conditional expressions.

Images