多年以来，采用模型驱动开发（MDD）的水平似乎仍没预期的那么好。阻碍、限制MDD使用的因素有很多，例如对实际的MDD成功案例缺乏认知、不确定如何在平常使用MDD、缺少预先投资的拨款模式、或是没有战略举措的重点。

　　如果你过去尝试过MDD，那你很可能遇到了一些挫折，导致你现在不再用它。也或许你正在尝试采用MDD，而又面临着一些挑战和阻碍。无论你遇到上述哪种情况，本文都对你有所帮助。我们会在本文中看一看与采用MDD相关的挑战和误解[1]。

　　建模早已证明了它在改善沟通、促进业务编排、提升质量、提高生产率上的价值。它的使用范围很广，分析、设计和开发都会有所涉及。考虑到这一点，我们就来看看有关MDD的诸多误解和挑战，我们又该怎样利用现代方法和相关工具集解决这些问题。

　　1-挑战：方法不当且不可用

　　过去，MDD的一个关键抑制因素是人们实施活动的时候没有现成的MDD最佳实践。比如说，人们在阅读有关如何执行特定任务（诸如设计高可用的解决方案）的过程文档时，文档里并没有任何MDD的内容。为了得到MDD实践，人们不得不到论文或书本里去找，然后再应用到现有的非MDD文档上。

　　如今，MDD从业者在进行日常工作时，可用的MDD指南已经越来越多，而且那些信息嵌在他们每天使用的工具中。我们先看看开发过程，它包括利用MDD原则的“工具向导”最佳实践，这些“工具向导”隶属于整个方法和过程。

　　特定任务的指南（例如需求评审、设计用户接口或设计高可用的解决方案）现在都包含指向MDD内容的链接。比如推荐设计模式、提供设计中应用模式的指南、利用现成工具中的模式实现。

　　以前还有另一个阻碍因素，就是MDD与特定开发方法过度掺杂，人们无法提取MDD最佳实践，并将其应用到不同的场景中。一个典型的例子就是面向对象分析和设计（OOAD）中存在大量工具，你要么采用全部的OOAD内容，将其作为从MDD受益的一部分内容，要么就完全抛弃OOAD。MDD的最佳实践曾是OOAD框架的一部分，但人们并不知道如何在框架之外利用这些最佳实践。抽取出MDD的内容并将其应用到不同的场景中是不可能的。

　　这些因素再加上其他一些原因导致企业很难在它们的环境里采用最佳实践（包括MDD最佳实践）。公司已经有了合适的过程和方法，而给这些方法添加MDD方面的内容却很困难。

　　为了在组织和特定类型的项目中采用MDD，业界在裁剪特定开发过程方面已经做得越来越好。比如有的研讨会旨在指导团队完成定制的开发过程，这通常被称作“方法采用研讨会”。研讨会的目的是针对特定项目裁剪现有的方法内容，它通常会涉及以下人员：过程工程师（管理组织开发过程的人）、首席架构师、开发人员组长和项目经理。

　　支持定制后，方法工具浮出水面，比如Rational Method Composer和Eclipse Process Framework Composer，它们包含定制的最佳实践库。这些工具的思想是整理、打包最佳实践，用工具为组织裁剪并采用这些最佳实践。在工具中，你选择想要采用的某些方法元素，对它们进行修改、编辑，并将其组织成希望关注的过程。然后将该过程以可读格式（例如HTML）在组织内发布，供从业者在日常工作中遵循。

　　尽管使用上述工具和方法的可用指南有很多，但仍然要求用户找到、理解并遵照指南。跨越这一障碍的措施是，除了在工具里提供指南之外，还要将方案的全面自动化。举例来说，你能在使用基于Eclipse的产品时利用备忘单（Cheat Sheets）。备忘单提供完成任务的步骤指南，并能自动化工作流里的步骤。

　　下一节我们会讨论关于模式实现的机制。不管选用什么方法，要点都是获取越来越多的指南，并将其落实到工具中，从而更好地指导用户充分利用模型。

　　正如软件解决方案可能会过度工程化一样，创建指南也会发生同样的问题。克服这个挑战的最后一点是要务实、主动。计算出构建方案所需步骤的全部细节，无论从价值来说还是从时间来说都没有什么意义。那关键的步骤是什么呢？他们如何与团队的技术相结合？在文档化步骤上投入时间的意义何在？相对于自动化，在创建静态文档上又该投入多少呢？

　　过程，尤其是MDD，都不是放之四海而皆准的，这将在“4-误解”中讨论。

　　2-挑战：基础设施和工具不能从MDD获益

　　近几年，我们看到建模工具已不局限于对特定图形符号（比如UML）的支持了，经过发展，它已然能帮助从业者完成工作。这些工具不仅支持图形建模符号，也内置了MDD特性，这些特性有利于：

　　˙业务编排：业务编排是SOA等成功方法的关键方面。通过使用MDD模型、自动化、以及与之关联的“追踪”，你能记录决策的原因，跟踪满足业务需求的所有方式。另外，我们可以研究利用MDD的特定版本，比如业务驱动开发（BDD）。顾名思义，BDD关注的是业务建模。你可以在这种情况下进行建模，也可以在某些情况下模拟组成业务的流程。

　　˙高质量：由于实践内建在工具中，并进行了自动化处理，因此出错的几率非常小，甚至不会出错。

　　增强的一致性和治理：由于工具支持指南和最佳实践的自动化，所以提高了解决方案中元素的一致性。另外，工具也能确保构建的元素是固定的，并与需求和最佳实践保持一致。

　　˙提高的生产率：重复、耗时的工作现在都自动化了。从业者可以“复用”，把时间花在最紧要的事情上（比如业务逻辑）。依赖自动构建，用户群的复杂度和自动化要么可以在当前项目中实现，要么可以分散在多个项目中实现。
　　
　　˙改善的沟通：使用模型、工具和自动化，从业者（例如架构师）能针对不同的受众创建不同的视图。

　　˙影响分析：MDD的可追踪性能让你分析出需求变更对解决方案造成的影响，反之亦然。

　　让我们以设计模式为例，来说明工具如何给MDD带来了活力。假设某本书中描述了设计模式，我们将其称为模式规范。该规范非常有用。它描述了模式的使用时机、模式的特征，以及使用模式的好处和意义。模式规范能帮助人们理解模式并做出恰当的选择。但模式规范并不能确保设计的高质量和生产率的提高。为了从中受益，你必须将这些模式“自动化”。我们将其称为模式实现，也就是模式规范在工具中的可复用编辑。使用模式实现，设计者可以将模式快速应用到他们的设计中，也能确保这些应用准确无误。

　　领域独立的工具不太可能内置领域所需的所有MDD工件。工具除了提供开箱即用的MDD工件外（比如一组设计模式实现），也允许你扩展现有的工件、创建自己的工件。现在的工具包含“扩展框架”，以及最佳实践、模板和API。Rational Software Architect之类的工具还允许你构建适用于领域的MDD工件（例如模式实现、规则、约束等）。

　　既然你能构建这些MDD工件，那么基于资产的开发（ABD）就能让你与他人共享工件、提升复用的实践和基础设施。换句话说，ABD最佳实践和基础设施的改进支撑了MDD的采用进程。诸如Rational Asset Manager的可复用资产库能让你管理可复用的软件工件，让开发社区共享和复用工件。试想一个为领域创建的模式实现，你现在可以把它提交到资产库中，该模式经过评审和认可，社区中的其他从业者就可以复用它了。作为这个生态系统的一部分，你可以监控资产被复用的时机和方式，收集反馈信息并确保整个团队在使用合适资产的正确版本。

　　我们重新回到务实和实用上来。在对用户和用户所在组织有意义的情况下，ABD及复用倡议才需要被采用。你需要识别出你的成熟度级别，并采用支持该级别的工具和过程。通过事先思考和计划，你可以随需确定、推广ABD计划，避免不必要的开销和成本。