52、图变换与抽象在软件验证及类型检查中的应用

图变换与抽象在软件验证及类型检查中的应用

1. 图程序相对于HR+条件的正确性

随着软件系统复杂度的增加，对能直观呈现系统全貌的设计概念需求日益增长，图变换系统便是一种强调数据结构互连的可视化建模方法。系统状态用图来建模，系统状态的变化由图程序描述，而系统的结构属性则由图条件描述。

以往研究中，嵌套图条件被引入，它增强了图上的一阶逻辑，且与一阶图属性在表达能力上等价，但只能表达Gaifman意义下的局部属性。然而，许多现实世界的属性是非局部的，比如“节点1到节点2存在路径”、图的连通性或无环性等，这些属性无法用嵌套图条件表达。

为解决这一问题，提出了HR+条件。将超边替换系统与嵌套图条件相结合形成HR条件，图中加入超边变量，再根据超边替换系统用图替换这些变量，进一步处理子图便得到HR+条件。通过超边替换，HR+条件能够表达非局部属性，且比图上的一元二阶公式更具表达力。

例如，HR+条件 $\exists(\bullet \bullet 1 2 +)$ ，其超边替换系统为 $+ ::= \bullet \bullet 1 2 | \bullet \bullet \bullet 1 2 +$ ，对于所有节点1和节点2之间存在路径的图都能满足。

再以“汽车编队”为例，为节省高速公路车道空间和燃油，同向行驶的汽车组成编队，每队有且仅有一个领导者（用小 $\alpha$ 表示）和任意数量的追随者，该属性可由条件 $\forall \left( \exists \left( \alpha + \right) \right) \land \lnot \left( \exists \left( \alpha \alpha + \right) \right)$ 表示。

对于有限图，判断图 $G$ 是否满足HR+条件 $c$ 的问题是可判定的。一种简单的方法是，对于条件 $c$ 中的每个超边，推导出相应替换系统允许的每个图，得到的条件将是嵌套图条件，其满足性问题是可判定的。由于每个超边替换系统都可转换为单调系统，且生成的图大于 $G$ 的条件不可能满足，所以需要检查的嵌套图条件数量是有限的。

HR+条件可与图程序结合，以Hoare三元组 ${pre, Prog, post}$ 的形式构建图规范。目标是检查该三元组的正确性，即对于所有满足前置条件 $pre$ 的图 $G$ ，以及对 $G$ 应用程序 $Prog$ 得到的所有图 $H$ ， $H$ 是否满足后置条件 $post$ 。通过Dijkstra的方法，从程序和后置条件构建最弱前置条件，将后置条件转换为程序的右HR+应用条件，再从右应用条件转换为左应用条件，最后从左应用条件转换为最弱前置条件。正确性问题可归结为前置条件是否蕴含最弱前置条件。还计划扩展ENFORCE框架及其定理证明组件以支持HR+条件。

以下是相关操作步骤的总结：
1. 判断图是否满足HR+条件 ：
- 对于条件 $c$ 中的每个超边，推导相应替换系统允许的所有图。
- 得到嵌套图条件，利用其可判定性进行满足性检查。
2. 检查Hoare三元组正确性 ：
- 从程序和后置条件构建最弱前置条件：
- 将后置条件转换为右HR+应用条件。
- 从右应用条件转换为左应用条件。
- 从左应用条件转换为最弱前置条件。
- 判断前置条件是否蕴含最弱前置条件。

为展示研究结果的实际价值，将进行多个案例研究：
- 使用HR+条件和图程序验证汽车编队协议。
- 将HR+条件应用于C++模板实例化问题，通过图进行模板类型检查，并以图的形式输出类型错误及补救建议。
- 用HR+条件表达和检查UML图的OCL约束，结合UML元模型到图文法的转换，生成带约束的元模型实例。

2. 模型转换程序的静态类型检查

模型转换是模型驱动开发过程的关键元素，用于形式模型分析、代码生成等任务。随着模型转换复杂度的增加，确保转换程序的正确性变得愈发困难，而错误检测至关重要，因为错误可能会传播到目标应用程序中。

目前有多种分析方法用于模型转换的验证，基于定理证明的方法可证明基于图的模型上的语句有效性，模型检查在验证动态属性方面有前景，但需要抽象来克服无限状态空间的挑战。此外，静态分析技术用于验证静态属性，如将图变换系统展开为Petri网，或使用两层抽象解释。

本文提出一种针对部分类型化模型转换程序的静态分析方法，用于早期检测类型错误。像Viatra2这样的转换语言通常是部分类型化的，常见做法是使用静态类型（编译时检查）的图变换规则和动态类型（运行时检查）的控制结构。动态类型部分缺乏静态类型强制，导致类型错误常见且难以追踪，而静态部分则允许高效的类型推断。

2.1 类型安全作为约束满足问题

将转换程序的类型安全评估视为约束满足问题（CSP）。为转换程序中每个变量的每个潜在使用创建一个CSP变量，其域为类型系统的元素。约束由转换程序的语句创建，表达从语言规范中可推断的类型信息（如条件具有布尔类型）。

评估CSP后，检查两种类型的错误：
- 类型错误表现为CSP违反。
- 通过比较转换程序变量的不同CSP变量表示来识别变量类型变化，若存在不一致则发出警告（尽管有些情况可能是有效的，但通常是错误的）。

2.2 分析过程

静态分析的输入是转换程序和程序使用的元模型，输出是发现的错误列表。需要注意的是，实例模型（转换程序的输入）在静态分析过程中不被使用。分析过程如下：
1. 类型系统识别 ：收集转换程序中使用的所有可能类型，类型系统由元模型元素和内置类型（如字符串、整数）组成。为减小类型系统的规模，对元模型进行修剪，使其成为转换程序中使用类型的超集。类型系统包含直接从转换程序引用的所有元素、它们的所有父元素，以及关系的端点和逆关系。
2. 准备类型系统 ：为类型系统的每个元素分配一个唯一的整数集，以便高效计算子类型关系。
3. 分析步骤 ：遍历转换程序，构建并评估约束满足问题。使用多次遍历迭代来覆盖转换问题的不同执行路径。为提高性能，采用模块化遍历，分别遍历图变换规则和图模式，将规则（或模式）的部分分析结果描述并存储为前置条件和后置条件，基于“契约式设计”方法。为每个规则（或模式）的引用创建契约后，使用契约生成相关约束，而不是重新遍历引用的规则。控制结构的遍历也采用类似的模块化方法。
4. 解决CSP ：使用任意有限域CSP求解工具解决创建的CSP。结果用于构建类型契约和提供错误反馈。规则（或模式）的类型契约保存方法开始和结束时参数的计算类型，前置条件和后置条件的差异意味着参数变量的类型发生了变化。
5. 错误反馈 ：查找类型错误和类型变化，并将它们反向注释到转换程序中。在遍历过程中同时评估CSP，以便关联上下文信息和相关代码段。

该方法已在Viatra2转换框架中实现，并使用不同大小的转换程序进行了评估。初步评估显示，类型检查器对于早期错误识别很有用，能够识别与变量交换或模式调用相关的错误。

以下是分析过程的流程图：

graph TD;
    A[转换程序和元模型] --> B[类型系统识别];
    B --> C[准备类型系统];
    C --> D[分析步骤];
    D --> E[解决CSP];
    E --> F[错误反馈];

后续计划评估静态程序切片方法在模型转换程序中的应用，这将有助于生成有意义的跟踪信息，以定位转换程序中可能出错的部分，还可用于扩展系统的验证选项，如死代码分析和使用 - 定义分析。

图变换与抽象在软件验证及类型检查中的应用

3. 使用图变换和图抽象进行软件验证

在软件验证领域，对于用命令式编程语言编写的软件，提出了一种基于图转换系统（GTS）模型检查的验证方法。该方法将每个程序状态建模为图，通过图变换规则指定探索引擎。图变换适合对具有动态内存分配的语言的执行语义进行建模，同时为研究图抽象提供了清晰的环境，有助于缓解模型检查中固有的状态空间爆炸问题。

3.1 验证周期概述

整个验证周期的输入是程序源代码，具体流程如下：
1. 生成抽象语法图（ASG） ：代码由编译器分析，输出ASG。ASG是语言解析器生成的抽象语法树，丰富了类型和变量绑定信息。
2. 构建流图 ：ASG和语言控制流语义定义作为流构建机制的输入，构建给定ASG的流图。流图表示程序执行点应如何在ASG中流动。
3. 形成程序图 ：ASG和流图共同构成程序图，是程序代码的可执行图表示。
4. 生成图转换系统（GTS） ：程序图作为探索性图变换系统的输入，该系统由捕获编程语言元素执行语义的图变换规则组成，生成程序图的状态空间作为GTS。
5. 进行抽象处理 ：由于生成的GTS通常过大甚至无限，使用抽象技术产生原始GTS的有限过近似。
6. 模型检查 ：对生成的GTS进行模型检查，检查程序是否满足给定的正确性属性。检查结果为判定程序正确或给出产生错误的执行路径反例。
7. 追踪错误 ：将反例追溯到ASG或输入代码，方便用户检查错误。

验证周期的流程图如下：

graph LR;
    A[程序源代码] --> B[编译器分析];
    B --> C[抽象语法图（ASG）];
    C --> D[流构建机制];
    D --> E[流图];
    C & E --> F[程序图];
    F --> G[探索性图变换系统];
    G --> H[图转换系统（GTS）];
    H --> I[抽象处理];
    I --> J[模型检查];
    J --> K[判定/反例];
    K --> L[追踪到ASG或代码];

使用GROOVE作为探索/模型检查引擎，它是专门用于图生成系统模型检查的工具。

3.2 图抽象机制

图抽象机制是验证方法的关键。在图变换领域已有相关理论研究，但实际实现较少。本文的图抽象基于形状分析和抽象解释的概念。

图形状是对一组具体图的抽象，代表其底层结构。图形状的每个节点（或边）标记有多重性，指示具体图中必须（或可能）存在的节点（或边）数量。此前的图抽象方法存在无法保留重要结构属性（如节点间连通性）的问题，而当前研究致力于开发能控制状态空间爆炸，同时允许验证现实程序中有趣属性的图抽象方法。

目前选择Java作为初始处理的编程语言，已开发出能从任何合法Java程序生成抽象语法图的图编译器。

以下是对上述验证过程的步骤总结：
|步骤|操作内容|
| ---- | ---- |
|生成ASG|编译器分析代码生成ASG|
|构建流图|结合ASG和控制流语义定义构建流图|
|形成程序图|ASG和流图构成程序图|
|生成GTS|程序图经图变换规则生成GTS|
|抽象处理|对GTS进行抽象得到有限过近似|
|模型检查|检查GTS是否满足正确性属性|
|追踪错误|将反例追溯到代码|

综上所述，通过图变换和图抽象进行软件验证，结合模型转换程序的静态类型检查以及图程序相对于HR + 条件的正确性研究，为软件的正确性验证提供了一套较为完整的方法体系。这些方法在不同场景下各有优势，相互补充，有望在实际的软件开发和验证中发挥重要作用。未来可进一步探索这些方法的优化和扩展，以适应更复杂的软件系统和验证需求。