model - 模型驱动开发：什么是转换？

Question

据我了解，模型驱动开发（MDD）允许自动化程序/模型通过应用转换从其相应模型自动生成。

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

但究竟什么是转型？

Answer 1

（程序）转换是给定程序表示实例的函数，计算另一个。

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

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

通常，（全局）程序转换可能会影响整个表示，即使它很大，但通常单个转换仅修改一小部分，而将大部分程序表示单独保留。抽象地，整个程序表示实例被转换处理以产生另一个全新的程序表示实例。由于表示实例往往很大，这通常通过让转换简单地修改现有表示实例来实现。您可以将此类“小”转换视为具有附加参数，这些参数将它们集中在它们将对其进行更改的表示的特定部分。

像数学函数一样，转换组合产生“更大”的转换（也是部分的，因为条件也组合）。通常您编写一组转换来完整地转换程序表示，因为没有一个转换会在一个步骤中处理整个表示实例。您可以组合它们的事实允许您编写许多共同实现您的目的的“小”转换，因此您在语义翻译中获得了一种模块化，这就是人们喜欢程序转换的想法的原因。

与数学函数一样，您可以通过编写程序代码来实现此类转换。这样的代码检查原始模型的一些部分，并在模型运行时对其进行更改，但这通常很尴尬。

因此，此类转换通常以所谓的“声明性”形式编写为包含一对模式和条件的规则. 每个规则都被解释为“如果您看到左侧模式，并且条件匹配，则更改程序表示以匹配右侧模式”。模式变量允许模式指定原始程序表示的块以不受影响地通过转换（通常由一些其他转换处理）。虽然这些规则被称为“声明性”（因为它们看起来不像传统代码），但它们只是表示一些等效的功能，因此在预期的意义上不是声明性的。规则往往比等效的过程代码更具可读性，这通常是因为模式是用源和目标表示的表面语法编写的。

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

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

Answer 2

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

除了模型，模型转换代表了 MDD 的另一个关键要素，并允许定义不同模型之间的映射。转换是在源模型和目标模型之间执行的，但实际上是在各自的元模型上定义的。

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

MDE为定义模型转换提供了适当的概念语言（例如，QVT或ATL），从而为设计者提供指定转换规则的优化解决方案。显然，由于最终模型被编码为文件，因此可以考虑使用通常的命令式编程语言来对抗它们的转换。但是，这会降低整个建模框架的抽象级别，并且通常会导致生成繁琐且无法维护的软件。

Answer 3

模型驱动开发的转变是我们在处理模型时得到的输出。此输出可以是另一个模型或源代码。

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

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