Verification of Model Transformations A Survey of the State-of-the-Art 模型转换的验证 对现状的调查

模型驱动工程范式认为软件开发生命周期由工件（需求规范、分析和设计文档、测试套件、源代码）支持，这些工件是表示要构建的系统不同视图的模型。存在一个由模型转换驱动的（半）自动构造过程，从系统的抽象模型开始转换直到生成一个可执行的模型。

本文关注模型转换，尤其是它们的验证，要验证的最低要求是转换以及源模型和目标模型都是很好地形成的。通过一个案例研究来举例说明那些可以是在模型转换中可以验证方面以及如何验证它们。最后，我们得出结论，需要一个集成的环境来处理模型转换的异构验证。

我们首先在第2节中详细介绍了审查过程。然后，在第3节中，我们将快速查看模型转换并定义一个运行示例。

第二节是文献审查

这一节回答了用哪些策略处理模型转换的验证，以及试图解决什么样的问题？

该过程分为两个步骤进行：（a）电子数据库中的Web搜索；（b）对执行Web搜索结果的作者、会议和引用进行并行搜索。

第一步通过“模型转换”和“验证”以及它们的同义词构造一个搜索查询，在scopus、scienceDirect、Springer等数据库中搜索。

第二步寻找【2】中引用的论文以及确定与该主题相关的作者和会议来加强第一步。在作者的个人网页以及DBLP数据库中进行搜索，找到了一些技术报告和小会议材料，跟随一些作者工作的发展。

第三节是 模型迁移的简单介绍

MDE生态系统中所有东西都是模型，模型是系统或其环境的抽象。每个模型（包括元模型）都符合元模型。

模型，实例，元素，条件的表示方法

图一左侧是UML类图，介绍类，属性，关联，约束

图一右侧是关系模型，介绍表，列，主键，外键

模型转换也可以被视为模型，模型转换（基于面向数学的概念）与程序转换密切（采用面向对象的方法）相关又有不同

Klepe等人[51]对模型转换的定义：源模型--（规则）-->目标模型

图二介绍模型转换涉及到的模型以及它们的关系。

转换有多种，只考虑模型的转换。

模型转换可用的范围很广

模型转换有多种可变性：双向，多输入，多输出，策略可以是确定的，非确定的，交互的……

转换规则作为源元素和目标元素之间的数学关系

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

翻译

每一个传统的软件开发生命周期都由许多工件（例如需求规范、分析和设计文档、测试套件、源代码）支持，这些工件主要用作开发的指南以及与利益相关者的通信工具。
模型驱动工程（MDE，[49]）范式通过设想由工件驱动的软件开发生命周期将这种观点推向其极限，这些工件是表示要构建的系统不同视图的模型。它的可行性是基于存在一个由模型转换驱动的（半）自动构造过程，从系统的抽象模型开始转换直到生成一个可执行的模型。
因此，整个过程的质量很大程度上取决于模型和模型转换的质量。

我们关注模型转换，尤其是它们的验证。
从这个意义上说，在模型转换上需要验证的最低要求是转换以及源模型和目标模型都是很好地形成的。
然而，还有许多其他的特性可以验证，并且有很多的验证方法可以这样做。
本课题在[2]中被分析为一个三维问题，包括：涉及的转换、所涉及的特性以及用于建立特性的形式验证技术。

本文的目的是对[2]中扩展工作的模型转换验证的文献进行全面回顾。
特别是，我们引入第一维度但没有深入研究，因为有许多著名的著作[67,26]论述了这一主题，我们将第二和第三维度与[2]中未提及的其他方面进行了扩展。
我们还遵循一个基于问题的方法，通过一个案例研究来举例说明那些可以在模型转换中验证的感兴趣的方面以及如何验证它们。
最后，我们得出结论，需要一个集成的环境来处理模型转换的异构验证。

论文的其余部分结构如下。
我们首先在第2节中详细介绍了审查过程。
然后，在第3节中，我们将快速查看模型转换并定义一个运行示例。
在第4节中，我们介绍了必须验证的转换的不同方面，在第5节中，我们回顾了如何在文献中验证这些方面。
在第6节中，我们使用运行的示例来举例说明验证属性，并讨论如何对其进行验证。
最后，在第7节中，我们就这个主题发表了一些总结性的评论，并为今后的工作提供了指导。

 

2文献审查
文献综述遵循与系统综述方法相关的过程[50]。我们专注于回答这个问题：哪些策略被用来处理模型转换的验证，以及什么样的问题试图解决？

该过程分为两个步骤进行：（a）电子数据库中的Web搜索；（b）对执行Web搜索结果的作者、会议和引用进行并行搜索。

第一步首先确定关键词“模型转换”（与同义词“转换”）和“验证”（与同义词“验证”、“形式验证”、“验证”、“认证”），并构造一个搜索查询，该查询通过Timb'o Portal在某些选定的电子数据库中使用：scopus、scienceDirect、Springer、IEEE数字图书馆和ACM数字图书馆。
搜索应用于那些数据库中论文的标题、摘要和关键字，或者在那些不允许我们将搜索限制在这些字段的情况下的所有搜索字段。

第二步是通过寻找[2]中引用的论文，以及确定与该主题相关的作者和会议来加强第一步。
通过作者列表，我们在他们的个人网页以及DBLP数据库中进行了搜索。
这第二步帮助我们找到了一些技术报告和小会议材料，并允许我们跟随一些作者工作的发展。

纳入标准是基于对论文标题、摘要和关键词的回顾，评估他们是否以某种方式回答了最初的问题。
我们考虑了用英语和西班牙语写的论文。
这套最初的论文是通过阅读全文而加以完善的。
虽然有些论文由于没有经过严格的审查而出版，因此不能被认为是高质量的，但我们对它们的内容给予了特权，有利于回答最初的问题。
由于篇幅原因，我们这里不包括完整的文献综述。在[18]中可以找到这本著作的扩展版本以及每一篇论文的描述。

3 A Quick Look at Model Transformations

在MDE生态系统所有东西都是模型，甚至代码都被视为模型。在这种情况下，模型是系统或其环境的抽象。每个模型都符合元模型，即引入某种模型的语法和语义的模型。同样地，元模型符合某种元模型。元模型通常是自定义的，这意味着它可以通过自己的语义来指定。

元模型通常使用UML类图来定义[36]。但是，还有其他几种特定语言可用于此目的，例如元对象工具（mof，[35]）、为Eclipse建模框架定义的Ecore元模型（emf，[31]）和内核元模型（km3，[5]）。除了元模型定义了通常具有具体语法的建模语言之外，还可以使用与元模型相同的语言表示模型。此外，对于表示模型实例以及作为元模型“实例”的模型，UML对象图提供了图形表示。最后，层次结构中的每个元素都可以使用XML元数据交换（XMI，[39]）来表示。在某些情况下，有一些条件（称为不变量）不能被这些语言的结构规则捕获，在这种情况下，建模语言由另一种逻辑语言补充，例如对象约束语言（ocl，[38]）

让我们介绍众所周知的类到关系模型转换作为一个运行示例，它最初在[10]中引入，已成为模型转换的实际标准示例。我们将使用如[47]所示的转换。图1左侧的元模型定义了UML类图，其中类可以包含一个或多个属性，可以属于一个类层次结构，并且可以声明为持久的。每个属性都有一个类型，可以是另一个类或基元数据类型（字符串、布尔值、整数等）。属性可以定义为主要属性。关联是在具有从源到目标方向的类之间定义的。附加的约束是每个类必须至少有一个属性和至少一个主属性（它们可以被继承）。

另一方面，关系模型符合图1右侧的元模型。每个模型都包含许多由许多列构成的表。其中一些列是对应表的主键。表可以与零个或多个外键关联。每个外键引用一个表，并与构成该键的许多列相关联。

MDE范式的第二个构建块是模型转换，它也可以被视为模型。如[26]所述，模型转换与程序转换密切相关。“他们在各自转型社区的思维方式和传统、正在转型的主题以及正在考虑的要求方面存在差异。
虽然程序转换系统通常基于面向数学的概念，如术语重写、属性语法和函数编程，但模型转换系统通常采用面向对象的方法来表示和操纵其主题模型。

Klepe等人[51]定义模型转换如下：“转换是根据转换定义从源模型自动生成目标模型。转换定义是一组转换规则，它们共同描述如何将源语言中的模型转换为目标语言中的模型。转换规则是对如何将源语言中的一个或多个构造转换为目标语言中的一个或多个构造的描述。

如图2所示，从[6]中提取，模型转换基本上将符合给定源元模型mma的模型ma作为输入，并生成另一个符合给定的目标元模型mmb的模型Mb作为输出。模型转换可以定义为一个模型mt，mt本身符合模型转换元模型mmt。最后一个元模型以及mma和mmb元模型必须符合元模型（如mof或ecore）。转换定义由转换引擎执行。

这个模式定义了模型到模型的转换。还有模型到文本和文本到模型的转换，其中目标模型和源模型分别是不符合任何特定元模型的字符串。在不丧失一般性的情况下，我们将只考虑模型到模型的转换（从现在起只考虑转换，或模型转换）。

在不丧失一般性的情况下，我们将只考虑模型到模型的转换（从现在起只考虑转换，或模型转换）。
正如在[67,66]中指出的，“这一定义非常普遍，涵盖了模型转换可用于的广泛活动：自动代码生成、模型合成、模型演化、模型模拟、模型执行、模型质量改进（例如通过模型重构）、模型转换、基于模型的测试、模型检查，模型验证。

然而，这个模式可以扩展，正如在[26]中详细研究的那样。撇开细节不谈，作者识别了一个模型转换的多种可变性，例如它可以是双向的，可以以多个源模型作为输入和/或生成多个目标模型作为输出，其规则应用策略可以是确定性的、非确定性的或交互的，源模型和目标模型可以是不同的抽象级别（水平与垂直转换），源模型和目标模型是否符合相同的元模型（内生与外生转换）。

除了这些方面之外，还有几种用于定义和执行模型转换的方法，从直接操作中转换，通常是在编程语言中开发的，这些编程语言访问模型的内存表示（例如Java元数据接口[27）]到相关的（又名声明性）。
转换规则作为源元素和目标元素之间的数学关系（例如，查询/视图/转换（QVT）关系[37]），通过基于图的转换，该转换包括将模型视为类型化的属性标记图，并应用图转换技术（例如，属性图语法[83]）。

在我们的运行示例中，转换基本上描述了如何将持久化类转换为表。 类的属性和关联被转换为相应表的列，并且主键和外键也被适当地设置。 主键定义为定义为primary的属性，以及用于与其他类关联的外键，包括类层次结构中的类。 下面我们使用ATL声明表示法显示持久化类到表规则的定义。转换使用预处理步骤，该步骤使层次结构中的类的特征（属性或传出关联）变平。 使用此中间结构，更容易定义规则，如下面的规则将持久化类映射到表