[发明专利]一种基于PRDL规则描述语言的C程序代码规范检查装置

说明书

本发明提供一种基于PRDL规则描述语言的C语言代码规范检查装置及其检查方法，代码规范检查装置包括五个功能模块：规则解析器，程序解析器，规则检查引擎，缺陷报告器，用户交互接口。其中，规则解析器由语义解析器和查询优化器两个子功能模块组成，负责解析PRDL规则语义生成初始逻辑查询计划，再对该计划进行重写优化。程序解析器由代码行解析器、标记流解析器、语法树解析器三个子功能模块所组成，负责对源代码进行文本特征抽取和结构特征抽取，将抽取得到的三个层次(代码行、标记、语法树)的模型融合成C程序模型。本发明对用户选择或定义的PRDL规则进行语义解析，从而获取违背规则的缺陷代码相关信息，将检查结果报告给用户进行审核与评估。

技术领域

本发明涉及到检查C语言程序代码规范的技术，特别涉及到基于PRDL语言的结构化查询以及C程序的多模型融合表征，属于基于规则的静态分析技术。

背景技术

静态分析是保证软件质量的重要手段。通过扫描分析应用程序的源代码，可以在软件开发的早期阶段就发现一些潜在的缺陷。代码规范检查装置属于基于规则的静态分析工具。这类工具通过将源代码或是源代码经过分析得到的产物与描述缺陷的规则进行词法或语法上的匹配，发现违反规则的情形。常见的工具有CheckStyle，PMD，C++test等，下面对这些软件进行简介：

CheckStyle：一款帮助开发者写出遵循某些规范Java代码的静态检测工具。Checkstyle内嵌了对Sun Code Conventions和GoogleJavaStyle这两种代码规范的支持，用户可以通过自定义配置来实现对其他代码规范的支持。然而，自定义Checkstyle的检查规则并不是一件简单的事，用户需要做的不是描述一条规则，而是用代码实现对这条规则的检查，包括检查器、过滤器、监测器这三个组件。检查器是用来实现规则检查这一主要功能的，用户需要做遍历语法树等比较底层的事情，然后还要细化一系列检查器属性，把检查器作为插件整合进Checkstyle主体程序中。过滤器的功能是决定哪些事件可以通过检查器被报告给监测器，用户一般需要实现其中的accept(AuditEvent)方法。监测器监听检查器在检查代码过程中的行为，包括开始检查一个文件，发现了违反规则的情况等，然后做出适当的响应，比如输出错误信息等。当然过滤器和监听器要也与Checkstyle主体程序进行相应整合，只有完成所有这些步骤，才算是成功添加了一条规则。

PMD：面向Java语言的静态检测工具，可以检查出一些潜在的缺陷，比如死代码，未经优化的代码，过于复杂的表达式，重复代码等。PMD支持两种自定义规则的形式，一种是调用API写Java代码，过程和Checkstyle类似；另一种是使用XPath查询语言写规则，当XPath查询找到了匹配结果，就将它作为违反规则的情形加入报告中。之所以能这么做，是因为Java源代码可以被解析成抽象语法树(AST)这一树形结构。AST可以被视作结构化文档，正如XML一样，因而可以通过XPath查询以寻找特定模式。在PMD中使用XPath写查询可以分为以下几步：1.在工具中写出想要查找的Java代码；2.掌握代码对应的抽象语法树结构；3.写出匹配查询模式的XPath表达式；4.不断修改代码并返回第2、3步完善XPath表达式。举例来说，如果用户希望找到局部变量，可以使用表达式“//LocalVariableDeclaration”，可以看出以这种方式定义规则比较简洁清晰。

C++test：一款商业化软件测试工具。C++test能够做包括代码规范检查在内的代码静态检测，还具有数据流分析和单元测试生成等许多功能。除了使用C++test规则库中的GJB 5369-2005，JSF，MISRA-C等代码规范，用户还可以通过C++test提供的规则编辑工具RuleWizard在图形化界面中自定义规则。用户使用RuleWizard的各种组件将规则描述为一种代码模式，该模式如果出现在代码中就将被规范检查引擎检测到并报告。由于集合、触发器等概念的存在，使得C++test尽管采用了图形化的规则描述方式，但是规则的语义依然不清晰。使用RuleWizard来编写规则学习门槛高，且在编辑完成新的规则后很难判断规则描述是否与需求相符。