将代码注释转换为过程规范( 三 ) _代码注释

3.2 特殊的后置条件@throws和@exception标记表示特殊执行的后置条件。让我们考虑以下来自 Apache Commons Collections 库的ClosureUtils类的摘录。

文章插图

? 第一个特殊的后置条件很简单，并且可以使用最新技术进行处理。但是，只有 Jdoctor 能够理解与容器中元素相关的属性，如第二条@throws注释中所示。
? Jdoctor 还处理更复杂的注释，例如以下注释，该注释来自 Apache Commons Collections 库的CollectionUtils类：

文章插图

尽管此注释描述的是无效条件，但现有技术无法产生正确的断言。Jdoctor 确定“两个集合”均指参数a和b，“比较器”指参数c 。
3.3 普通后置条件@return标记表示方法定期执行的后置条件，并且变化最大，因此最具挑战性。这是三个其他技术无法处理的示例。
? 第一个示例来自 Apache Commons Collections 库中的BagUtils类：

文章插图

? Jdoctor 使用在类Bag中声明的常量产生后置条件。将代码注释与要测试的代码中的方法或其他代码元素匹配并不总是那么简单，正如以下针对JGraphT库的Graph.addEdge（）方法的注释所说明的那样。

文章插图

? Jdoctor 推断“此图”是指图实例本身，并且containsEdge方法可以检查后置条件。Jdoctor 正确传递两个顶点作为此方法的参数以形成边。
? 将代码注释与代码元素匹配可能还需要一些语义相似性概念。从同一个 Graph 类中获取以下示例。

文章插图

? 由于 Jdoctor 新颖的语义相似性分析，Jdoctor 推断“未找到”在语义上与“容器中包含一个元素”的概念有关。@tComment 和 Toradocu 缺乏任何语义相似性分析，而 ALICS 仅支持有限数量的手动定义同义词。
4 JDOCTORJdoctor 将与构造函数和方法有关的 Javadoc 注释转换为可执行的 Java 表达式。它的主要见解是观察到，自然语言注释中的名词倾向于与代码中的变量或表达式相对应，注释中的动词/谓词与操作或方法相对应。Jdoctor 处理 Javadoc 前置条件（@param）、普通后置条件（@return）和特殊后置条件（@throws或@exception）。
Jdoctor 的工作分为四个步骤：
（1）文本规范化（第 4.1 节）：Jdoctor 对 Javadoc @ param、@ return、@ throws和@exception块标记中的文本进行预处理，以准备分析自然语言。此阶段包括几个文本转换，以方便后续步骤。
（2）命题识别（第 4.2 节）：Jdoctor 使用自然语言解析器来识别注释中每个子句的命题（主语-谓词对）。
（3）命题翻译（第 4.3 节）：Jdoctor 将每个识别的命题与 Java 元素（例如表达式或操作）匹配。此步骤是 Jdoctor 的核心，它依赖于模式，词汇和语义相似性匹配的组合。
（4）创建规范：Jdoctor 创建 Java 布尔表达式，该表达式对自然语言 Javadoc 注释进行编码。它用 Java 代码替换文本中的每个主题和谓词，并遍历解析树以创建合法的 Java 代码，包括方法调用，操作和布尔连接符（来自语法连接）。
4.1 文本规范化Javadoc 注释很少是语法上完整的英语句子。例如，他们经常缺乏标点符号，具有隐含的主语和/或动词，并且将数学符号与英语混在一起。当前的 NLP 解析器不能总是处理程序员编写的 Javadoc 注释样式。Jdoctor 通过在使用 NLP 解析器之前将其预处理为语法英语句来使文本可解析。这个阶段适当地扩展了先前的工作，并允许处理更多的 Javadoc 注释。
? 标点符号：Jdoctor 会在缺少句号时添加一个句号。它还消除了初始标点符号，这些标点符号是由于程序员（错误地）使用 Javadoc 注释中的逗号将参数或异常名称与其描述分开而产生的。
? 隐式主语：评论可能引用事先提及的主语。例如，典型的@param注释是“永远不会为空” 。由于 Jdoctor 孤立地分析句子，因此每个句子都需要一个明确的主题。对于@param注释，Jdoctor 在注释文本的开头添加参数名称。Jdoctor 还启发式地解析代词（例如“ it”），将其替换为注释中最后使用的名词。
? 隐式动词：某些注释具有隐式动词，例如“ @ param num，a positive number” 。Jdoctor 会根据被认为是主语的第一个名词是单数还是复数来添加“is”或“are“ 。