前言
“模型驱动开发”——体会一下这几个词。它们说出了这个不断变化的工业中一个新的改变。这里不是说一种革命，而是一种缓慢的变化，但是肯定会渗透到我们开发系统的方式中。这种推动将降低代码的重要性，并且专注于一些开发中的真正事情：最终的应用程序被期望怎样工作，并确保你能够根据客户的需求可靠地建立起它来。
模型驱动开发是更伟大视景MDA 中的一部分。MDA 是模型驱动体系架构（Model-Driven Architecture）的简称，由对象管理组织OMG（Object Management Group）所驱动。MDA 表示了一种模型驱动开发方法的概念框架。然而，尽管完整的MDA 还没有成为现实，模型驱动开发现在已成为可能。实际上，它已以较低级的形式存在了较长一段时间，所以我们并不是在做某种新的东西（当然，除非你在听某些市场人员的宣传）。
没有魔法
如果模型驱动开发这么好的话，为什么不是每个人立刻加入到这个潮流中来呢？
首先，模型驱动开发不是一个银子弹，能神奇地解决你所有的问题。总有某人需要去实现系统的功能，并且还找不到任何工具来完成这一点。所有你能发现的工具只是使这项工作更容易和直接一些。
第二，采用模型驱动开发，并不只是在开发项目的过程中更换一种工具。它还必须和已根深蒂固的开发过程结合起来（如果没有的话，你就可以开始使用模型驱动开发了；否则你就只能改善当前的情况），但实际上更重要的是，你还会担心它对现有应用程序的影响。决定改用基于模型的方法前确实需要有一些仔细的考虑，并且，一般说来，为了不影响当前的工作，你只会在新项目中改变开发方法。
第三，你还需要获得那些使用工具的人们的支持（你需要一些工具来应用模型驱动开发）。开发人员常会认为“模型驱动开发不是编程”而回避它，并且当心他们的工作难于被接受。他们还可能担心模型驱动开发将会使他们以前辛苦学来的一些技巧过时。他们的担心也不是完全没有理由。采用模型驱动开发后，市场确实很有可能会减少对那些精通好几种编程语言的开发人员的需求。但是另一方面，所有好的开发人员，首先和最主要的是，他们是问题的解决者。他们感兴趣的是尽可能地为手边的主要问题找到新的更好的解决方案。模型驱动开发激动人心的一点就是它允许开发人员集中精力于解决主要的设计问题，增加新的、酷的功能；而不是花费他们的主要时间于改正语法错误，防止内存泄露，或无休止的低级bug 上。
还有第四点，它也是第三点的一个结果，工具必须足够的好。不幸的是，有时用户对工具期待太多，或工具提供厂商承诺过多，实际上却不能交付。这两种情况都很容易使用户放弃模型驱动开发的想法。你确实需要保证工具能够满足你的需求。
可视化软件工程
模型驱动开发的基础是模型和表达模型的语言。模型提供了这样一种能力，能够一致性地显示这个系统的不同视图。一个常见的错误是认为模型驱动开发是模型和代码之间的一种关系，通过代码实现了模型。确实很多情况下，这二者是等同的，但它大大限制了我们的视野。
模型的一个主要用途消除开发过程中各参与方之间的隔阂，需求工程师，系统分析员，软件开发人员和测试者都可以使用同一种语言。你可以注意到，他们可能专注于语言的不同部分，以满足他们的需要，但他们都会共用一些基本的结构，并对他们正工作的系统有一个统一的认识。而且使用统一的语言有助于消除角色间的界限，使得在项目的不同阶段人员转换到被需要的角色更加容易。还有另外一些人需要知道项目的进展情况，包括项目领导、经理和评估委员会。更重要的是，用户也需要知道什么将会被交付，需要加入到整个开发过程中，与创建系统的不同人员进行交流。一种图形建模语言，比如UML，使得各参与方之间的交流成为可能，帮助架起参与方与某些系统复杂功能之间的桥梁。模型驱动开发正逐渐获得公司高级管理者注意，其中的一个主要原因就是这种能够逐渐增加用户、管理层和大的组织机构参与的能力。
那么编程将会怎样呢？它不再需要了吗？我们在这之前提及了一下，现在再详细讨论它。给模型提供足够的信息，工具就能生成大部分和全部系统所需要的代码。请注意，如果你用工具去生成全部的代码，这就相当于编译你的模型。在很多方面，这都类似于当从汇编编程转到C 编程时发生的模式转换，开始的时候，存在一定的怀疑，特别是那些汇编语言编程者。对于模型驱动开发，我们说的也是一种相似的模式转换，建模语言代替了编程语言，用建模语言来实现系统。这主要是因为建模语言正变得更有表现力，允许用户能够指定详细的系统行为。而且，主机上的确认和验证技术能用于检查系统的正确性。在模型中，一般说来你会忽略掉那些令人不快的细节，比如分布式，代理和内存管理，并且让工具去生成它们的代码。这些都表明你还需要对系统的行为进行建模（或者如果你愿意，也可以编程），但你可以在更抽象的层次上进行，关注于系统的重要功能。
你的明星程序员，你记不清他已多少次拯救你的公司了，可能会说，“如果我用编程的方式实现系统可能要快很多。”你知道他说的可能是对的。但是，这是个大系统，或者请慢，他打算对什么编程呢？是谁为他创建了系统规范？难道他不是团队的一部分吗？或者这个系统确实很小，一个人就能够确定规范，开发和测试？即使这样，你愿意所有的信息都只存在这一个人的头脑中？如果他不小心发生车祸，或者你的竞争对手为他提供了一份他无法抗拒的待遇，这时会怎样呢？系统交付以后又会怎样呢？最终用户能够修改实现吗？或即使是理解系统？将来升级，系统维护起来方便吗？
这将我们带入到模型驱动开发的另一个主要用途，把系统和软件开发更多地纳入到系统和软件工程规则中。模型驱动开发是关于开发和维护系统的，系统并不只是由应用程序组成，还包括其他的部分，使得人们可以理解这个应用程序。一个模型可以包含明显可执行的部分，但它几乎总是还有其他部分，并不能被运行，比如需求，系统的粗略框架，商业模型和分析模型。在项目开发时，所有这些都应该被创建出来并保持最新，它们对于将来的维护非常重要。
模型驱动开发的现代工具提供了运行一个（或部分）模型的能力，这使得可以更早得到确认，系统能按预定方式工作。换句话说，这意味着项目风险被极大地降低。在模型驱动开发中，测试也变得更加重要，因为能够被更早和更频繁地进行。这种方式，会使你对在项目后期，应用程序的各部分能够统一合作具有更多地信心。直观地，你可能以为所有这些额外的工作会延长开发周期，但是经验显示，产品上市时间实际上是缩短了。你花费更少的时间用于实现和测试阶段，更多的时间用于分析和设计阶段，当你迭代重复这些过程时，你会发现，这种方式的好处是实实在在的。
UML 2.0 的作用
无疑，统一建模语言（UML，Unifid Modeling Language）就是设计用来进行模型驱动开发的语言。它第一次标准化是在1997 年，作为当时各种面向对象分析方法之争的结果。然后它迅速成为最流行的建模语言，用于“可视化、构造和存档在基于软件的系统创建过程中的产品”。
我们沿着这条道路已经走了五年，用户和工具提供商对于UML 语言都有了更多的经验。我们知道什么很有用处，也知道什么需要被改进。而且，软件工业在这些年也发生了变化，需要去支持一些新的技术，比如基于构件的开发和可执行的模型。这些需求还不能用现在的UML 合适地处理。为了解决这些问题，对UML 大的修订工作两年前由OMG 开始启动，预计于2002 年底前完成。
在语言中新增加的性能，用于对系统架构建模，都是些很重要的部分，使得更容易创建任何复杂度的实际系统。对这种规模可伸缩性的关注也扩展到了其他领域，包括对行为进行建模的图形，比如顺序图和状态机。既然UML 试图适合很多参与方的需要，它需要变成一种相当大的语言，但是并不是每一个人都需要知道语言的所有部分。它被有意识地分割成几种视图或图形，允许你关注于只与你相关的专门领域。其他人可能希望工作在其他的视图上，模型将保持这些视图间的一致性。
工具的考虑
工具实现模型驱动开发的方式各不相同，给予用户或多或少的灵活性。双向工程是一个可怜人的选择，他不能在模型中捕获到系统行为，并且他还把自己与某种特定的编程语言绑定在一起，这还是一种以代码为中心的方法，所有这些都将使你感到难受。在一些紧急的场合，你甚至会忘记模型，比如一个项目就要到达最后期限（看起来在某处总有一个最后期限）了。在项目的最后，你得到了一个可工作的应用程序，还有一个没有实际用处的模型。这时，你甚至怀疑建模的重要性了。
对双向工程问题的一个让步就是在模型中直接插入编程代码，因此强迫你更新模型以确保最终得到一个可执行的应用程序。这同样使你感到难受，又被绑定到某种特定编程语言，你还不得不在模型的很多地方插入代码片断。这很像在C 程序中插入汇编代码，尽管有时这是必要的，但是将来维护会是问题并可能伤害你。
考虑直接在模型中提供指定系统行为的能力，上述两种方法都变得过时。在模型驱动开发中，你只需按一个键，在你选择的平台上，就能获得自动生成的任何语言的代码，这样在模型这一级上就能实现应用程序的可移植性。你不需要修改代码，改变你的系统就能直接反应到模型的实现上。当然，目前还有一些路需要走，大部分的工具厂商目前都有他们自己的语言映射，但要实现MDA 的目标，就需要有对不同语言和平台的标准映射和脚本。好消息就是这种前景正在展现。模型驱动开发确实正在起作用，并必将改变我们开发系统的方式。
什么是模型驱动开发(MDD)？为什么使用MDD？本文将回答这些问题，告诉您在软件项目中使用模型驱动开发的十五个理由。
1、MDD开发更快速
相比传统软件开发，模型驱动开发(MDD)的软件项目中，应用程序被指定为一个更高层次的抽象模型。通过对模型的解释/执行或产生的代码，抽象模型会自动转化为可工作的软件应用。
在代码方面，因为模型具有更高的抽象层次，所以比相同实现的其他方式具有更小的代码量。换句话说，模型中的每个元素(符号或其它伪编程语言)可以代表多行代码;这样，我们可以在相同的时间内实现更多的功能。比如，对比Mendix和Java开发， MetaEdit+或其他MDD开发工具比传统开发方式快五倍的速度。
2、MDD使开发成本更低
MDD能够以更低的成本高效的实现项目。正如上文所说，MDD的开发速度更高，可以缩短软件产品的交付日期，提早上市时间。其次，使用MDD本身就可以用较低的成本完成开发;比如，可以用更少的工程师和非专业人士并保证软件高质量的完成。当然，能节约多少成本还取决于学习MDD的成本和开发或购买MDD开发工具的成本。
另外，使用MDD来改变正在开发和维护的项目也能够节约成本。在维护方面，阅读高抽象模型的应用程序行为更加容易(详细参考第六点)，此外，我们还可以更快的使用高级语言添加或改进产品的功能。
3、MDD可以提高开发质量
在使用MDD的软件开发过程中，应用程序使用高级的抽象模型，而模型由一个引擎执行或被解释成代码;所以，该程序模块的质量将取决于执行引擎或解释器，而执行引擎或解释器一般是由一流软件公司和专家级程序员打造的。
此外，我们在项目中所使用的所有好的方法都可以包含在模型驱动开发(MDD)引擎中，并且在使用MDD工具开发软件时应用到你的项目中。如果你购买了一个MDD工具，你也同时购买了众多优秀的开发工具，因为MDD工具建立在过去所有软件项目的优秀技术总结。
4、MDD出错率更低
每个具有软件开发经验的人都知道，测试会花费开发人员大量的时间和精力。MDD可以确保我们专注于程序功能的测试，这意味这我们只需进行验收测试。技术细节的测试已经包含在MDD测试工具中。比如，对基础构造或安全问题的测试。
5、MDD的有效性验证
在使用MDD时，程序功能本身是低错误的，因为程序的有效性验证时在MDD的高层模型中完成的。我们知道，在使用传统的编程语言时，IDE会提供一些语法检查，甚至会进行静态代码的分析。但这并不能真正帮助我们避免程序的功能性错误。
当使用MDD方法时，对特定领域的有效性验证可以在系统设计时进行，由此产生的错误也可以控制在一定的范围内。比如对本文的一个静态文本验证。在使用Mendix模型环境中，我们可以使用实时的一致性检查以确保模型的一致性并保证其可以在运行时环境执行。
6、MDD使人在软件中的影响降低
在第二点中我们提到过使用MDD可以用更少的工程师和非专业人士并保证软件高质量的完成。当你不再需要技术专家来建立软件，你可以挑选更多人来为你工作。另外，与传统的开发方式相比，在使用MDD的项目中，如果有人中途加入，他可以更简单的理解软件应用的高级模型，因为他不必为搞懂程序的某些功能而阅读大量的源码。
7、MDD给行业专家更高多空间
MDD可以使行业专家专注于软件的行业特性，而技术专家将集中精力用于构建MDD的工具(详见第八点)。构建复杂的应用程序将不再是精英程序员的专利，在MDD项目中，将允许行业专家用他们自己的知识系统使用特定的符号构建一个模型，并使之融入高层的程序模型中。
8、MDD使高阶程序员只做他们该做的事
在使用MDD开发的项目中，开发人员很少进行重复性的工作。他们将有更多的机会在他们的工作中发挥创造性。比如，他们可以关注如何构建MDD工具;他们可以指导程序新手进行软件的初级开发或配合行业专家进行系统建模。高级程序将用更多的精力去解决应用程序中关键部分的技术攻关。比如，行业专家可以为图形用户接口、处理流程和商业规则创建模型。应用的集成部分(WebServices、API调用、数据库成等)对行业专家和开发新手存在困难，但这部分工作留给高级程序员去关注。高级程序员可以轻松而富有创造性的搞定这类项目中难度较大的部分。
9、MDD将消除业务和IT之间的隔阂
业务和IT的完美对接是在软件开发中经常被谈及的。MDD可以用以下方法使商业和IT之间走的更近：
◆行业专家或业务分析人员可以直接的参与开发过程(参考第七点)。软件的应用部分被定义为一个很高的抽象模型，这些模型将无限接近业务概念中的描述和定义。
◆因为MDD可以更快速的进行开发(参考第一点)，软件的构建过程将更少的迭代，这将使软件更符最初的需求(软件交付日期缩短，从市场策划到最终用户的周期变短)。
◆业务和模型以及模型和IT系统之间的定义更加明确。比如，使用模型驱动的面向业务需求(SOA)的一个框架。
10、MDD使软件开发不再惧怕商业需求变更
软件开发界当前存在的一个问题是商业需求的经常变化，而且这种变化的速度远远高于软件系统本身所容纳的限度。这主要是目前企业的长期战略无法保持足够的时间就产生变化并导致核心IT业务经常变化。当前动态的商业环境不得使企业有足够的反应时间。
但MDD可以提供有效的解决方案，因为MDD可以使软件开发更加快速(参考第一点)，它还可以是应用程序的改变更加容易(参考第二点和第六点)。如何商业需求和软件应用模型的关联足够明确，需求变化甚至可以自动传递到软件应用部分的变化(参考第九点)。
11、由技术产生的软件变化更少
技术的更新与变化越来越快。想想Java EE、 SOA/SOBA、WebServers、REST、OSGi和最近一年云计算带来的技术变革。MDD可以确保我们的应用程序模型在迁移到其他技术平台时不会发生变化;我们只需根据所变更的技术平台相应的改版代码编译器或解释器。更换解释器后，所有的程序模型将直接被编译成新平台的代码。
12、MDD使架构更加强壮
公司经常会定义架构标准，软件开发必须按照这些标准行事。但当所有代码都用手创建时如何检查或执行这些架构标准？当选择MDD进行项目开发时，应用程序会遵守既定的架构标准。你可以确保IT架构的标准化，因为这些架构标准在MDD工具中被定义。
一般，功能性的架构标准将指导功能设计。这些标准表现在你所采用的DSL(领域特定语言)。在MDD中，架构标准指导功能设计，并将在代码编译器和解释器中得到体现。
13、MDD使开发人员获得更多行业知识
MDD的另一个好处是你不只是建立一个软件，在高层的软件模型中，你将获得所建立软件的领域知识。在大多数软件项目中，领域需求的描述并不清晰，我们通常需要与行业专家或领域内不同的用户接触，用他们的专业知识来描述系统需求并建模。在MDD中，基于高度抽象的领域模型，我们可以通过行业专家对应用模型的描述获得深入了解具体应用领域的机会。
14、MDD可以提供最新的文档
当使用MDD进行项目开发时，我们无需再忍受不完整或不及时的文档，因为模型就是文档。当使用正确的抽象方法，模型的描述对行业专家和项目需求方具有很高的易读性(请参考第十三点)。
15、MDD使项目重心放在业务问题，而不是技术
就行前面提到的，MDD可以让我们更多的关注业务问题而不是如何将这些问题用技术实现。所以，不要再讨论我们该使用Java EE还是.NET，应该尽快开始MDD的学习和项目实践。