CN111930636B

CN111930636B - 图形编程作品检查方法、装置、系统、设备及存储介质

Info

Publication number: CN111930636B
Application number: CN202010996284.XA
Authority: CN
Inventors: 陈刚; 林锋; 王馨然
Original assignee: Beijing Yizhen Xuesi Education Technology Co Ltd
Current assignee: Beijing Yizhen Xuesi Education Technology Co Ltd
Priority date: 2020-09-21
Filing date: 2020-09-21
Publication date: 2021-01-08
Anticipated expiration: 2040-09-21
Also published as: CN111930636A

Abstract

本申请的图形编程作品检查方法、装置、系统、设备及存储介质，一些示例中，图形编程作品检查方法包括：在接收到检查指令时，获得所述图形编程作品经格式化得到的图形代码组件组合、以及相关的至少一个参考答案经所述格式化得到的至少一个参考答案数据；利用所述至少一个参考答案数据检查所述图形代码组件组合，以获得对所述图形编程作品的检查结果。通过将图形编程作品及相应的参考答案格式化，利用形成的格式化数据形式的参考答案数据对图形编程作品的图形代码组件组合进行精细的多维度的检查，从而提供精细的检查结果，能指出错误及指导等，有效解决现有技术的检查结果单一的问题。

Description

图形编程作品检查方法、装置、系统、设备及存储介质

技术领域

本申请实施例涉及编程教学技术领域，尤其涉及图形编程作品检查方法、装置、系统、设备及存储介质。

背景技术

基于当前的教育中对逻辑思维训练的需求，各种逻辑思维类的电子教学工具持续在涌现。尤其在当今社会对于计算机网络技术的高度依赖的情形下，编程教学课程所面对用户的年纪也越来越小。

为此，已出现了一些较为直观且趣味的图形编程教学软件，例如麻省理工学院的简易图形化编程工具（Scratch）等，提供“搭积木”的编程方式，即用户可以将图形化的代码积木通过点击和拖拽等操作进行组合，而完成编程作品。

然而，虽然Scratch等图形编程教学软件具有对用户的图形编程作品的检查功能，但是输出的最终检查结果内容单一而不够精细，无法给用户给出指导性的建议，例如只能告知最终检查结果而对于错误的代码无法给出有效的订正提示等，不利于学习效率。

发明内容

有鉴于此，本申请实施例中提供图形编程作品检查方法、装置、系统、设备及存储介质，解决现有技术中的技术问题。

本申请实施例提供了一种图形编程作品检查方法，用于检查由图形代码组件组合形成的图形编程作品；所述图形编程作品检查方法包括：

在接收到检查指令时，获得所述图形编程作品经格式化得到的图形代码组件组合、以及相关的至少一个参考答案经所述格式化得到的至少一个参考答案数据；

利用所述至少一个参考答案数据检查所述图形代码组件组合，以获得对所述图形编程作品的检查结果。

可选的，在利用所述至少一个参考答案数据检查所述图形代码组件组合之前，还包括：

获得经所述格式化的比对模板；

检查所述图形编程作品相比于所述比对模板是否无修改；

若无修改，则停止所述检查；

若有修改，则继续所述检查。

可选的，所述格式化是将图形代码组件组合所包含的每个图形代码组件表示为多个数据维度上的格式化数据，以构成所述图形代码组件组合的格式化数据；所述多个数据维度包括：执行角色、事件、顺序逻辑、及类型；其中，在图形代码组件具有参数的情况下，所述多个数据维度还包括参数。

可选的，所述格式化的方式包括：

获取图形代码组件组合中每个图形代码组件的执行角色信息；其中，各所述图形代码组件按各自的执行角色分组形成各执行角色组；

获取每个图形代码组件在所属执行角色组下相关的事件信息；其中，每个执行角色组下的各图形代码组件按各自相关的事件信息分组形成各事件组；

依排列顺序提取事件组下每个图形代码组件的类型、表示其嵌套关系的深度信息、以及具有参数的图形代码组件的参数；

根据所提取的每个图形代码组件的信息，形成每个图形代码组件的格式化数据，并按所述排列顺序形成对应的图形代码组件组合的格式化数据。

可选的，所述利用所述至少一个参考答案数据检查所述图形代码组件组合，以获得对所述图形编程作品的检查结果，包括：

将所述至少一个参考答案数据同图形编程作品按照预定匹配规则在相关于所述多个数据维度的多个检查维度上进行匹配，以得到所述图形编程作品分别在每个参考答案数据检查下得到的匹配结果；

获取各所述匹配结果中的最优匹配结果；

根据所述最优匹配结果生成所述图形编程作品的检查结果。

可选的，所述多个检查维度包括：执行角色、事件、顺序逻辑、类型及数量；在图形编码组件具有参数的情况下，所述多个检查维度还包括：图形代码组件的参数。

可选的，在执行角色的检查维度上进行所述匹配，包括：

将图形编程作品同每个参考答案数据进行执行角色匹配：

若无匹配的执行角色，则停止检查；

若有匹配的执行角色，则继续检查。

可选的，所述的图形编程作品检查方法还包括：在无匹配的执行角色时，还提示正确的执行角色信息。

可选的，所述匹配的方式包括以下中的一种：

1）类型数量匹配方式，包括：判断图形编程作品是否与参考答案数据在图形代码组件的事件、类型及数量的维度上一致，以得到匹配结果输出；

2）完全匹配方式，包括：判断图形编程作品是否包含与参考答案数据在所述多个检查维度上完全一致的部分，以得到匹配结果输出；

3）局部匹配方式，包括：

根据对一参考答案数据的局部匹配规则标记从所述参考答案数据中提取用于检查的各答案片段，并确定每个所述答案片段相关的嵌套关系；

根据已确定相关嵌套关系的各所述答案片段之间的全排列结果得到对应的各种检查顺序；

按照每种所述检查顺序依次使用各所述答案片段在图形编程作品中进行匹配，以获得图形编程作品中分别与每个答案片段间最匹配的目标部分，集合形成每个备选匹配结果；

在各个所述检查顺序中，以能实现最优匹配度的备选匹配结果的检查顺序为最优检查顺序，并以最优匹配度的备选匹配结果作为输出的匹配结果。

可选的，所述检查顺序的评优规则包括：

1）完全匹配优于部分匹配；其中，所述完全匹配指的是图形编程作品具有符合于整个答案片段的部分，所述部分匹配指的是图形编程作品具有符合于部分答案片段的部分；

2）在部分匹配时，检查得到图形编程作品中与答案片段相符的图形代码组件的数量越多的检查顺序越优；

3）当在不同检查顺序中，图形编程作品和答案片段完全匹配的图形代码组件数量相同时，检查得到图形编程作品中缺失图形代码组件越少的检查顺序越优。

可选的，所述最优匹配结果是通过择优规则所选择的；所述择优规则包括：：

1）关于与所述最优匹配结果相应的图形编程作品所存在错误的提示信息；

2）图形编程作品的最优答案数据；其中，所述最优答案数据是与所述图形编程作品的最优匹配结果对应的参考答案数据。

本申请实施例还提供了一种图形编程作品检查方法，用于检查由图形代码组件组合形成的图形编程作品；所述图形编程作品检查方法包括：

在接收到检查指令时，利用至少一个参考答案检查所述图形编程作品，以获得对所述图形编程作品的检查结果，包括：

将所述至少一个参考答案同所述图形编程作品在多个检查维度上进行匹配，以得到所述图形编程作品分别在每个参考答案检查下得到的匹配结果；

获取所述图形编程作品的一或多个匹配结果中的最优匹配结果；

根据所述最优匹配结果生成所述图形编程作品的检查结果。

可选的，所述匹配的方式包括以下中的一种：

1）类型数量匹配方式，包括：判断图形编程作品是否与参考答案在图形代码组件的事件、类型及数量的维度上一致，以得到匹配结果输出；

2）完全匹配方式，包括：判断图形编程作品是否与参考答案在所述多个检查维度上完全一致，以得到匹配结果输出；

3）局部匹配方式，包括：

根据对一参考答案的局部匹配规则标记从所述参考答案中提取用于检查的各答案片段，并确定每个所述答案片段相关的嵌套关系；

按照每种所述检查顺序依次使用各所述答案片段在所述图形编程作品中进行匹配，以获得图形编程作品中分别与每个答案片段间最匹配的目标部分，集合形成每个备选匹配结果；

可选的，所述最优检查顺序是通过评优规则确定的。

可选的，所述检查顺序的评优规则包括：

可选的，所述最优匹配结果是通过择优规则所选择的。

可选的，匹配结果的择优规则包括：

1）参考图形编程作品和参考答案之间匹配的执行角色数量，匹配的执行角色数量越多，匹配度越高；

2）在匹配的执行角色数量相同的情况下，参考执行角色之下事件匹配的数量，匹配的事件数量越多匹配度越高；

3）在事件匹配的数量相同的情况下，参考类型数量权重；其中，匹配结果中的类型数量错误越少则类型数量权重越高，对应的匹配度越高；

4）当多个参考答案在累加各自对应的匹配结果中类型数量权重而得到总权重相同时，参考顺序匹配度权重；其中，匹配结果中的顺序逻辑错误越少则顺序匹配度权重越高，匹配度越高；

5）当多个参考答案在累加各自对应的匹配结果中类型数量权重而得到总权重相同时，输出其中首个参考答案的匹配结果，作为最优匹配结果。

本申请实施例还提供了一种图形编程作品检查装置，用于检查由图形代码组件组合形成的图形编程作品；所述图形编程作品检查装置包括：

格式化模块，用于在接收到检查指令时，获得所述图形编程作品经格式化得到的图形代码组件组合、以及相关的至少一个参考答案经所述格式化得到的至少一个参考答案数据；

检查模块，用于利用所述至少一个参考答案数据检查所述图形代码组件组合，以获得对所述图形编程作品的检查结果。

检查模块，用于在接收到检查指令时，利用至少一个参考答案检查所述图形编程作品，以获得对所述图形编程作品的检查结果；

所述检查模块包括：

匹配子模块，用于将所述至少一个参考答案同所述图形编程作品在多个检查维度上进行匹配，以得到所述图形编程作品分别在每个参考答案数据检查下得到的匹配结果；

最优获取子模块，用于获取各所述匹配结果中的最优匹配结果；

检查结果生成子模块，用于根据所述最优匹配结果生成所述图形编程作品的检查结果。

本申请实施例还提供了一种图形编程系统，包括：

图形编程模块，用于向用户提供图形编程界面，用于接收用户操作而将所操作图形代码组件组合为图形编程作品；

检查模块，由前述任一项的图形编程作品检查装置实现，用于检查所述图形编程作品并输出检查结果。

本申请实施例还提供了一种计算机设备，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序时执行前述任一项的图形编程作品检查方法的步骤。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序运行时执行前述任一项所述的图形编程作品检查方法的步骤。

与现有技术相比，本申请实施例的技术方案具有以下有益效果：

一方面，本申请实施例中通过将图形编程作品及相应的参考答案格式化，利用形成的格式化数据形式的参考答案数据对图形编程作品的图形代码组件组合进行精细的多维度的检查，从而提供精细的检查结果，能指出错误及指导等，有效解决现有技术的检查结果单一的问题。

另一方面，本申请实施例中对图形编程作品无侵入性，不限制作品题材，不需要运行即可得出检查结果。

附图说明

图1是Scratch的图形用户界面示意图。

图2是本申请实施例中的图形编程作品检查方法的流程示意图。

图3是Scratch中一个积木组合的示意图。

图4是本申请实施例中格式化的流程示意图。

图5是本申请实施例中格式化数据的原理示意图。

图6是本申请实施例中对应实际代码的格式化的流程图。

图7是图6中S608的具体实施流程图。

图8是步骤S202在实际应用中的具体实施流程图。

图9是本申请实施例中局部匹配方式的流程示意图。

图10是本申请实施例中一种参考答案的图形示意图。

图11是本申请实施例中一种参考答案的图形示意图。

图12a是本申请实施例中一种参考答案的图形示意图。

图12b是待图12a中参考答案检查的图形编程作品的图形示意图。

图13a是本申请实施例中一种匹配矩阵的内容示意图。

图13b是本申请实施例中一种匹配矩阵内匹配结果的内容示意图。

图13c是本申请实施例中一种匹配结果中错误信息的具体内容示意图。

图14是本申请实施例中一种检查结果的图形界面示意图。

图15是本申请另一实施例中图形编程作品检查方法的流程示意图。

图16是本申请实施例中图形编程作品检查装置的结构示意图。

图17是本申请另一实施例中图形编程作品检查装置的结构示意图。

图18是本申请实施例中图形编程系统的结构示意图。

图19是本申请实施例中计算机设备的结构示意图。

具体实施方式

图形编程教学软件已被应用于孩童、青少年的编程教学中。例如麻省理工学院的简易图形化编程工具（Scratch），用户可以通过在Scratch的图形用户界面中操作各种“编程积木”，并加以组合以形成图形编程作品。

如图1所示，展示Scratch的图形用户界面示意图。

在图1所示的Scratch的图形用户界面示意图中，左侧栏位101展示可以选择使用的代码积木，例如“运动”、“外观”、“声音”、“事件”、“控制”等各类型的代码积木，图中展示选择“外观”选项而展示的各种外观相关的代码积木；图示中部的编程区域102展示通过组合所选择的代码积木构成的图形编程作品，示例性地展示有“当旗帜（图中以图形表示）被点击”则执行角色“移动100步”至“碰到边缘就反弹”，将执行角色的旋转方式设为“左右翻转”（图中的倒三角表示下拉列表，通过操作在下拉列表可以选择动作），执行角色“右转15度”说“你好！”播放声音“喵”并展示下一个造型；图中右侧栏位展示右下方的执行角色区域103、及其上方的动画展示区域（一般称为“舞台区”）104，其中可以展示执行图形编程作品的代码后所对应呈现的动画结果，所述执行角色可以是卡通猫“可多”，对应于上述“喵”的声音。当然，执行角色可以是多个，例如在右侧的执行角色区域104可以分开展示，例如执行角色有猫和狗，用户可以选择对应的执行角色，而在中部的编程区域102可以对应所选择的执行角色进行代码积木的编程，图中角色“猫”的纹路与“狗”不同表示其被选中。

在Scratch中，有各类型的积木，其形态各有不同。其中，大多数编写程序都是以事件积木开始，例如图1中展示的最上面一块的“当旗帜被点击”的代码积木就是事件积木。

在现有的Scratch中，如果想要评价用户提交的图形编程作品是否满足要求，主要方案是在提供给用户的Scratch 模板中提前预置好两部分积木组，一部分积木组用于给当前作品构建一个可量化的目标，简称目标积木组；另一部分积木组用来在用户作品运行结束后评估用户代码是否达成目标，简称为评估积木组。

现有方案的评估中，只能输出检查的最终结果，较为单一，对于其中错误的代码积木无法给出有效的订正提示。此外，由于必须预设可量化的目标，会给Scratch作品的题材带来很大的限制，采用此类方案的Scratch 作品基本都是闯关类的作品或其衍生题材，使得编程作品的题材，教学效率、趣味性有所降低。再有，用户在编程创作过程中无法立即得到检查反馈，必须让作品运行并等待作品运行完成才能触发评估积木组中的代码。

鉴于上述不足，本申请实施例中旨在提供与图形编程作品检查相关的方案，以解决上述一项或多项问题。

如图2所示，展示本申请实施例中的图形编程作品检查方法的流程示意图。

所述图形编程作品检查方法可用于检查由图形代码组件组合形成的图形编程作品。在一些示例中，所述图形代码组件可以是Scratch中的代码积木，图形代码组件组合即可以是Scratch中拼装积木得到的积木组合，而图形编程作品则可以是由一或多个积木组合形成的作品，例如图1所展示的内容。需说明的是，图1所展示的一个积木组的图形编程作品只是一种示例，实际上图形编程作品并不限制积木组的数量，例如有一个或多个执行角色（例如猫、狗等），每个执行角色可以执行一或多个事件，则会对应形成一个或多个事件相关的积木组，每个积木组以一个事件积木为起始。

所述图形编程作品检查方法包括：

步骤S201：在接收到检查指令时，获得所述图形编程作品经格式化得到的图形代码组件组合、以及相关的至少一个参考答案经所述格式化得到的至少一个参考答案数据。

步骤S202：利用所述至少一个参考答案数据检查所述图形代码组件组合，以获得对所述图形编程作品的检查结果。

在一些实施例中，所述检查指令可以是通过图形用户界面来接收用户操作所产生的，例如在图1的图形用户界面中设置一“检查”按钮，以接收用户操作，如点击、拖曳等，从而执行所述检查。

可以理解的是，在实际场景中，用户可以在任何情形下，主动发起对其已编程作品的检查，相比于现有技术中只能在图形编程作品完成之后进行检查的方案来说，与用户的实时交互性更好，更利于教学效率。

通过具体示例说明上述步骤S201中格式化的原理。

之所以采用格式化，是因为目前存在的图形编程教学软件中，例如Scratch，形成的图形编程作品的源码由于其格式问题，具体的，在Scratch3.0得JSON 文件中，角色脚本区内的每个积木都被分配了一个随机的唯一积木标识（key），彼此之间使用链表的方式连接，当产生嵌套之后代码更加复杂，这就使得作品源码难以阅读，更无法直接进行二次开发。此外，Scratch 作品运行时，每个积木是单独解析的，不同积木的数据格式存在较大的差异。在 Scratch 采用的链表数据格式和积木格式异构的双重影响下，想要直接对Scratch 的作品源码进行明文解析非常困难；相应的，图形编程作品、参考答案的代码解析存在困难，就只能采用单一的检查方式，对更加细致、灵活的检查产生了阻碍，不利于教学效率。

以Scratch为例进行具体说明。Scratch 3.0的作品源码整体采用 JSON 数据格式进行存储，JSON(JavaScript Object Notation)是一种轻量级的数据交换格式。在图3中，展示一个积木组合，其中包含了功能如下：当旗帜被点击后，角色会向前走10步，走完10步后如果进入了绿色区域，会说“你好”。

示例性地，图3的积木组合对应的 JSON代码如下代码段1所示：

{

"积木1":{

"opcode":"event_whenflagclicked", //事件

"next":"积木2", //下一个是“积木2”

"parent":null, //不存在父积木

"inputs":{

},

"fields":{

}

},

"积木2":{

"opcode":"motion_movesteps", //移动动作

"next":"积木3", //下一个是“积木3”

"parent":"积木1", //父积木是“积木1”

"inputs":{

"STEPS":[ 1, [4,"10"]] //移动步数是“10”

},

"fields":{

}

},

"积木3":{

"opcode":"control_if", //如果...那么

"next":null,

"parent":"积木2",

"inputs":{

"CONDITION":[ 2, "积木4"], //条件：如果“积木4”

"SUBSTACK":[ 2, "积木5"] //分支：那么“积木5”

},

"fields":{

}

},

"积木4":{

"opcode":"sensing_touchingcolor", //碰到颜色

"next":null,

"parent":"积木3",

"inputs":{

"COLOR":[1,[ 9,"#a3cc33"]] //颜色是 "#a3cc33"

},

"fields":{

}

},

"积木5":{

"opcode":"looks_say", //外观：“说”

"next":null,

"parent":"积木3",

"inputs":{

"MESSAGE":[1, [ 10,"你好！"]] //说：“你好”

},

"fields":{

}

其中，每个代码积木都被分配了一个随机的唯一积木标识（称为key），为查看清晰，在上述代码中简单地通过“积木1”~“积木5”等来替代性地表示积木标识，如果在实际实施中，积木标识可以是一串字母、数字、符号构成的随机字符串；可以看到，每个当前代码积木所对应的数据结构体中，通过“next”字段中的key来标注当前积木相邻的后一块积木，同时通过“parent”字段中的key标注当前积木的前一块积木，通过此方式确定积木的先后顺序；如果向前积木“parent”的值为“null”即“空”，则表示该积木为组合的首个积木，可以例如为事件积木

可以看到，“opcode”字段为积木的名称（也就是积木的“类型”），parent记录上一个积木的积木标识。积木的参数被分散在“inputs”和“fields”字段中，比如“碰到颜色”这块积木的参数名为 COLOR ，而“移动”积木的参数名为STEPS。

除了彼此间的顺序关系，上述积木组合还存在更为复杂的“嵌套”关系，比如“如果…那么”积木中存在两个嵌套关系：“碰到颜色”是“如果…那么”的条件积木，“说”是满足条件时要被执行的积木。在原始的 JSON 文件中，“opcode”为“contorl_if”的积木代表用户界面的“如果…那么”积木，该积木的“inputs”字段中，“CONDITION”和“SUBSTACK”所对应的数组内部出现了两个随机的积木标识，通过这两个积木标识在代码中找到了“opcode”为“sensing_touching color”和“looks_say”的积木，这两块积木就是用户界面上的“碰到颜色”和“说”积木，代表“如果…那么”中嵌套了这两块积木。

比较上述两段中对于参数的说明可见，在积木原始 JSON 中，嵌套关系跟参数在代码格式上非常相似，容易混淆。

因此，步骤S201中，可以通过对图形代码组件组合先进行格式化，以使其中各种信息更清楚而易于区分，利于多样化的检查的实现。所述图形代码组件即可例如为Scratch中的代码积木，而图形代码组件组合即可为对应的积木组合。

在一些示例中，所述格式化指的是将积木组合所包含的每个积木表示为多个数据维度上的格式化数据。在具体实现的示例中，所述多个数据维度包括：执行角色、事件、顺序逻辑、及类型；其中，在积木具有参数的情况下，所述多个数据维度还包括参数。

其中，执行角色例如为图1中的猫“可多”或其它在执行角色库中的执行角色，图1实施例中的积木组合都可以是由“可多”为执行角色的。

再例如，图1实施例中积木组合，可以看到其中首块积木为事件积木，之后的代码积木都归属于它，故通过所述事件积木即可确定后续代码积木的所属事件，通过确定代码积木所属事件的信息，可以唯一确定代码积木所归属于本事件相关的积木组合。

再例如，代码积木的名称“opcode”就代表了它的名称（也即类型），例如"motion_movesteps"表示移动。

所述顺序逻辑包含了代码积木的顺序及嵌套关系。

关于顺序关系，指的是积木组合中各个代码积木之间的先后排列顺序，例如图3中从上至下的各积木排列顺序，这个排列顺序同时也对应了积木组合的代码顺序，例如前述代码段1所示。

关于嵌套关系，举例来说，图3中的“如果....那么”代码积木，其中嵌套了“碰到颜色”和“说”的代码积木。

可选的，可以通过每个积木的深度信息来表示其嵌套位置，从嵌套外层到内层，每深一层嵌套则对积木的深度信息的取值可以加1来表示。例如，假设将每个不存在嵌套关系代码积木，通过深度信息的取值为“1”来表示，比如图3中“当旗帜被点击”、“移动”的深度信息的取值为“1”；被嵌套的积木“碰到颜色”和“说”的深度信息的取值可以设置为比“1”更深一级的“2”，如果“碰到颜色”换成其他嵌套积木，则被其所嵌套的积木的深度信息的取值就可以为更深一级的“3”。

再例如，图3中所示例的，其中有的积木没有参数，例如“当旗帜被点击”就不是无参数的积木，而“移动”积木就是有参数的积木，这些参数可以归到对应的积木的格式化数据中。

在Scratch中，用户是在对应执行角色所打开的执行角色区域中进行代码积木的拼装，所以相应的代码积木都会归到执行角色下，且积木组合的积木一般为事件积木，表示执行角色下的一个事件，往下再是所属的其它积木，图形代码积木之间可能存在有嵌套关系，其中有的是有参数积木而有的是无参数积木。

在一些示例中，对应这样的上下级关系，可以进行如图4所示的格式化的流程示意图，其具体包括：

步骤S401：获取每个图形代码组件的执行角色信息；其中，各所述图形代码组件按各自的执行角色分组形成各执行角色组。

举例来说，例如图形编程作品包含以小猫“可多”为执行角色的第一图形代码组件组合，那么这个第一图形代码组件组合中的每个图形代码组件就会归在小猫“可多”这一执行角色组；同理，图形编程作品中若还包含以小狗为执行角色的第二图形代码㢟组合，那么其中的每个图形代码组件就会归在小狗这一执行角色组中。

步骤S402：获取每个图形代码组件在所属执行角色组下相关的事件信息；其中，每个执行角色组下的各图形代码组件按各自相关的事件信息分组形成各事件组。

举例来说，图3中的图形代码组件组合的执行角色是小猫“可多”，则归属于小猫“可多”的执行角色组中，进一步的，该图形代码组件组合的首个图形代码组件是事件类型的，“当旗帜被点击”，则以其为事件形成事件组，后续的图形代码组件都归在此事件组中。

步骤S403：依排列顺序提取事件组下每个图形代码组件的类型、表示其嵌套关系的深度信息、以及具有参数的图形代码组件的参数。

所述排列顺序为每个图形代码组件在所在的图形代码组件组合中的先后顺序。

如之前实施例所述，类型通过从“opcode”提取的名称表示；嵌套关系通过深度信息表示，例如“当旗帜被点击”、“移动”、“如果....那么”的深度信息的取值可以设为“1”，而被“如果....那么”嵌套积木嵌套的“碰到颜色”和“说”的深度信息的取值可以为“2”；另外，参数例如为图3中“移动”中的参数“10”，“碰到颜色”中的颜色代码“#a3cc33”等。

步骤S404：根据所提取的每个图形代码组件的信息，形成每个图形代码组件的格式化数据，并按所述排列顺序形成对应的图形代码组件组合的格式化数据。

图3的图形代码组件组合对应于之前代码段1，在经格式化后，得到的图形代码组件组合中每个图形代码组件的格式化数据表示成[名称，[参数列表]，深度信息]，而图形代码组件组合的格式化数据中集合了这些格式化数据，可以表示为数组形式。举例来说，代码段1可以格式化为以下代码段2形式：

{

"event_whenflagclicked":

[

["event_whenflagclicked", 1],

["motion_movesteps",["10"], 1],

["control_if", 1],

["sensing_touchingcolor", ["#a3cc33"], 2],

["looks_say", ["你好!"], 2]

]

}

具体说明上述代码段2中各个积木的格式化数据的含义。

例如，“event_whenflagclicked”，表示这一组积木组合的事件积木是“当旗帜被点击”。“event_whenflagclicked”下方展示的数组中的每个元素为一个积木的格式化数据。

其中，积木的格式化数据的形式为[名称,[参数列表],深度信息]，名称对应的是积木的opcode，参数列表包含积木的各项参数，深度信息用于表示积木的嵌套关系。

在代码2的示例中，各个图形编码组件的格式化数据的排列顺序同图3中对应的图形编码组件的排列顺序是一致的，即图形代码组件组合中图形代码组件的排列顺序的信息也被还原在了对应的格式化数据中。

可以理解的是，在该排列顺序下，根据深度信息的变化可以对应得到嵌套关系的变化，例如一个嵌套关系的发生或退出。举例来说，最外层的图形代码组件的深度信息为“1”，按在图形代码组件组合中图形代码组件的排列顺序，出现嵌套关系后深度增加“1”，每深一层嵌套深度增加“1”，每解除一层嵌套则深度减少“1”；若还原到深度信息为1时，说明退出了最外层的嵌套关系；例如从“如果...那么”到“碰到颜色”和“说”，深度信息从“1”变化到“2”，若该图形代码组件组合中后续的图形代码组件出现深度信息为“1”时，说明退出了“如果...那么”的嵌套。同理，若之后再出现组合中的图形代码组件的深度信息增加，说明又出现了新的嵌套关系。

进一步具体来讲，数组中的第一个元素是格式化后的事件积木的格式化数据，本示例中事件积木是“当旗帜被点击”，无参数，深度为1。

数组中的第二个元素对应“移动”积木的格式化数据，其有一个参数，为 10，同时跟事件积木是拼接的关系，所以深度信息相同也为1。

数组中的第三个元素是“如果…那么”积木的格式化数据，该积木包含嵌套积木同时没有自身的参数，由于嵌套关系只通过相邻关系+深度信息表达，所以保持了“如果…那么”积木格式的简洁。第三个元素的深度信息为 1 表明与第二块积木仍是拼接关系。

数组中的第四个元素是“碰到颜色”积木的格式化数据，包含一个参数“a3cc33”，是 RGB 格式的颜色。该积木深度信息为 2，而相邻的上一个积木深度信息为1，表明“碰到颜色”积木是“如果…那么”积木的嵌套内积木。

数组中的第五个元素是“说”积木的格式化数据，包含一个参数“你好！”，深度为2，表明“说”积木和“碰到颜色”积木都是“如果…那么”积木的嵌套内积木。如果后面还有其他积木，如果深度变为 3，说明进入了更深一层的嵌套，如果深度变为 1，说明结束了“如果…那么”积木的嵌套，回到了“如果…那么”积木的同一深度。

为更直观说明图4方法的原理，可以参考图5所示，其中右侧展示执行角色组“小猫”（如小猫“可多”）、“小狗”，“小猫”的执行角色组下级有事件组“当旗帜被点击”，事件组当旗帜被点击下级有各个图形代码组件的格式化数据，如“当旗帜被点击”、“移动”、“如果...那么”、“碰到颜色”、及“说”。

图5中展示的是图形代码组件“当旗帜被点击”和“移动”的格式化数据更具体的数据结构示意图。图形代码组件“当旗帜被点击”是无参数的，其包含操作码“event_whenflagclicked”（即“事件_当旗帜被点击”）和深度信息“1”；而“移动”是有参数的，其包含操作码“motion_movesteps”（即“动作_移动_步”）、参数（移动步数“10”）、及深度信息“1”。

上述步骤S403，在可能的实施方式中实际的处理过程包括：

逐一访问每个图形代码组件；

将判断需要递归处理的图形代码组件，加入到第一递归队列；

从第一递归队列外的每个图形代码组件中提取信息并置入对应的格式化数据；

从第一递归队列中的每个图形代码组件中提取信息并置入对应的格式化数据。

以下结合之前实施例中，现有Scratch的JSON代码及其转化后的格式化数据的代码，在图6实施例中展示上述处理过程实际实现的流程图。

以 Scratch 为例，有效的积木组合的首个积木必须是事件积木，故找到链表中的事件积木“event”作为启动积木，依顺序格式化处理每个当前积木；当每个当前积木处理完后，会读取当前积木中next指向的下一块积木继续格式化处理；需要递归处理的积木，指的示存在下拉列表的积木和嵌套的积木，下拉列表的积木例如图1中的“将旋转方式设为”积木，嵌套的积木例如图3中的“如果...那么”积木，此类积木需要递归处理，会生成递归任务插入到“递归队列”中，例如以下流程中的第一递归队列即递归队列1、和第二递归队列即递归队列2，并在处理 next 指向的下一积木之前处理；如果递归队列中存在任务时，会优先处理递归队列中的任务，处理递归会开启新的流程，整个处理过程中的深度信息会+1。

以Scratch为例，在图6中，展示对实际代码进行格式化的流程，具体包括：

步骤S601：开始步骤。

步骤S602：inputs第一次格式化。

举例来说，判断当前积木是否包含需归到递归队列的积木标识（key），若有则加入到递归队列1；对于在 Scratch 中包含具有下拉列表的积木，下拉列表的积木可能是由多块积木拼接成的，在步骤 S602中可以把此多块积木拼接成一块处理。例如图1中的“播放声音”积木和其中的“喵”，“喵”由下拉列表所选择，看似“喵”所是“播放声音”积木的参数，但实际上“喵”可能是属于“播放声音”积木以外的另一积木中的参数，因此，可以在步骤 S602中将这两个积木拼接为一块。

步骤S603：fields格式化。

举例来说，Scratch 中 inputs 和 fields 两个字段都可以携带数据，比如在S602中拼接带有下拉列表的两块积木为一块时，下拉列表选中的参数可能会保存在拼接成一块积木的fields 中；为了统一处理，在S603中可以把fields合并到 inputs中，即将参数合并到inputs中。

步骤S604：inputs第二次格式化。

合并了 fields 之后，对 inputs作第二次格式化，此流程主要是为了特殊处理事件积木的参数和“自定义积木”。

步骤S605：判断inputs是否为空；若否，则至步骤S606；若是，则至步骤S608；

步骤S606：生成无参数的积木的格式化数据。

如果经过 S605判断inputs列表为空，说明该积木没有参数，按照格式生成无参数的积木的格式化数据，加入到格式化结果的数组中。

S607、S612 处理递归队列1：递归队列1是全局共享的队列，也就是说在解析当前积木时，递归队列1可能已经包含了待处理的任务。在 S602 中，如果发现inputs中包含需要递归处理的积木，那么会把要处理的积木key和深度组合成一个“递归任务”加入到递归队列1队尾。使用“队列+递归”的优势是嵌套积木和被嵌套积木在最终的输出数组中是相邻的，保留了上下文，同时根据深度信息又可以推测出嵌套的层级关系。

递归队列 1 主要是用来处理那些已知的递归积木，往往非常明显，比如图10中的“重复执行”和“如果...那么...否则”都是明显的嵌套积木，判断方式是被嵌套的积木key会出现在此类积木的inputs字段中。例如，当遍历重复执行积木的 inputs 列表时，发现字段“SUBSTACK”时，内部的值一定是被嵌套积木的 key，“如果...那么”积木也同样有这个key。不过，嵌套积木虽然发现的早，但是此时当前积木的参数可能还没有处理完，所以需要提前把 SUBSTACK 中的 key 先加到递归队列1中，等待当前的积木完全处理完毕后，再去检查递归队列1是否有需要处理的积木。

S608：inputs 第三次格式化。

本步骤的主要目的是对每个积木的 inputs 中的每一组数据进行所需参数的筛选，并加入到参数列表，且在此流程中若还遇到包含需要递归处理的积木，则将积木加入到第二递归队列，即递归队列2中；需要筛除的递归队列 2 的作用是收集那些不是特别明显的需要递归处理的积木，通常是积木中放入了其他积木，例如“移动10步”积木中的“10”参数替换成其它积木，例如“响度”等；可选的，递归队列 2 的优先级高于递归队列 1，即在处理递归队列时，先处理递归队列2中的积木，再处理递归队列1中的积木。

在一些实施例中，S608完整的处理流程如图7所示：

步骤S701：开始；

步骤S702：将inputs中的各input排序后逐个遍历；

在具体实施中，之所以对inputs排序是因为：Scratch 中包含多组参数的积木，有时候参数中标识key的顺序不是固定的；由“与”连接的两个积木，这两个积木中的任意一个先执行得到的结果会不同，故此处确定一种排序后再继续处理。所以需要对其中的各个input进行排序。

在遍历每个input的过程中：

步骤S703：判断input长度是否为3；若否，则进入S704；若是，则进入S705；

在具体实施中，input 是 inputs 中的每一个字段对应的值。由于某些积木上可以嵌套其他积木，比如“移动10步”积木10步位置为一圆形框，在Scratch中称为数字框，其中除了放置参数以外，还可以放置其他圆形的积木，例如“响度”积木插入“移动10步”中10步的位置，这会使得“移动10步”积木的inputs 发生变化，“响度”积木的key 会被插到“移动10步” inputs 中的STEPS字段中，在这种情况下，对应的数据长度会变成 3。

具体的，“移动10步”的input对应为"STEPS":[ 1, [4,"10"]]，假设响度积木的key为“abc”，则“移动“响度”步”对应的input为"STEPS":[ 3，"abc"，[4,"10"]]，可见[]中的数据长度变为了3，因此需要特殊判断。

步骤S704：去除input中的空值，标记input的末尾元素last。

步骤S706：判断last是否是字符；若是，说明可能是key或字符形式的参数，则进入S707；若否，则进入S708；

步骤S707：判断last是否为某个积木的标识（key）；若是，说明last需要递归处理（可能有嵌套），则进入S709；若否，说明last只是普通参数，则进入S710；

步骤S709：将标识对应的积木加到递归队列2；之后进入S711；

在具体实施中，之所以选择input的末尾元素，是因为所需提取的参数一般就在input的最后，例如COLOR":[1,[ 9,"#a3cc33"]]中的"#a3cc33"；又例如，在下拉列表的积木中，比如“碰到“鼠标指针””，“鼠标指针”是下拉选择的参数，其中涉及拼接的“碰到”积木以及存放“鼠标指针”参数的其它积木，“碰到”积木中input的末尾元素是这个其它积木的key，在递归队列中进行递归处理就可以跳转到该其它积木，而“鼠标指针”参数就存放在该其它积木的fields中，在JSON代码中，“鼠标指针”的参数例如表示为“_mouse_”，对应的字段例如表示为：“TOUCHINGOBJECTMENU”；在fields和inputs合并后从inputs提取或直接从合并前的fields直接提取input末尾元素的方式，就可以从该其它积木提取到“鼠标指针”参数。

步骤S711：inputs遍历是否结束；若是，则结束；若否，则回到步骤S702；

步骤S710：将last拼接到参数列表中；之后进入S711；

步骤S708：标识是否是广播；若是，则进入S712；若否，则进入S713：

其中，广播是 Scratch 中的一类特殊积木，例如“广播消息”积木，其结构跟其他积木不同，所以需要特殊处理。

步骤S712：把last的第一个元素last[1]加入到参数列表，即广播类型积木的参数；之后进入S711；

步骤S713：把last的末尾元素加到参数列表；之后进入S711；

步骤S705：input的第一个元素input[1]是否是其它积木的key；若是，input带有key的都可能与递归相关，这里表示数字框中放入了原生的变量，则进入S714；若否，则进入S715；

步骤S714：将input[1]加入到递归队列2；之后进入步骤S711；

步骤S715：input[1]是否是数组；若是，则进入步骤S716；若否，则进至S704，进行参数的识别即可。

步骤S716：表示数字框中放入了自定义的变量（位于数组中），并将input[1]加入到递归队列2。

在某些情形下，input[1]和last[1]可能会相同，例如"STEPS":[ 1, [4,"10"]]中，1、4都是Scratch中的内部值，可以略去，则在"STEPS":["10"]中，last[1]和input[1]得到的参数都是“10”，如果如前述S703得到的input的数据长度为3，例如"STEPS":[ 3，"abc"，[4,"10"]]，那么last[1]和input[2]皆为“10”，"abc"可以表示放入移动积木中的其它积木的key。

回到图6的流程，在S608之后，还可以包括：

步骤S609：生成当前的含参数的积木的格式化数据。步骤S608 结束后会生成当前积木的参数列表，按照格式组合出含参数的积木的格式化数据 [名称，参数列表]，深度]，加入到最终要输出的数组中。

步骤S610、对递归队列2 进行处理。

步骤S611：对递归队列1进行处理。

因为递归队列2 与原积木的上下文更加紧密，所以先处理递归队列 2，再处理递归队列 1。

通过上述实施例，可以理解本申请实施例中格式化的原理；以下再通过具体示例说明上述图2中步骤S202中对图形编程作品进行检查的原理。

可以理解的是，在所述图形编程作品已格式化的情形下，对其进行检查的答案也需要进行相应的格式化。

在一些可选示例中，所述的图形编程作品检查方法中，在步骤S202之前还可包括比对模板检查，包括：

获得经所述格式化的比对模板；

检查所述图形编程作品相比于所述比对模板是否无修改；

若无修改，则停止所述检查；

若有修改，则继续所述检查；例如，进入步骤S202。

具体来说，在比对模板也是一种预先设置的图形代码组件组合，用于提供给用户以令其对所需编写的图形编程作品有所概念，以提升教学效率。在所述图形编程作品被格式化的情形下，所述比对模板亦被格式化，再进行对比。其中，如果图形编程作品相比比对模板未有修改，则说明用户只是使用了模板，但未在模板基础上进行任何的编程行为，也就没有必要再进行后续参考答案检查。

可以理解的是，在上述示例中，图形编程作品和比对模板中每个图形代码组件都具有格式化数据，那么可以将比对模板中的图形代码组件组合的格式化数据在图形编程作品中对比，以得到是否存在所述修改。在一些示例中，所述修改指的是图形代码组件的类型、数量、顺序逻辑、参数等维度上是否有变化。

在一些示例中，如图8所示，展示步骤S202在实际实施例中的具体实施流程，包括：

步骤S801：将所述至少一个参考答案数据同图形编程作品的每个图形代码组件组合在相关于所述多个数据维度的多个检查维度上进行匹配，以得到所述图形编程作品分别在每个参考答案数据检查下得到的匹配结果。

可选的，参考答案可以有多个，有利于通过各个匹配来度量用户的图形编程作品在不同维度上的优缺点，而不会像单一固定的答案一般只能得到固定答案比较的反馈，从而更有利于编程这样的需要逻辑和发散性思维的技能的教学效率。

具体的，类型数量指的是特定类型的图形代码组件的统计数量，例如图3中“移动”积木的数量；顺序逻辑指的是图形代码组件的顺序和嵌套关系；参数指的是图形代码组件的参数。

按照前述实施例中，所描述的每个图形代码组件组合对应为从上到下的执行角色组、事件组、及其中各图形代码组件的按顺序排列的格式化数据（包含对应其类型的名称、对应嵌套关系的深度信息及参数），可以先对图形编码作品的执行角色进行检查。因此可选的，可以将执行角色的检查排在最先，如果执行角色不正确，那么后续的事件、顺序逻辑、类型、数量、参数等都没有检查的必要。

在一示例中，在执行角色维度的检查流程，包括：

将图形编程作品同每个参考答案数据进行执行角色匹配：

若无匹配的执行角色，则停止检查；

若有匹配的执行角色，则继续检查。

需说明的是，虽然在Scratch中各个图形代码组件是先归属在执行角色下的，因此示例中展示优先判断是否有执行角色匹配的情况，若无匹配则可省去具体的检查流程；但是在其它实施例中，并非以执行角色为优先的情况下，可以对此流程加以变化，并非以此示例为限。

可选的，对图形编程作品在执行角色维度的检查可以位于前述比对模板的检查之后；当然，也可以根据实际需求而加以变化，并非以此为限。

在一些示例中，所述匹配的方式包括以下中的一种：类型数量匹配方式、完全匹配方式及局部匹配方式。在具体实施中，在对图形编程作品检查前，可以预先选择设置其中任意一种匹配方式，通过预先设置的一种匹配方式，将多个参考答案数据中的每个分别按此预设的匹配方式同图形编程作品进行匹配，以得到各个匹配结果；因此，在一些示例中，各个匹配结果可以呈现为匹配矩阵的形式。

逐一说明几种匹配方式：

1）类型数量匹配方式，包括：判断图形编程作品是否与参考答案数据在图形代码组件的事件、类型及数量的维度上一致，以得到匹配结果输出。

例如，如果有一个参考答案数据对应为：有一个“当旗帜被点击”积木、一个“移动”积木、一个“如果...那么”积木、一个“碰到颜色积木”、及一个“说”积木，要求图形编程作品中积木组合所包含类型积木和数量与此参考答案数据一致，无需检查顺序逻辑、参数；如果是图形编程作品为图3中的积木组合，通过该类型数量匹配方式进行匹配，就能达到100%的正确匹配。

类型数量匹配方式对答案要求较低，更适合于初学者的检查。

2）完全匹配方式，包括：判断图形编程作品是否包含与参考答案数据在所述多个检查维度上完全一致的部分，以得到匹配结果输出。

完全匹配方式，即判断图形编程作品相比于参考答案时是否完全相同，包顺序逻辑、类型、数量及参数；如果存在图形代码组件多余或缺少，顺序错了或者类型错了等，都会降低匹配度。

3）局部匹配方式；其匹配流程例如图9所示，可以包括：

步骤S901：根据对一参考答案数据的局部匹配规则标记从所述参考答案数据中提取用于检查的各答案片段，并确定每个所述答案片段相关的嵌套关系。

局部匹配方式与完全匹配方式不同，可以根据要检查的要点设定参考答案数据的局部匹配规则。对取得的各参考答案数据按局部匹配规则标记进行划分成答案片段，并明晰各答案片段的嵌套关系，之后可通过各个答案片段的格式化数据按对应的局部匹配规则与图形编程作品进行匹配。

在一些示例中，局部匹配方式可以针对不同的应用场景设置各种局部匹配规则，例如对应普通连续的图形代码组件设置两种局部匹配规则：1.1完全匹配；1.2：类型数量匹配；对应嵌套的图形代码组件设置两种局部匹配规则：2.1嵌套内包含；2.2嵌套内类型数量。此处的完全匹配、类型数量匹配与前述实施方式中的相同名词在原理上一致，只是在匹配上此处使用的是答案片段，而之前针对的是整个参考答案数据。

为更直观了解上述答案片段的原理，请参考图10所示，展示实施例中一种参考答案的图形示意图。

其中，如图中箭头所指，通过“嵌套内包含”、“嵌套内类型数量”的特殊图形代码组件来表示局部匹配规则标记，从“嵌套内包含”开始至“嵌套内类型数量”之间的为第一个答案片段，包括：“如果...那么...否则”及其内嵌套的“碰到”（参数为鼠标指针）、“说-- 秒”（参数为xxx秒）、“显示”、“隐藏”。

第一个答案片段对应的“嵌套内包含”，表示的是至少包含这些积木即算作正确匹配，故用户在写出正确的逻辑后，还可以另外增加逻辑。

第二个答案片段从“嵌套内类型数量”的特殊图形代码组件所表示的局部匹配规则标记开始，包括：“重复执行”的嵌套积木、嵌套在“重复执行”中的另一个嵌套积木“如果...那么...否则”、及嵌套在“如果...那么...否则”中的“碰到”。

第二个答案片段对应的“嵌套内类型数量”，表示的是要求图形编程作品同参考答案中图形代码组件的类型和数量一致，并不需要限定逻辑。在此示例中，之所以设置为“嵌套内类型数量”，是因为程序启动后需要持续监听用户的鼠标事件（对应“鼠标指针”参数），所以需要一个死循环，每一轮循环都需要做判断，可认为在死循环中，检查执行角色是否碰到鼠标指针是必须的逻辑，而不添加其他图形代码组件的逻辑。

又如图11中的参考答案，其中的局部匹配规则标记对应的“完全匹配”，也就是说，要求与后续积木完全相同。在此示例中，采用此局部匹配规则的原因在于，执行角色需要说一句话，然后隐藏自己，这个逻辑要先“显示”再“说”然后再“隐藏”，这三个动作必须按顺序连续完成，且同不包含嵌套积木，适合使用“完全匹配”。

如果要这三个动作打乱顺序也算对，那么这里的局部匹配规则就要改为“类型数量匹配”。在“类型数量匹配”中，用户就可以自行设置参数，也可算正确匹配，“说- - - -秒”这个积木说什么，说几秒用户可以自行定义，所以用“ - - ”表示忽略参数。

步骤S902：根据已确定相关嵌套关系的各所述答案片段之间的全排列结果得到对应的各种检查顺序。

以图12a中的参考答案举例来说，其包含了两个答案片段，设上方的第一个“完全匹配”对应的答案片段为答案片段1，下方第二个“完全匹配”对应的答案片段为答案片段2，则根据两个答案片段的全排列，存在两种检查顺序，答案片段1、2，及答案片段2、1。

步骤S903：按照每种所述检查顺序依次使用各所述答案片段在图形编程作品中进行匹配，以获得图形编程作品中分别与每个答案片段间最匹配的目标部分，集合形成每个备选匹配结果。

图12b中示例性地展示了待检查的图形编程作品，其中包含了两个图形代码组件组合A和B，通过上述两种检查顺序答案片段1、2及答案片段2、1分别匹配该图形编程作品。

1）按照答案片段1、2 的顺序去匹配：

以下分别将答案片段1、2针对A进行匹配作为情形1，将答案片段1、2针对B进行匹配为情形2进行说明。

先使用答案片段1进行匹配：

情形1：答案片段 1 与图形编程作品中左侧的图形代码组件组合A进行匹配，按完全匹配的局部匹配规则，图形代码组件组合A中的“移动10步”和“碰到边缘就反弹”两块完全匹配；在后续答案片段2的匹配中此已匹配的两块会被忽略，故图形代码组件组合A剩余的待匹配部分是“当旗帜被点击”和“移到随机位置”。

情形2：答案片段 1 与图形编程作品中右侧的图形代码组件组合B进行匹配，按完全匹配的局部匹配规则，图形代码组件组合B中缺失“移动10步”和“碰到边缘就反弹”两块，图形代码组件组合B剩余的待匹配部分是“当旗帜被点击”和“说你好2秒”。

再使用答案片段2进行匹配：

情形1：答案片段2与图形代码组件组合A的待匹配部分进行匹配，按照完全匹配的局部匹配规则，图形代码组件组合A的待匹配部分中“移到随机位置”匹配，缺失1块“移动10步”。

情形2：答案片段 2 与图形代码组件组合B剩余待匹配的部分进行匹配，缺失“移动10步”和“移到随机位置”两块。

由此，可以得到情形1的匹配结果优于情形2，则得到按照答案片段1、2 的顺序去匹配图形编程作品的匹配结果：

匹配图形编程作品相对答案片段 1：完全匹配，匹配图形编程作品相对答案片段2：缺失1块“移动10步”。

2）按照答案片段2 、1的顺序去匹配：

由于1、2 的顺序并没有产生完全匹配的最终结果，所以还需要使用2、1的顺序再去检查。

以下分别将答案片段2、1针对A进行匹配作为情形3，将答案片段2、1针对B进行匹配为情形4进行说明。

先使用答案片段2进行匹配：

情形3：答案片段 2 在图形代码组件组合A中完全匹配的结果：A中的“移动10步”匹配，但A中缺失1块“移到随机位置”；A中剩余的待匹配部分有“当旗帜被点击”、“碰到边缘就反弹”和“移到随机位置”。

情形4：答案片段 2 在图形代码组件组合B中匹配的结果：B中缺失“移动10步”和“移到随机位置”两块；B中剩余的待匹配部分有“当旗帜被点击”、“碰到边缘就反弹”和“移到随机位置”

再通过答案片段1在A、B剩余的待匹配部分中进行匹配：

情形3：答案片段1 在A剩余的待匹配部分中匹配的结果：A中的“碰到边缘就反弹”匹配，缺失1块“移动10步”。

情形4：答案片段 1 在图形代码组件组合B中匹配的结果：B中缺失“移动10步”和“碰到边缘就反弹”两块。

由此，情形3中答案片段2、1匹配的数量较多，可以得到情形3的匹配结果优于情形4，则得到按照答案片段2、1 的顺序去匹配图形编程作品的匹配结果：

匹配图形编程作品相对答案片段 1：缺失1块“移动10步”，匹配图形编程作品相对答案片段2：缺失1块“移到随机位置”。

在一些示例中，在上述完全匹配的过程中，以完整答案片段匹配为最高优先级，当图形编程作品中包含完整答案片段时，不必进行答案片段中子片段的匹配，例如答案片段为顺序的多个图形代码组件A、B和C；当图形编程作品中不包含完整答案片段A、B和C时，以其中各种最长答案子片段进行匹配，例如比完整答案片段少一个图形代码组件的A和B、B和C进行匹配；以此类推，若当前的最长答案子片段完整匹配到了，则不再进行在最长答案子片段缩小后（例如减少一个边上的图形代码组件）的最长答案孙片段中继续匹配；反之，则继续匹配，直至得到匹配结果，例如A、B和C的最长答案子片段A和B、B和C两个在图形编程作品中都匹配不到，那么就以A、B、C三个最长答案孙片段分别在图形编程作品中匹配，尝试得到匹配结果。

步骤S904：在各个所述检查顺序中，以能实现最优匹配度的备选匹配结果的检查顺序为最优检查顺序，并以最优匹配度的备选匹配结果作为输出的匹配结果。

可选的，所述检查顺序的评优规则包括：

根据以上原则可知，按照上述评优规则2）、3）中数量满足程度优先于顺序满足程度，故在答案片段 1、 2 的检查顺序中，选择得到最优的第一个备选匹配结果：图形编程作品相对答案片段1完全匹配，相对答案片段2缺失1块“移动10步”。

在答案片段2、1的检查顺序中，选择得到最优的第二个备选匹配结果：图形编程作品相对答案片段1缺失1块“移动10步”，相对答案片段2缺失1块“移到随机位置”。

可见，在根据检查顺序答案片段1、2和2、1得到的两个备选匹配结果中，由于“相对答案片段1完全匹配”优于“相对答案片段1缺失1块“移动10步”，“相对答案片段2缺失1块“移动10步””和“相对答案片段2缺失“移到随机位置””之间抵消，故得到最优的检查顺序为答案片段1、2，及最优的第一个备选匹配结果作为匹配结果输出。

步骤S802：获取各所述匹配结果中的最优匹配结果。

在一些示例中，图形编程作品同每个参考答案数据的匹配结果可以存放在匹配矩阵中，从匹配矩阵中的各个匹配结果选出最优匹配结果。

如图13a所示，展示实施例中一种匹配矩阵的示意图。一个题目可能有多种编程写法，也就代表着会有多个参考答案。该匹配矩阵是以执行角色和参考答案为维度来组织的，每个交叉点上的元素即为一执行角色下以事件为单位的各个图形代码组件组合和一参考答案数据按预设匹配规则（类型数量匹配、完全匹配、或局部匹配）进行匹配的匹配结果。

可选的，如果图形编程作品中多余了或者误删了执行角色，也可以记录在匹配矩阵中，采用局部匹配规则时会忽略多余的角色。

如图13b所示，展示实施例中一种匹配结果展开的数据结构示意图。

每个匹配结果可以包括以下各项数据：缺失的事件图形代码组件（如Scratch中的积木）、多余的事件图形代码组件、错误信息、是否完全匹配、完全匹配的图形代码组件组合数量、类型数量权重、及顺序匹配度权重。

当某个执行角色如果不是与参考答案完全匹配，匹配结果中的错误信息会继续细分。如图13c所示，错误信息进一步包含两类错误信息，一类是与类型数量相关的“类型数量错误信息”，数量一般即多余和缺失，例如图中展示的进一步细分的“多余的图形代码组件数量”和“缺失的图形代码组件数量”；另一类是与顺序逻辑相关的“顺序逻辑错误信息”，顺序逻辑错误是指当前事件下图形代码组件没有缺失、多余，但是存在逻辑错误，细分也有两类：一类是图形代码组件使用正确，但是参数错误了，另一类是图形代码组件前后顺序错误或者嵌套层级错误，例如图中展示的进一步细分的“参数错误的图形代码组件数量”、“顺序或嵌套关系错误的图形代码组件”。

根据匹配矩阵，可以得到各个元素中匹配度最优的，以将最优匹配结果对应的参考答案作为输出给用户的最终答案。

在一些示例中，根据所述匹配矩阵，进行匹配度的择优规则以获得参考答案和图形编程作品间最优匹配结果，即可得到和图形编程作品最匹配的最终输出答案；可选的，匹配度的择优规则也可以是根据与多个检查维度的上下优先级来确定，例如按执行角色、事件、类型、数量、顺序、嵌套、参数等的从上至下的优先级来确定，择优规则具体包括：

如果所有执行角色都完全匹配了，那么说明图形编程作品正确。

例如，通过查看匹配的事件积木的数量来确定该匹配的事件数量。

3）在事件匹配的数量相同的情况下，参考类型数量权重，例如图13b中的类型数量权重项的值；所述类型数量权重可以是根据图13c中的错误信息项中“类型数量错误信息”计算得到，匹配结果中的类型数量错误越少则类型数量权重越高，对应的匹配度越高；

在类型数量优先于逻辑顺序的情况下，可进一步形成以下择优规则4：

4）当多个参考答案在累加各自对应的匹配结果中类型数量权重而得到总权重相同（例如每个参考答案的总权重对应于图13a中相应列的各个元素中的类型数量权重相加）时，可以参考顺序匹配度权重，顺序匹配度权重可以是根据上图13c的错误信息中的“顺序逻辑错误信息”计算得到，匹配结果中的顺序逻辑错误越少则顺序匹配度权重越高，匹配度越高；

步骤S803：根据所述最优匹配结果生成所述图形编程作品的检查结果。

在一些示例中，所述检查结果是将最优匹配结果转化为用户可以理解的内容，例如展示关于最优匹配结果中错误信息的提示信息；也可以展示最终输出的答案以供比对。

例如图14所示，图中左侧展示了用户的图形编程作品141，假设以图10和图11中的为参考答案，检查该图形编程作品141；右侧展示了检查结果142；在右侧的检查结果中，示例性地展示了检查到的执行角色是小猫“可多”，向下事件为“当旗帜被点击”，再下方列出了存在的错误，例如图形代码组件“重复执行”中多出了“显示”，别忘记把“显示”放到图形代码组件“如果...那么....否则”中等。

在一些示例中，综合上述实施例，提供一种实际应用的举例：

用户可以在完成其图形编程作品时，点击“检查”以对图形编程作品检查。可选的，已预先设置有与图形编程作品对应的比对模板、各参考答案和匹配方式。

在受到“检查”触发检查，将提交的图形编程作品、对应的比对模板和各参考答案都进行格式化而转化为格式化数据。

然后开始检查，先将图形编程作品和比对模板进行比对，发现相对有修改则继续检查；然后，将图形编程作品和各参考答案中的执行角色进行匹配，发现有匹配的执行角色，则继续检查并把匹配的结果放入匹配矩阵，例如将图形编程作品中涉及的关联或放到匹配矩阵的执行角色维度；之后，进一步通过预设的匹配方式进行图形编程作品和各个参考答案的格式化数据的匹配，得到各个匹配结果并放入所述匹配矩阵；通过择优规则在所述匹配矩阵选择最优匹配结果，并获得对应的最终输出答案；将所述最优匹配结果转化为用户可以理解的检查结果进行展示，可选的，还可以展示所述最终输出答案。

虽然，在上述实施例中是通过转化后的格式化数据进行检查，可以实现更加灵活多样的检查结果，有利于教学；然而，在一些示例中，也可以通过与上述格式化原理相似的方式，直接从例如代码段1中提取检查涉及的数据，也可以达成灵活多样的检查结果，只是在计算上可能不如前述实施例效率高。

基于这样的实施例，在不预先进行格式化的情况下，从未格式化的原代码段中提取执行角色、事件、顺序逻辑、类型及数量等数据，进行检查并输出检查结果。

如图15所示，展示本申请提供又一实施例中形编程作品检查方法的流程示意图。本实施例中具体检查、匹配的实现可以参考前述实施例，此处不作重复赘述。

本实施例中，所述图形编程作品检查方法包括：

步骤S151：在接收到检查指令时，利用至少一个参考答案检查所述图形编程作品，以获得对所述图形编程作品的检查结果，包括：

S1511：将所述至少一个参考答案同所述图形编程作品在多个检查维度上进行匹配，以得到所述图形编程作品分别在每个参考答案检查下得到的匹配结果；

S1512：获取所述图形编程作品的一或多个匹配结果中的最优匹配结果；

S1513：根据所述最优匹配结果生成所述图形编程作品的检查结果。

可选的，所述匹配的方式包括以下中的一种：

3）局部匹配方式，包括：

可选的，所述最优检查顺序是通过评优规则确定的。

可选的，所述检查顺序的评优规则包括：

可选的，所述最优匹配结果是通过择优规则所选择的。

可选的，匹配结果的择优规则包括：

如图16所示，展示本申请实施例中的图形编程作品检查装置160，用于检查由图形代码组件组合形成的图形编程作品。本实施例中的图形编程作品检查装置160，对应于图2实施例中的图形编程作品检查方法，因此本实施例中的具体实施细节可以参考上述实施例，此处不对技术细节进行重复赘述。

所述图形编程作品检查装置160包括：

格式化模块161，用于在接收到检查指令时，获得所述图形编程作品经格式化得到的图形代码组件组合、以及相关的至少一个参考答案经所述格式化得到的至少一个参考答案数据；

检查模块162，用于利用所述至少一个参考答案数据检查所述图形代码组件组合，以获得对所述图形编程作品的检查结果。

如图17所示，展示本申请实施例还提供了一种图形编程作品检查装置170，用于检查由图形代码组件组合形成的图形编程作品。本实施例中的图形编程作品检查装置170，对应于图15实施例中的图形编程作品检查方法，因此本实施例中的具体实施细节可以参考上述实施例，此处不对技术细节进行重复赘述。

所述图形编程作品检查装置170包括：

检查模块171，用于在接收到检查指令时，利用至少一个参考答案检查所述图形编程作品，以获得对所述图形编程作品的检查结果；

所述检查模块171包括：

匹配子模块1711，用于将所述至少一个参考答案同所述图形编程作品在多个检查维度上进行匹配，以得到所述图形编程作品分别在每个参考答案数据检查下得到的匹配结果；

最优获取子模块1712，用于获取各所述匹配结果中的最优匹配结果；

检查结果生成子模块1713，用于根据所述最优匹配结果生成所述图形编程作品的检查结果。

如图18所示，展示本申请实施例还提供了一种图形编程系统的模块示意图。所述图形编程系统180包括：

图形编程模块181，用于向用户提供图形编程界面，用于接收用户操作而将所操作图形代码组件组合为图形编程作品。

检查模块182，由前述例如图16或17的图形编程作品检查装置160或170实现，用于检查所述图形编程作品并输出检查结果。

在一些示例中，所述图形编程系统可以是基于Scratch实现，包含所述图形编程模块，以用于与用户交互来实现积木组合的编程。而前述实施例中的图形编程作品检查装置可以作为组件、模块形式集成到图形编程系统中，以用于检查图形编程作品。

如图19所示，展示本申请实施例中的计算机设备的结构示意图。

所述计算机设备190包括存储器191和处理器192，所述存储器191上存储有可在所述处理器192上运行的计算机程序，所述处理器192运行所述计算机程序时执行前述例如图2或图15实施例中的图形编程作品检查方法的步骤。

在一些示例中，所述处理器192可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理(Digital Signal Processing，DSP)、ASIC等；所述存储器191可能包含高速RAM存储器，也可能还包括非易失性存储器(Non-volatile Memory)，例如至少一个磁盘存储器。

在一些示例中，所述计算机设备190可以实现于例如服务器、服务器组、台式机、笔记本电脑、智能手机、平板电脑、智能手环、智能手表、或其它智能设备、或这些智能设备通信连接而形成的处理系统。

本申请实施例还可以提供计算机可读存储介质，其上存储有计算机程序，所述计算机程序运行时执行前述任一种实施例中图形编程作品检查方法的步骤。

即，上述本发明实施例中的图形编程作品检查方法被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的图形编程作品检查方法。此外，当通用计算机访问用于实现在此示出的图形编程作品检查方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的图形编程作品检查方法的专用计算机。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机程序。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机程序可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。

例如，前述图16、17、18实施例等中的各个功能模块可以是软件实现；或者也可以是软硬件配合实现，例如通过计算机设备实施例中的处理器运行存储器的计算机程序实现；或者，也可以是通过硬件电路实现。

此外，在本申请各个实施例中的各功能模块可以集成在一个处理部件中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个部件中。上述集成的部件既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的部件如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。

例如，前述图16、图17实施例中各个功能模块、子模块可以是独立、单一的程序实现，也可以是一程序中的不同程序段分别实现，在某些实施场景中，这些功能模块可以位于一个物理设备，也可以位于不同的物理设备但相互通信耦合。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。

例如，前述图2、15实施例中的图形编程作品检查方法等，其中的各个步骤的顺序可以在具体场景中加以变化，并非以上述描述为限。

虽然本说明书实施例披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本说明书实施例的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。

Claims

1.一种图形编程作品检查方法，其特征在于，用于检查由图形代码组件组合形成的图形编程作品；所述图形编程作品检查方法包括：

在接收到检查指令时，获得所述图形编程作品经格式化得到的图形代码组件组合、以及相关的至少一个参考答案经所述格式化得到的至少一个参考答案数据；所述格式化是将图形代码组件组合所包含的每个图形代码组件表示为多个数据维度上的格式化数据，以构成所述图形代码组件组合的格式化数据；所述多个数据维度包括：执行角色、事件、顺序逻辑、及类型；其中，在图形代码组件具有参数的情况下，所述多个数据维度还包括参数；所述顺序逻辑包含了代码积木的顺序关系及嵌套关系；其中，在图形代码组件组合的格式化数据中，各个所述图形代码组件的格式化数据之间的排列顺序同图形代码组件组合中图形代码组件之间的排列顺序一致，每个所述图形代码组件的格式化数据中的深度信息的取值表示图形代码组件在图形代码组件组合中的嵌套位置；

2.根据权利要求1所述的图形编程作品检查方法，其特征在于，在利用所述至少一个参考答案数据检查所述图形代码组件组合之前，还包括：

获得经所述格式化的比对模板；

检查所述图形编程作品相比于所述比对模板是否无修改；

若无修改，则停止所述检查；

若有修改，则继续所述检查。

3.根据权利要求1所述的图形编程作品检查方法，其特征在于，所述格式化的方式包括：

4.根据权利要求1所述的图形编程作品检查方法，其特征在于，所述利用所述至少一个参考答案数据检查所述图形代码组件组合，以获得对所述图形编程作品的检查结果，包括：

获取各所述匹配结果中的最优匹配结果；

根据所述最优匹配结果生成所述图形编程作品的检查结果。

5.根据权利要求4所述的图形编程作品检查方法，其特征在于，所述多个检查维度包括：执行角色、事件、顺序逻辑、类型及数量；在图形编码组件具有参数的情况下，所述多个检查维度还包括：图形代码组件的参数。

6.根据权利要求5所述的图形编程作品检查方法，其特征在于，在执行角色的检查维度上进行所述匹配，包括：

将图形编程作品同每个参考答案数据进行执行角色匹配：

若无匹配的执行角色，则停止检查；

若有匹配的执行角色，则继续检查。

7.根据权利要求6所述的图形编程作品检查方法，其特征在于，还包括：在无匹配的执行角色时，还提示正确的执行角色信息。

8.根据权利要求4或5所述的图形编程作品检查方法，其特征在于，所述匹配的方式包括以下中的一种：

3）局部匹配方式，包括：

9.根据权利要求8所述的图形编程作品检查方法，其特征在于，所述最优检查顺序是通过评优规则确定的。

10.根据权利要求9所述的图形编程作品检查方法，其特征在于，检查顺序的评优规则包括：

11.根据权利要求4所述的图形编程作品检查方法，其特征在于，所述最优匹配结果是通过择优规则所选择的。

12.根据权利要求11所述的图形编程作品检查方法，其特征在于，匹配结果的择优规则包括：

13.一种图形编程作品检查装置，其特征在于，用于检查由图形代码组件组合形成的图形编程作品；所述图形编程作品检查装置包括：

格式化模块，用于在接收到检查指令时，获得所述图形编程作品经格式化得到的图形代码组件组合、以及相关的至少一个参考答案经所述格式化得到的至少一个参考答案数据；所述格式化是将图形代码组件组合所包含的每个图形代码组件表示为多个数据维度上的格式化数据，以构成所述图形代码组件组合的格式化数据；所述多个数据维度包括：执行角色、事件、顺序逻辑、及类型；其中，在图形代码组件具有参数的情况下，所述多个数据维度还包括参数；所述顺序逻辑包含了代码积木的顺序关系及嵌套关系；其中，在图形代码组件组合的格式化数据中，各个所述图形代码组件的格式化数据之间的排列顺序同图形代码组件组合中图形代码组件之间的排列顺序一致，每个所述图形代码组件的格式化数据中的深度信息的取值表示图形代码组件在图形代码组件组合中的嵌套位置；

14.一种图形编程系统，其特征在于，包括：

检查模块，由如权利要求13所述的图形编程作品检查装置实现，用于检查所述图形编程作品并输出检查结果。

15.一种计算机设备，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，其特征在于，所述处理器运行所述计算机程序时执行权利要求1至12中任一项所述的图形编程作品检查方法的步骤。

16.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序运行时执行权利要求1至12中任一项所述的图形编程作品检查方法的步骤。