模型驱动的开发:什么是转换？

Question

据我所知，模型驱动开发(MDD)允许自动化，从而通过应用转换从相应的模型自动生成程序/模型。

关于转换，我只知道它们是存储开发人员特定于平台的专业知识的某种方式。

但是，到底什么是转换？

Answer 1

(program) 是一个函数，给定一个程序表示实例，计算另一个实例。

程序表示可以是任意的，但通常是抽象语法树(AST)或图(例如，UML)；您甚至可以包含字节码作为程序表示。像数学函数一样，变换可以是“部分的”(即，只在一些可能复杂的条件下工作)。

我个人喜欢术语“变换”指的是函数本身，而“变换”指的是应用变换以获得新表示的行为或结果。

通常，(全局)程序转换可能会影响整个表示，即使它是巨大的，但通常单个转换只修改了一小部分，而不影响大多数程序表示。抽象地说，整个程序表示实例由转换处理以产生另一个全新的程序表示实例。由于表示实例往往很大，这通常是通过让转换简单地修改现有表示实例来实现的。这样的“小”转换，你可以认为是有额外的参数，将它们集中在表示的特定部分，他们将对其进行更改。

与数学函数一样，转换也会产生“更大的”转换(也是局部的，因为条件也是这样组成的)。通常，您可以编写一组转换来转换整个程序表示，因为没有一个转换会在一个步骤中处理整个表示实例。事实上，你可以组合它们，允许你编写大量的“小”转换，这些转换共同实现了你的目的，所以你在语义转换中获得了一种模块化，这就是为什么人们喜欢程序转换的想法。

与数学函数类似，您可以通过编写过程代码来实现此类转换。这样的代码检查原始模型的一小部分，并在运行时产生对模型的更改，但这通常是笨拙的。

因此，这样的转换通常是以所谓的“声明性”形式编写的，即 which contain a pairs of and a 。每个规则都被解释为：“如果您看到左侧模式，并且条件匹配，则更改程序表示以匹配右侧模式”。模式变量允许模式指定原始程序表示的块原封不动地通过转换(通常由其他转换处理)。虽然这些规则被称为“声明性”(因为它们看起来不像传统代码)，但它们只是表示一些等价的函数，因此并不是预期意义上的声明性。规则往往比等效的过程代码更具可读性，这通常是因为模式是用源和目标表示的表层语法编写的。

作为一个实际问题，单独的转换只适用于表示中的特定位置，并且它们的应用顺序(“组合”)很重要。为了处理这个问题，(编程)转换工具通常提供一种“元编程”的方法来控制焦点和规则应用顺序。

这些想法适用于所谓的“模型驱动的开发”，它只是将转换应用于有争议的高级模型，以生成低级代码，或将低级代码转换为其他低级代码。您甚至可以使用这些想法来构建反向工程工具，例如，将低级代码映射到一些抽象模型。我们的DMS Software Reengineering Toolkit是一个程序转换工具，具有过程性转换和源到源的重写，用于所有这些目的。

Answer 2

MDD的核心开发流程是从应用程序模型向下到运行中的实现，通过后续的模型转换。这允许模型的重用和系统在不同平台上的执行。实际上，在实现级别上，运行的软件依赖于特定的平台(定义为特定的应用程序域)来执行它。

除了模型之外，模型转换还代表了MDD的另一个重要组成部分，并允许定义不同模型之间的映射。转换是在源模型和目标模型之间执行的，但它实际上是在各自的元模型上定义的。

模型转换可以分类为：-模型到模型的转换-模型到文本的转换(用于生成软件代码、文档或其他文本工件)。

MDE为定义模型转换提供了合适的概念性语言(例如QVT或ATL)，从而为设计人员提供指定转换规则的优化解决方案。显然，由于模型最终被编码为文件，因此可以考虑使用通常的命令式编程语言来定义它们的转换。然而，这降低了整个建模框架的抽象级别，通常最终会产生繁琐且不可维护的软件部分。

Answer 3

模型驱动开发中的转换是我们在处理模型时得到的输出。这个输出可以是另一个模型，也可以是源代码。

在MDA (模型驱动架构)方法中，我们可以通过转换过程将PIM (平台无关模型)转换为PSM (平台特定模型)。然后，我们可以再次通过后续转换将PSM转换为源代码。

其他一些方法，如ABSE，将模型直接转换为源代码。在这里，ABSE模型直接生成最终的源代码，因为它的模板作为小程序工作(在协作类型的生成器中)：不需要进一步的转换。像大多数其他MDD方法一样，ABSE需要工具支持。在本例中，它是AtomWeaver。