29、UML 模型测试与调试：EPTUD 插件与嵌入式系统调试平台

UML 模型测试与调试：EPTUD 插件与嵌入式系统调试平台

1. UML 设计模型测试：EPTUD 插件介绍

1.1 背景与需求

在模型驱动开发中，验证模型的技术至关重要。许多软件故障出现在设计阶段，因此需要有效方法来查找和消除设计模型中的错误。目前，UML 设计模型的评估多采用人工的走查、检查等非正式方法，这些方法繁琐、易出错且效率低下。

1.2 测试方法概述

• 假设条件 ：假设 UML 图语法正确，可由 UML 绘图工具自动检查；假设被测模型仅描述顺序行为。
• 活动图中的操作类型 ：包括调用操作、计算、创建和销毁对象、创建和销毁链接、读写链接、读写变量等操作。
• 信息用途 ：类图和序列图信息用于评估测试充分性，类图和活动图信息用于获取设计模型的可执行形式。

1.3 测试流程

graph LR
    A[UML DUT] --> B[生成测试用例以满足测试充分性标准]
    B --> C[测试用例]
    A --> D[生成 DUT 的可执行形式]
    D --> E[添加测试脚手架]
    E --> F[可执行 DUT (EDUT)]
    F --> G[添加测试脚手架以获得可测试 DUT (TDUT)]
    C --> H[执行测试]
    G --> H
    H --> I[测试结果]

• 测试用例 ：由前缀 P、系统事件序列 E 和预言 O 组成。前缀 P 用于将系统从初始配置转换到期望的测试起始配置；系统事件序列 E 是一系列操作调用；预言 O 是一系列元组 (oi, ei)，用于定义系统的预期行为。
• 可执行形式转换 ：利用设计的结构（类图）和动态（活动图）视图信息将 DUT 转换为可执行形式 EDUT。
• 测试脚手架 ：添加到 EDUT 以获得可测试形式 TDUT，包括测试驱动程序和检测测试失败的代码。
• 测试执行与失败报告 ：使用生成的测试输入执行 TDUT，观察活动图建模的系统行为对配置的影响。在每次系统事件执行后，检查相应的预言条件 oi。如果测试过程中产生的配置违反类图约束或任何条件 oi 为假，则报告失败。

1.4 Eclipse 插件实现

• 模型规格说明 ：使用 Omondo EclipseUML 插件绘制类图和序列图，使用 Java 类动作语言 (JAL) 描述操作行为，开发者使用 ecore 系统编辑器指定操作和 OCL 约束。
• 可执行和可测试形式生成
  • UML 元素转换 ：UML 类、属性和操作转换为 Java 类、状态变量和方法声明。为每个类 C 生成集合类 SetOfC，用于处理关联端多重性大于 1 的情况。
  • TFactory 类 ：从类图生成，具有创建和销毁类图中每个类和关联实例的公共方法。
  • 活动图转换 ：活动图转换为 Java 方法体，遵循以下规则：
    1. 调用操作转换为 Java 方法调用。
    2. 返回操作转换为返回语句。
    3. 创建对象操作转换为 Java 对象创建语句。
    4. 从活动条件和迭代结构分别导出 Java 条件和循环结构。
    5. 对象（或链接）创建和销毁操作转换为 TFactory 中方法的适当调用。
  • 脚手架添加 ：添加到 EDUT 以获得 TDUT，包括测试驱动程序和检测测试失败的代码。失败检测检查以下条件：
    1. 条件中未初始化的变量。
    2. 操作调用中未初始化的参数。
    3. 操作调用的目标对象不存在。
    4. 方法执行前的前置条件为假。
    5. 方法执行后的后置条件为假。
    6. 系统事件执行产生的对象配置违反类图约束。
       前三个检查由插入 EDUT 的代码执行，后三个检查使用 USE 工具。EPTUD 将 DUT 转换为 USE 格式。
• 测试执行与失败报告 ：使用生成的测试输入执行 TDUT，EPTUD 向 USE 提供 OCL 中指定的前置和后置条件，并请求 USE 在每个操作执行前后进行验证。在每个系统事件执行后，EPTUD 通知 USE 检查对象配置是否符合类图约束。

2. 嵌入式系统中执行 UML 模型的调试平台

2.1 调试背景

在模型驱动开发中，将模型自动转换为可执行代码需要新的基于模型的调试和监控方法。传统的源代码调试器在处理自动生成的代码时无法提供合适的视图，而模拟对于嵌入式系统来说也并非总是可行，因为嵌入式系统有严格的时序约束，且与环境和外设硬件交互频繁。

2.2 调试方法与平台架构

graph LR
    A[UML 模型] --> B[GeneralStore 生成源代码和可执行文件]
    B --> C[目标平台执行可执行文件]
    C --> D[驱动层抽象调试接口]
    D --> E[调试场景实现调试功能]
    E --> F[可视化层展示调试信息]
    G[UML 工件映射层] --> D
    G --> E

• 系统建模与代码生成 ：使用 UML CASE 工具建模系统，GeneralStore 从 UML 类图和 UML 1.5 动作生成源代码并构建可执行文件。针对嵌入式系统，可生成 C/C++ 或 Java 代码。
• 目标平台与调试接口 ：可执行文件在目标平台上运行，目标平台需提供调试接口，如 GNU 调试器 (GDB)、Java 虚拟机调试接口 (JDI) 或硬件支持的调试器接口。为抽象实际目标，定义驱动层包装各种调试器实现。
• 调试场景与可视化 ：从顶层看，有各种调试场景实现监控和调试系统所需的功能。这些场景将系统状态或系统跟踪转换为各种图表，通过可视化层展示给用户。每个场景提供基于 UML 图交换的图表模型，实现可视化数据的标准化序列化。
• UML 工件映射层 ：负责将建模元模型中的工件映射到源代码级别的工件（如变量、代码行等）。映射分两个阶段完成，底层将模型级别的查询转换为源级别的查询，上层为每个考虑的建模工件提供查询实现。

2.3 原型实现与未来工作

• 原型实现 ：正在实现一个 Java 原型，可使用 UML 对象图监控执行模型中类的实例及其关系。设计流程包括导入 UML 类模型到 GeneralStore，生成可运行的可执行文件，通过 GDB 执行调试对象并在类模型定义的断点处停止。从任何对象开始构建对象模型，迭代处理属性和关联，重新生成目标代码并查询 GDB 评估表达式，将获得的值重新映射到模型数据类型并添加到插槽中。使用全自动布局和路由从模型构建图表信息，并在 Eclipse 中基于图形编辑器框架 (GEF) 展示图表。
• 未来工作 ：关注更通用的实现，改进可视化层，实现更高级和增量式的布局和路由。构建平台后，将开发更多调试场景并集成到实际工具中，同时考虑异构建模系统的跨元模型调试。

3. UML 设计模型测试与调试的综合分析

3.1 测试与调试的关键技术点对比

技术方面	UML 设计模型测试（EPTUD 插件）	嵌入式系统 UML 模型调试
输入来源	UML 设计模型（类图、序列图、活动图）	UML 模型（使用 UML CASE 工具建模）
转换目标	转换为可执行的 Java 代码	生成源代码（C/C++ 或 Java）和可执行文件
调试/测试手段	测试用例生成、测试脚手架添加、USE 工具辅助检查	驱动层抽象调试接口、调试场景实现、UML 工件映射
可视化方式	未提及可视化	使用 UML 对象图监控实例及关系

通过这个表格可以清晰地看到，UML 设计模型测试主要侧重于将 UML 模型转换为可测试的代码并进行测试用例的执行和检查；而嵌入式系统 UML 模型调试则更注重在不同平台上对模型执行的调试，并且强调了可视化的重要性。

3.2 操作流程总结

UML 设计模型测试（EPTUD 插件）操作流程

1. 模型绘制与规格说明 ：
   • 使用 Omondo EclipseUML 插件绘制类图和序列图。
   • 用 Java 类动作语言 (JAL) 描述操作行为。
   • 开发者使用 ecore 系统编辑器指定操作和 OCL 约束。
2. 可执行和可测试形式生成 ：
   • 将 UML 类、属性和操作转换为 Java 类、状态变量和方法声明。
   • 生成集合类 SetOfC 处理关联端多重性。
   • 从类图生成 TFactory 类。
   • 把活动图按规则转换为 Java 方法体。
   • 添加测试脚手架到 EDUT 得到 TDUT。
3. 测试执行与失败报告 ：
   • 生成测试用例。
   • 执行 TDUT，EPTUD 向 USE 提供条件并请求验证。
   • 检查对象配置是否符合类图约束，报告失败情况。

嵌入式系统 UML 模型调试操作流程

1. 系统建模与代码生成 ：
   • 使用 UML CASE 工具建模系统。
   • GeneralStore 从 UML 类图和 UML 1.5 动作生成源代码和可执行文件。
2. 目标平台与调试接口准备 ：
   • 可执行文件在目标平台运行，目标平台提供调试接口。
   • 驱动层包装各种调试器实现。
3. 调试与可视化 ：
   • 调试场景实现调试功能。
   • UML 工件映射层完成工件映射。
   • 可视化层展示调试信息。

3.3 技术难点与挑战

UML 设计模型测试

• 代码转换的准确性 ：将 UML 模型转换为 Java 代码时，需要确保转换规则的准确性，特别是活动图转换为 Java 方法体时，不同的操作转换需要严格遵循规则，否则可能导致代码逻辑错误。
• 测试用例的生成 ：如何生成有效的测试用例以满足测试充分性标准是一个挑战，需要综合考虑类图、序列图和活动图的信息。

嵌入式系统 UML 模型调试

• 跨平台调试 ：不同的目标平台有不同的调试接口，驱动层需要抽象这些接口，确保调试功能的通用性。
• UML 工件映射 ：将建模元模型中的工件映射到源代码级别的工件是一个复杂的过程，需要考虑不同的转换方式和建模域。

4. 总结与展望

4.1 总结

UML 设计模型测试和嵌入式系统 UML 模型调试是模型驱动开发中不可或缺的环节。EPTUD 插件为 UML 设计模型的测试提供了一种有效的方法，通过将 UML 模型转换为可执行代码并进行测试用例的执行和检查，可以发现设计模型中的故障。而嵌入式系统 UML 模型调试平台则针对嵌入式系统的特点，提供了一种基于模型的调试和监控方法，通过抽象调试接口、实现调试场景和进行 UML 工件映射，帮助开发者更方便地调试自动生成的代码。

4.2 展望

• 可视化增强 ：无论是 UML 设计模型测试还是嵌入式系统 UML 模型调试，都可以进一步增强可视化功能。例如，在 EPTUD 插件中可以增加动画序列图来可视化测试执行过程，在嵌入式系统调试平台中可以提供更多类型的可视化图表。
• 测试输入生成技术 ：在 UML 设计模型测试中，开发更有效的测试输入生成技术可以提高测试的覆盖率和效率。
• 跨元模型调试的完善 ：对于异构建模系统的跨元模型调试，需要进一步研究和完善相关技术，以满足日益复杂的系统开发需求。

通过不断地改进和完善这些技术，我们可以更好地应对模型驱动开发中的挑战，提高软件系统的质量和可靠性。