详细地说明一般的MDSD和MDA工具的重要属性。这种属性可用作工具的选择标准。然而，出于显而易见的原因，不会推荐任何商业上的工具。OMG提供了MDA工具列表，但不是列在其中的所有工具都符合本次讨论的内容。一些原因是，列表上的工具仅仅由制造商注册，没有被任何类型的权威机构证明。
一、工具在开发过程中的角色
如果没有工具的支持，模型驱动的软件开发将没有任何意义。这一节将提供典型工具类别的简要概述，这些工具类别应该用于MDSD项目或域体系结构的上下文中。
1.建模
首要的工具是建模工具。根据DSL，不同的具体工具可用于这种类型中。人们应该尝试提供特定DSL的适合编辑器--“了解”DSL并且在建模期间有效支持它的编辑器。
如果使用UML配置文件创建模型，则需要适合的UML工具。大体上，可以利用任何UML工具，但应该了解一些推荐的工具。
- XML导出。首要的，该工具必须能够以XML格式导出模型。
- 类别模版和标记值。
- 元建模/配置文件。工具应该理想地支持真正的元建模和UML配置文件的创建。
- OCL。如果工具不仅支持M1级别作为注释的OCL表达式，还支持作为配置文件定义一部分的OCL，则会非常有用。
2.模型验证和代码生成
当前可用的大量UML工具不能检查模型对于域特有的元模型的正确性。而代码生成只可以在模型关于元模型是正确的情况下起作用。同样，在不使用UML对模型进行建模的情况下，模型的检查必须发生在代码生成之前。
在大多数情况下，使用单独的工具指导这种模型检查。重点是，该工具中的验证阶段与代码生成阶段分离。转换不需要验证模型，但是假设模型正确性与元模型相关，否则会给这种转换带来不必要的麻烦。
3.构建工具
在许多情况下，生成器将创建大量不同的工件。在下一步中，必须适当地对这些工件进行编译、打包和处理。针对这一点需要合适的构建工具。原则上，任何脚本语言都可以服务于这个目标：在Java世界中，Ant已经被广泛接受。
在许多情况下，人们将生成构建脚本，作为生成器运行的一部分，然后直接执行它。
4.处方框架
如果需要开发者手工编写系统的特定方面，并且如果在这样做时必须遵循特定的规则，则指导开发者会很有用。生成器不会真正起到帮助作用，因为它将只是生成基类，然后终止，并且希望开发者“做正确的事”和编写子类。
处方框架在运行代码生成器后管理开发者的实现任务。在一般情况下，生成器除了生成代码外，还实例化随后由IDE根据生成的代码检查的大量检查，从而证明手工编写的代码是完整的和正确的。这种工具可以有效地简化使用生成器的开发。
5.IDE工具箱
“IDE工具箱”不是必须使用的，但如果可用，那么将是非常有用的，应用程序开发者可以在一个自定义的IDE中操作和管理模型、不同的处理步骤、生成的人工制品。针对配置文件、模型访问以及对生成工件的访问采用的编辑器应该都是可用的。特别的，域特有的IDE应该只显示这些与开发者相关的工件或者方面。无关的中间结果应该只在需要时才显示。
Eclipse平台是这种IDE工具箱的示例。它允许通过可接受的工作创建项目或特有的IDE。
二、工具体系结构和选择标准
1.实现元模型
针对域正式定义的元模型是良好的起点，但为了真正有用，必须在应用程序开发期间实际地使用它。只要元模型只是在纸上或建模工具中归档，而没有更多的工具使用它，它就没有任何生产性的价值。
手工检查模型与底层元模型的一致性是非常耗费时间，并且容易出错。标准的建模工具，例如当前的UML工具，在这儿通常没有任何作用，因为它们不理解域特有的元模型的规则，并且因此不能使用它们检查模型。典型UML工具应用的唯一规则是通常检查UML模型的良好够长的规则，也就是说，根据UML元模型的检查。在这一点上，只能希望UML工具在不久的将来提供对配置文件的改进支持。
2.忽略具体语法
每种模型不可避免地都必须以具体语法重现，例如基于MOF的模型的UML XMI，以及文本模型的XML.无论如何，基于具体语法定义的转换都相当复杂，因为它们必须考虑具体语法，而元模型元素实例的转换应该是它们关注的焦点。这就是使转换变得复杂。此外，如果改变模型的具体语法，则可能不再使用转换--这种情况在项目的过程中确实会经常发生。
以具体语法为基础的转换定义一般容易产生错误，并且效率较低。例如，XMI非常复杂的语法。只有在很少的情况中可以在XMI的基础上通过XSLT定义转换。在许多情况下，同一个元模型有多个具体语法也很有帮助，例如，在使用不同的DSL描述各种技术子域或者在项目的过程中改变具体语法时。基于具体语法的转换定义和模型确认不一定会转换绑定到特定的具体语法。
转换定义由此应该基于源元模型。出于这个目的，在转换工具中实现一个三步骤的过程：
1.在生成器中解析源模型并创建模型的抽象表示，一般采用对象结构的形式，例如，通过元模型类的实例化。
2.将该模型转换为目标模型，并且只使用抽象对象--图形表示。
3.将目标模型译成目标DSL的具体语法。
通过这种途径可以产生在指定转换方面更为有效的和富有建设性的方法，并且使转换程序变得更为灵活，因为现在可以使用任何的具体语法。这一点对于基于XMI的具体语法特别重要，因为不同的UML工具会导出不同的XMI个性化语法。应该避免将转换绑定到特定的工具，更不要将转换绑定到特定的工具版本。
典型的、基于AST的生成器的操作模式
MDSD代码生成器通常不使用完整的三步骤途径，而是直接基于最初的模型实例生成文本输出。这种文本输出过于复杂，因此无法创建目标模型的抽象语法树，在当前情况下就是目标语言的抽象语法。相反，使用模版语言在源模型上定位。然后，源模型应该表示为对象图，即实例化的元模型。
该途径非常适合于实现元模型。在理想情况下，可将同一个实现用于两个目标。
3.模块化的转换
从MDSD工具方面来看，对这种概念的支持构成了一种结构特点或一个选择标准。
4.模型转换的重要性
模型转换在域体系结构中占有重要地位，它是成熟的、基本的工件，非常类似于模型和手工创建的源代码。模型转换影响到开发人员处理转换的方式以及工具的操作方式。
当前的一些工具仍然认为转换没有模型和传统的源代码重要。幸运的是，基于模型的生成器通常将代码生成模版存储为单独的文件，可以很容易地使用工具版本化这种文化，并且在必要的情况下进行合并。然后，有必要提及的是，对于转换的表示和处理，现在仍然没有经过证明的被广泛接受的范例或者语法。
三、指针
本节介绍大量有趣的工具和架构，其中大多数是开放源代码的。一些工具现在已经获得，其他的工具将在不久后发布。
1.Eclipse的世界
许多有趣的MDSD相关技术都出现在Eclipse平台环境中。
1）Eclipse建模架构
Eclipse建模架构是基于Eclipse的MDSD架构，并且是大量有趣的工具的基础。它的主要构件是ECore，这是与E MOF密切联系的元元模型实现。EMOF允许使用各种技术定义元模型，例如基于树的编辑器、编程等。然后可以通过这些元模型生成实现类，这些实现类提供了构建元模型实例的具体API，这些生成的类也提供了对不可以直接使用Java类表示的元数据的运行时访问。
EMOF的重要性在于它很快发展成为构建MDSD工具的事实上的行业标准。大量不同的实验工具已经根据EMOF开发出来的。
2）图形建模架构
图形建模架构GMF是一种基于EMF的架构，它支持自动生成用于EMF元模型的图形编辑器。
这种生成编辑器的途径并不是最新的--以前已经使用过该途径，但是使用了其他的特定的技术。
3）生成式模型转换程序
生成式模型转换程序GMT子项目作为分别研究MDSD不同方面的大量子项目的容器。这些项目有不同的成熟度。
- ATL是模型间转换引擎，它在过去几年中已发展成书，并且已经被广泛使用。
- AMW是表示大量模型之间对应关系的工具。这些对应关系存储在称为编制模型的单独模型中。
- AM3的目标是支持大型建模，这涉及元模型和元元模型独立跨模型引用。
4）模型驱动开发集成
模型驱动开发集成项目的目标是提供所谓的“模型总线”，这是用于工具间模型交换的程序。和基于文件的交换相比，MDDI的主要目标是提供实时的模型同步。
2.UML工具的发展趋势
UML工具过去主要用作许多MDSD项目的入门级绘图工具。使用类图作为基本上所有内容的基础，使用类别模版和标记值添加语义。基本符合标准的XMI导出作为生成器的导入格式。然后，在这个领域中发生了一些有趣的改进。
另一个有趣的发展方向是越来越多的UML工具带有开放的API，这些API的功能在变得越来越强大，从而可以自动化和定制域特有的工作流。
3.UML2复合结构图
有必要指出的是，在大多数UML工具中都采用了UML2的特殊新特性：复合结构图。
4.其他类型的编辑器
一些工具可用作建模前台，人们一般不会立刻想到使用这些工具。其中一个优秀的示例是微软的VIsio，可以将visio认为是一种面向对象的绘图工具。
特征建模工具是另一种有趣的建模系统被选方法，特别是在建模的系统是软件系统家族环境中的产品时。
5.集合的元建模IDE
集成的元建模IDE是支持两种不同任务的工具：
- 它们支持为用户定义的DSL定义元模型、约束、具体语法以及编辑器。
- 在第二个阶段，它们使用新定义的DSL在工具中可用，从而允许应用程序开发人员使用用户定义的DSL。