据我了解，模型驱动开发（MDD）允许自动化，通过应用转换，从相应的模型自动生成程序/模型。
我所知道的有关转换的一点是，它们是存储开发人员特定于平台的专业知识的一种方式。
但究竟什么是转型？
答案 0 :(得分：4)
(program) transformation是一个给出程序表示实例的函数，计算另一个。
程序表示可以是任意的，但通常是抽象语法树（AST）或图形（例如，UML）;你甚至可以包含字节码作为程序表示。与数学函数一样，变换可以是“部分的”（即，仅在某些[可能复杂]条件下工作）。
我个人喜欢术语 transform 来引用函数本身，而 transformation 则引用应用变换来获取新表示的行为或结果。< / p>
通常，（全局）程序转换可能会影响整个表示，即使它很大，但通常单个转换只会修改一小部分而只留下大部分程序表示。抽象， 整个程序表示实例由转换处理，以产生另一个全新的程序表示实例。由于表示实例往往很大，因此通常通过使转换简单地修改现有的表示实例来实现。 您可以将这种“小”转换视为具有其他参数，这些参数将它们集中在它们将对其进行更改的表示的特定部分。
与数学函数一样，转换构成了“更大”的转换（也是部分的，因为条件也构成）。通常，您编写一个 set 转换来完整地转换程序表示，因为没有一个转换将在一个步骤中处理整个表示实例。您可以编写它们的事实允许您编写大量“小”转换，这些转换共同实现了您的目的，因此您在语义转换中获得了一种模块化，这就是人们喜欢程序转换的想法。
与数学函数一样，您可以通过编写过程代码来实现此类转换。这样的代码检查原始模型的位，并在模型运行时产生变化，但这通常很难。
因此，这种转换通常以所谓的“声明”形式写成rules which contain a pairs of patterns and a condition。每个规则都被解释为“如果您看到左侧模式，条件匹配，则更改程序表示以匹配右侧模式”。模式变量允许模式指定原始程序表示的块以不受影响地通过变换（通常由某些其他变换处理）。虽然这些规则被称为“声明性”（因为它们看起来不像传统代码），但它们只代表一些等效函数，因此在预期意义上不具有声明性。规则往往比等效的过程代码更具可读性，通常是因为模式是用源和目标表示的表面语法编写的。
实际上，个别转换仅适用于表示中的特定位置，并且它们的应用顺序（“组合”）很重要。为了解决这个问题，（程序）转换工具通常提供了一种“元程序”来控制焦点和规则应用程序顺序的方法。
这些想法适用于所谓的“模型驱动开发”，它只是应用于可论证的高级模型以生成低级代码或将低级代码转换为其他低级代码的转换。您甚至可以使用这些想法来构建逆向工程工具，例如，将低级代码映射到某些抽象模型。我们的DMS Software Reengineering Toolkit是一个程序转换工具，具有程序转换和源到源重写，用于所有这些目的。
答案 1 :(得分：2)
MDD的核心开发流程是从应用程序模型到运行实现，再到后续的模型转换。这允许在不同平台上重用模型和执行系统。实际上，在实现级别上，正在运行的软件依赖于特定平台（针对特定应用程序域进行了默认）来执行。
除了模型，模型转换代表了MDD和MDD的另一个关键因素 允许在不同模型之间进行defyne映射。转换是在源模型和目标模型之间执行的，但它实际上是在相应的元模型上进行了修改。
模型转换可分为： - 模型转换模型 - 模型到文本转换（用于生成软件代码，文档或其他文本工件）。
MDE提供适当的概念语言（例如，QVT或ATL）用于defyning模型转换，以便为设计者提供指定转换规则的优化解决方案。显然，因为最后模型被编码为文件，人们可以认为使用通常的命令式编程语言来破坏它们的转换。然而，这降低了整个建模框架的抽象级别，并且通常最终会进入 制作繁琐且难以维护的软件。
答案 2 :(得分：0)
模型驱动开发中的转换是我们在处理模型时获得的输出。此输出可以是另一个模型或源代码。
在MDA（模型驱动架构）方法中，我们可以通过转换过程将PIM（平台无关模型）转换为PSM（平台特定模型）。然后，我们可以通过后续转换将PSM转换为源代码。
其他一些方法如ABSE将模型直接转换为源代码。这里，ABSE模型直接生成最终源代码，因为它的模板用作迷你程序（在协作型生成器中）：不需要进一步的转换。与大多数其他MDD方法一样，ABSE需要工具支持。在这种情况下，它是AtomWeaver。