模型驱动开发MDD

模型驱动设计承诺带来开发时间的缩短、bug的减少以及更好的可维护性。这是黄粱美梦吗？或许Matthew Overington会说不是。

软件开发行业花了数年功夫经历了大规模成本削减的历程，并开始新的进展。对软件开发过程而言，我们需要更好的预测性、透明性和可信性。

建模并不是一个新的名词。它是软件设计和开发中的重要一环，但企业目前正在进行更聪明和野心勃勃的计划，应用模型来解决很多多年的老问题。

其中一个问题就是当前的编码方法对建模的依赖－只有当模型经常更新维护时它才是有用的。过时的模型实质上是无用的，实际上有时候还是反生产力的，导致bug……。你觉得模型中应该有的功能在实际代码中没有。而现在的趋势是希望可以得到这么一个框架，允许模型通过各种方式进行转换和应用，允许开发者从这些资源（译注：指这些模型）中得到更多用途。

Borland APAC产品线的主管Malcolm Groves认为模型驱动开发（MDD, Model Driven Development）是继90年代的RAD和OO之后下一个革新。尽管RAD工具允许开发者快速地开发实际可用的代码，但其中很多生成的代码却很垃圾。也有人认为RAD的困扰在于效率的不够，因此开始使用UML模型，并手工编码来生成结构良好的代码。这样确实可以得到不错的结果，但却损失了速度。MDD承诺搭起这两者之间的桥梁，允许开发人员在快速同时便于维护的基础上开发高质量的代码。

在RAD中，通常是架构师驱动开发的进行，数据库的结构在很大程度上决定了应用的形式。而使用MDD，开发者可以方便地在数据库和代码之间来回转换。使用今年底将发布的ECO III, Borland将提供MDD for C#, 和MDD for Delphi .NET。

Borland正在努力用MDD来取代RAD，Grove认为对建模的更多依赖将是现实的途径。开发人员可以在更高抽象级别上工作而无需担心底层细节。模型驱动架构MDA提升了抽象层次，使开发人员可以关注于业务逻辑。

继在定义UML中扮演了非常重要的角色之后，Rational对MDD也持相同的观点。Rational在1990年左右开始提供Rational Rose和后来的Rational XDE。Eclipse项目目前已经开放源代码，这也再次证明了Rational在该领域的领先地位。

根据IBM公司Rational分部的售前架构师Davyd Norris的说法，代码生成方面更多图形化工具的开发是很自然的进化方向。“MDD是关于向抽象级别的转换，它允许一个项目中具有不同经验和想法的不同的人在一起工作，而不管他们更适应于哪个抽象层次的工作”。

Norris认为企业架构师需要使用UML的敏捷方法，“企业们正在变得更加敏捷。更多的应用正基于高级别的模型进行开发。”

对Norris而言，从底层的代码到高层的模型这些不同的抽象层次都是模型的一部分。他对代码就是模型的说法非常不屑，企业架构中有很多东西是无法简单用代码来表示的。通过转换工具可以实现不同抽象级别之间的切换，但它们都是对同一个问题价值相同的不同片断。

微软的姿态稍有不同。OMG官方定义MDA是使用UML开发应用的方式，而微软却不打算用UML来进行模型驱动开发，而取而代之的是DSL（领域特定语言，domain specific languages），它被设计来支持特定的任务。微软认为UML用来表达设计的大概意图是有效的，但用来作为源语言却不合适，因为UML在addressability、可扩展性和一致性上都存在不足。

Jack Greenfield是微软企业架构和工具部门的架构师，根据他的说法，Redmond方法将模型作为“软件开发的源工件，这些工具可以被自动地处理，比如进行验证、分析、跟踪和代码生成等”。这些模型的用途并不是作为文档。

动力（Momentum ）

尽管先锋部队是Rational和Borland，还有大量小一些的公司有着同样的热情，并给出了不少强大的工具。

以Embarcadero公司为例。他们提供了模型驱动的数据管理解决方案，其中可以创建模型并且该模型被整个开发链中的所有人所理解。该公司的arsenal中包含了为一个分析数据库应用所提供的模型驱动应用（ER/Studio），一个可视化建模和数据流设计工具（DT/Studio），以及一个模型驱动的分析、设计和开发环境（Describe）。这三个部分之间互相交互，可以将ER/Studio中得到的数据模型导入Describe，并构建完整的应用模型。也就是，可以从模型直接生成代码。

Embarcadero公司的APAC地区主管Philip Ball指出，当前的趋势是解决多年的开发老问题－“意大利面条问题－什么东西都纠缠在一起。你可以改动一处代码，但你不知道你影响了多少其它的地方。”

他认为模型的使用有助于提高开发过程的透明性，这将缩短开发时间，并降低bug带来的冲击。

Ball认为，MDD是将推动开发中对元数据的更多依赖。“存在存储元数据的需要，这样开发人员可以得到一个更全局的视图，看到自己负责的部分在整个软件生命周期中的位置。”

随着近年来数据的大量增长，Ball感觉这个问题越来越成为如何来控制的数据的问题；如何保持一个全局的视图同时可以有效地使用。根据Ball的估计，知识工人（knowledge workers）在开始工作之前需要花费50％的时间来理解他们面前的数据。“如果有模型和元数据，他们可以看到这些数据在更大视图中的位置，这样就可以削减这部分时间开支。”

Rational的Davyd Norris同样强调在一个软件生命周期中全局性的好处。软件开发并不终止于测试。部署、维护和文档化也是同样重要，并往往会导致项目的成本超支。Rational致力于在整个生命周期中使用模型。这是一个很有野心的项目，但Rational已经为此努力多年了。

MDD的流行甚至MDA为软件开发中各个环节上的人提供了好处，从DB设计者到架构师、底层开发人员。它允许项目主管可以更透明地监控开发；允许开发人员可以更快地回滚代码的变动；允许DB设计者在代码生成中担任更重要的角色；开发人员可以架起纯技术和业务层之间的桥梁。Philip Ball指出，“建模和开发之间的界限开始模糊。”

现实世界

底层开发人员也开始追随这个趋势了。Granite Solutions的头头Dick Walker是一位Delphi开发者，在过去15个月中他应用MDD加速了Ski Hire Shop的开发速度。3层WinForms业务应用处理预定、打包、付费等工作。他使用.NET remoting来支持客户端和服务端的通信，并基于Borland的ECO工具构建了应用。Walker看到了MDD在未来开发中将担当的重要角色。他认为构建应用的经验在于“识别系统中的对象和他们之间的关系”，根据Walker的理解，书写的定义和方法的过程中常常会为代码带来错误，因此这个过程的自动化将缩短开发的时间。

当然不光有鲜花，Walker在使用C#Builder 和ECO的初期也遇到了很多问题，ECO现在还有很多限制。他认为这是“从RAD和DB对象开发到MDD应用开发的范式转换”。现在他已经度过了这个学习阶段，而且将不再回到过去的开发方式上去了。“MDD不是玩具，你可以用它来开发真正的应用程序。”他认为随着工具开发商的努力，只有天空才是限制（译注：MDD的限制会越来越少）。

魔术棒？

上面的这些往往使人们不禁认为MDD就是今天各种编程问题的答案了。不幸的是，现在我们还远远没有到可以有一个一劳永逸的方案能够给牙齿增白、防止脱发的时候。我们也不会有什么可以替代有经验的开发人员来书写好的代码。这些建模工具的发展只是辅助好代码的书写，而不是替代。

MDD的扩展使用可以帮助开发人员报告需求、在合并和收购时集成各种应用，当项目结束的时候生成文档。MDD最本质的一点就是帮助您提升资产的重用。

期望用UML来定义一个应用，然后按下一个魔术按钮，得到最终的应用，这是不现实的。开发人员还是需要挽起袖子，老老实实地编代码，这样才能得到优美而高效的应用。Philip Ball的总结很棒，他认为MDD是“not automating good design methodology”。MDD只是将一个开发项目中涉及的各种人都团结在一起，允许大家在各自擅长的抽象层次上进行工作。