模型间的转换是容易引起争论的主题，可能是因为没有很好地理解它们，也可能是因为它们在实际的模型驱动开发情况中的优点不是非常清晰。当然，这类似于“鸡和蛋”问题，因为缺少对底层问题和解决这些问题的机制的理解是如下方面的起源：缺少对在何处以及如何应用这些类型转换的理解。
使用OMG的查询（Query）/视图（View）/转换（Transformation）标准进行模型间的转换，这种标准也称为QVT。
一、历史
如同由OMG定义的那样，MDA指南通常讨论在不同抽象级别中不同模型之间的转换。在通过平台特有的模型（PSM）生成代码之前进行平台无关的模型（PIM）与平台特有的模型（PSM）的转换。这时就要用到QVT。
二、M2M语言需求
在深入研究QVT自身的细节之前，讨论以下内容将非常有帮助：关于模型间转换语言和其实现的一些更为重要并且或许较为不明显的需求：
- 大多数现实的模型间转换情况需要转换规则，从而能够查找其他转换规则已经计算的内容，因为每种规则通常只说明整个转换的一小部分。
- 除了在M2M抓还第一次运行时，用户很少会生成全新的模型。
- 转换隐式地或显示地定义源模型和目标模型之间的关系。
- 一般来说，转换的源模型可能非常大。
- 在许多使用情况中，通常是平台特有的目标模型可能需要由模型作者手工改变。
- 模型间的转换通常是在将源模型映射到目标模型时对其进行实质的结构变动。
- 是否支持双向转换是一种需求，这一点经常引起争论。
三、整体的体系结构
QVT规范由3种不同的模型间转换语言组成：Relations语言和Core语言是声明性的，而Operational。Mappings语言是强制性的。引入QVT的混合特性以容纳不同类型的用户，这些用户具有不同的需要、需求和习惯。如果考虑到对RFP的大量初始提交，每种提交对于QVT的使用和功能都具有不同的期望，则不会对这种策略感到惊讶。
QV T语言体系结构
在语义上根据Relations语言定义Relations语言。特别地，这是通过从Relations语言的MOF源模型到Core语言的MOF元模型的模型间转换模仿的。这种语义转换自身由Relations语言指定。
四、转换示例
ALMA元模型示例，该源模型可用于模仿天文观测数据。它提供了所有可能的工件上的平台无关抽象，ALMA软件基础结构需要这些工件。ALMA数据一种可能的平台无关具体化是关系数据库。在这种情况下，讨论ALMA元模型到简单关系数据库元模型的转换。
目标DB元模型是关系数据库表的简单重现。
QVT Relations语言是QVT的3种语言中的声明性成员。QVT Relations的用户必须将源元模型到目标源模型的转换描述为一组关系。转换执行意味着验证这些关系，然后在必要时通过操作目标模型实施这些关系。
Operational Mappings语言（OM）是QVT语言规范中的强制性成员。可以以混合的方式结合使用它与QVT Relations，或者独立使用它。出于示例的原因，只考虑独立使用的方法。
OPerational Mappings转换首先从转标题开始，该标题指定了转换的输入和输出模型。只可以在静态表明的方向上执行OM转换，因为它一般没有说明多个方向的转换。
五、OMG标准化过程和工具可用性
当前由OMG采用的QVT规范还没最终定案。这意味着，当前的规范通过发布报告对公众开放，允许OMG内部和外部的参与者支持潜在的问题和错误，或者对细小的改进提出建议。
工具开发者同时可以自由使用采用的规范，并且提供给MDA团队原型实现。遗憾的是，在编写本书时，几乎没有公众可用的QVT语言原型。
六、评估
当前的QVT标准是否可以在MDSD中新技术和方法学的动荡环境和快速发展中幸存下来，只有时间可以说明。标准指定3种语言的这种实际情况指示，模型间的转换仍然是难以理解的领域。也许多种非QVT的模型间转换语言和工具，一些是私有的，一些是开放源代码的，但所有这些都以它们自己的方式处理问题。
显而易见的是，QVT标准的目的是避免这种系统的无节制成长，但问题是当前没有人知道使M2M在时实践中起作用真正需要的是什么。这方面是因为很少有项目在工业项目设置中广泛地使用M2M，另一方面是因为模型驱动的开发是“早期的”市场。
根据语言的用法，QVT Relations和QVT Core都已经在支持双向映射的需要方面花费了大量成本，我们相信这种需要没有任何实际价值。
最后，我们应该提及的是，QVT规范是复杂的文档，进行了无数次的修订。即使可能，也很难证明语言标准是否是一致的和合理的。OMG在具有行为偏差的语言定义方面只有很少的经验。还有一种情况是，在很长的一段时间内太多的人研究了它的规范。然后，合理的语言标准必须是可被广泛接受的和易于实现的。我们预计QVT的修订和后续版本将在不久的将来出现，假设该标准没有被可能出现的实际模型转换标准绕过。