所在位置:UML新闻 - 内容 论坛精华    
模型驱动开发的今天

[2005/8/26]

模型驱动设计承诺带来开发时间的缩短、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只是将一个开发项目中涉及的各种人都团结在一起,允许大家在各自擅长的抽象层次上进行工作。

(自builderau,袁峰 摘译,不得转载用于商业用途)