心曲沉烟，悄望雪云平

Rational Rose是一个可视化建模工具，同时也可以生成Java代码，但很少有人将之归类为MDA工具。有人认为Rose只能将Class Diagram转换为代码，而对于其他模型(例如Use Case Diagram、Activity diagram)无能为力，而且即便有了这些代码，还是要经历一系列的调试、测试、配置管理、部署过程，而且前期的设计抽象工作亦必不可少，因此Rose对于提高开发效率的帮助是有限的。

与之形成对比的是OptimalJ、AndroMDA、OpenMDX等被称为MDA开发工具的软件，它们为基于Java EE的开发提供了更高层次的模型抽象。其中OptimalJ拥有一个相当易用且与Eclipse相结合IDE，而且其对业务建模-->应用建模-->代码生成三个阶段的连贯支持，使之成为一款广受好评的工具。但这些工具能否真正成为将MDA推向更深更广应用的助推器呢？

在以模型为中心的方法中，系统模型具有足够的细节能够从这些模型中生成整个系统的实现。为了实现这一点，模型也许应该包括，比如持久数据和非持久数据、业务逻辑和表示层元素的表示法。若存在任何与遗留数据和服务的集成，对那些元素的接口也需要被建模。然后代码生成过程应用一系列的模式将模型转换成代码，通常允许开发人员对被应用的模式进行选择。这种方法常常使用标准的或者私有的应用框架和run-time服务，这些应用框架和run-time服务能够通过限制被生成应用的类型使代码生成任务更加容易。在这个意义上，MDA似乎应具备两个特征：第一，必须使用标准的形式化语言对模型进行描述；第二，这个模型的抽象层次不能太高。这也是我们在OptimalJ中看到的：在OptimalJ中，虽然开发人员可以在此定义Domain model，但向Application model的细化工作依然必须由设计人员完成，OptimalJ提供的可视化建模工具更多地起到类似Visio的作用（当然，还可以自动维护模型的一致性），还难以真正实现从PIM到PSM的自动映射。

当我们把回顾OMG定义MDA的一些原则：
1.定义一个恰当的语言，使之成为理解企业级方案系统的基础。
2.系统的构建能够围绕着一系列模型进行，模型之间可以实现由抽象到具体的转换，并且这些模型能被组织到一个分层的和转换的体系架构框架中。
3.可以通过一系列元模型来描述模型。
4.标准化，且平台无关。
为了使开发人员能够在更高的抽象层次工作，MDA努力降低模型的复杂性，并以此提高软件的一致性、可追溯性，并以refactoring的方式提高代码质量。于是OMG寄希望于UML 2.0，力图使之成为黏合不同模型的强力胶，并为之增加了大量meta级的语言要素。但是，在我们早已经习惯的庞杂的UML之中，存在着巨大的语义断层，这使得基于UML的MDA工具不可避免地受到限制。为减少这些限制的影响，我们往往只能在较低的抽象级别定义PIM，直接定义PSM。这无疑又违背了MDD的初衷。

前两天把Eastwood主演的西部片《The good,the bad,and the ugly》温习了一遍，这部40多年拍的电影当年风靡一时，在IMDB上虽然可以获得8.9分这样超高的评价，但无疑如今看起来有些缓慢、松散、并且漫不经心。

于是也设想了一下，几年后，MDA是否也变成一部老电影？