模型驱动开发的误解和挑战

2012-03-07 13:14:00 分类：it知识库 阅读()

　　英文原文：Model Driven Development Misperceptions and Challenges

　　多年以来，采用模型驱动开发（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计划，避免不必要的开销和成本。

　　3 - 误解：MDD==UML？

　　有一个误解是MDD意味着你必须使用统一建模语言（UML）——现状如此，完全是因为来自对象管理组织（OMG）的UML规范进行了这样的描述。消除这一误解的方法有很多。

　　打消这种念头的第一种方法是用MDD的方法工作，这只需要你在执行任务时把模型作为关键的工件使用，并使用利用这些模型的自动化机制。在这种情况下，模型是用语言简化了的现实，而这些语言具有定义良好的语法和语义。因此，可以在MDD中使用的语言有很多，而不仅仅是UML。 

　　在大多数情况下，我们确实要为手头上的任务选择合适的工具。如果我们的MDD需要标准化、为人熟知、被广泛支持的语言，那UML就是一个不错的选择。UML也是可扩展的。严格来说，它能通过配置（提供定制的元素、属性和约束）进行定制。这能让UML对所作的工作来说变得具体，也能让语言更加易学易用。增强建模语言可用性或针对性的另一种方式是创建你自己的领域特定语言（DSL）。

　　要记住的是，我们受益于使用的语言和创建的模型。为了指导投资，我们要权衡以下问题：

  • 是否能有效地设计和理解解空间？
  • 能否轻松地和其他人沟通？
  • 是否能基于已经创建好的模型生成方案的其他部分？
  • 能否有效利用开发生命期之外的结果？
  • 是否能从实现追溯到设计？甚至需求？

　　4 - 误解：MDD放之四海而皆准

　　根据前面的误解可以看出，MDD显然不是放之四海而皆准的解决方法，任何非预设的生产线工具集都可以用来构建产品。MDD就是用模型为特定情况增加价值，它适用于特定领域，跟你所开发的软件类型也是配套的。因此，我们能在自己的场景中看到很多使用MDD、有意义的方式。

　　其中一个例子是，我们可以和传统的面向对象分析和设计（OOAD）一起使用MDD。在审视OOAD和MDD的时候，往往会发现使用了很多模型，比如用例、分析、设计和实现。有很多现成的例子和文档演示了如何使用这些模型来完成方案。但这并不意味着你必须用上所有的模型。关键是我们要有效地利用抽象。抽象的层次取决于所处的场景、使用的语言、相关的约束、规则和假设，以及可能实施的自动化。

　　除了在模型数量（和相关的抽象层次）上务实之外，也要切合实际地选择模型中用于交流的图表。比如说，如果使用UML作为建模语言，就没必要使用所有可用的图表类型（类图、交互图……）。语言中有一系列图表可供选择，一般用途的建模语言能为各种需求提供服务就可以了。在特定情形下，对于你试图完成的工作来说，只选择那些能为其增加价值、有助于沟通的图表才是有意义的。至于完整性，我们可以进行进一步的讨论，要注意的是，即使在一个图表中，你也不必使用所有可用的模型元素。

　　5-误解：图表就是模型

　　MDD中关键的一点是要认识到我们在创建模型——正如前面所讨论的，模型是用语言简化现实，该语言要具有良好定义的语法和语义。我们在模型中可以发现大量模型元素和一组图表。每种图表都提供了模型元素之上的一个视图。每个模型元素属于零或多个图表。我们要关注模型元素——它们是什么？有哪些关系？有什么属性？我们通常使用图表来帮助我们理清这些问题。此外，我们还将图表作为和其他人沟通的方式。但模型的关键信息存在于模型元素中——因为这能让我们生成所需的视图、创建所需的图表，从模型生成其他元素。如果MDD只是图表，那工具能画出漂亮的图片就能满足我们的需求了。这并不是说图表（和支持图表的工具）不重要。创建模型和图表的工具需要进行调整，以适合目标受众。

　　结合有选择性地使用图表，我们还能利用视角让模型更加可用、更加利于沟通。视角是组织模型的一种方式，以便模型的某些方面可以提供额外的图表，使模型面向各种各样的受众。透视图通常只包含图表，而没有额外的语义元素。严格来说，在你更新语义元素时，透视图会自动保持同步。使用透视图可以让你与其他角色和小组有效沟通，从而为MDD增加价值。每个小组都想理解方案中的一部分内容，也就是与他们的需求相关的那部分。在不打乱模型、不构建独立模型、或是不在维护同一元素的多个版本上浪费时间的情况下，透视图可以支持这些需求。请记住，我的意思并不是让你支持所有不同的小组，并创建庞大的一组透视图。再次强调一下，关键是要务实，要创建有意义、能带来价值的图表与视角。

　　6 - 误解：代码就是模型，模型就是代码

　　以前对MDD的误解之一就是它只能应用于代码。MDD基本上被局限在一个较低的抽象层次，因此它的影响也很有限。很多人只用MDD工具“可视化”代码（也就是将代码图形化的逆向转换）。这样是有好处的，比如说，更好地理解大段代码，以及组件或类之间的关系。但撇开这些来说，代码可视化并不能获得先前讨论的那些MDD优势（比如业务编排、改善质量、提高生产率或影响分析），因为它所作的一切也就是让你以图形化的方式查看代码而已。这是基本、初级的图形使用方法，和预期的一样，它的投资低，收益也低。

　　再复杂一点儿，在代码可视化之后，让可视化结果和预期的设计保持一致。例如设计师或架构师想评审开发团队开发的代码，代码的可视化视图就能让他们对代码和设计进行比较，因为可视化结果和设计使用了相同的可视化技术（比如UML类）。不过，尽管可视化结果和设计用相同的语言表示，但两者之间仍然有很大差距，因为它们所处的抽象层次不同。MDD工具凭借可视化、可追踪性、分析和发现功能、重构支持能帮助设计师完成工作。一旦标注出设计和代码之间有分歧的地方，人工干预就必不可少了，设计师就要和开发团队进行沟通。这能提升价值，但仍然无法完全拥有MDD的优势。为了支持分析和沟通，需要增加时间和精力，而且每个项目都需要投入多次。

　　MDD应该适用于任何层次的抽象，并有助于不同层次之间的连通。你应该在较高层次的抽象上进行建模。以分析模型为例（像系统的用例模型），它是设计模型的输入。分析模型中的有些元素可以在设计中予以利用。比如说，功能域信息分类（包）和用例可以用来创建设计模型中交互图的基础模板，用例会在设计模型中实现。利用工具及其扩展性，你可以修改“分析到设计”的转换过程，接着让组织内的成员在质量和生产率上获益。

　　MDD适用于所有层次的抽象，而抽象的层次是无穷尽的。要为领域和组织选择有意义的抽象层次。例如，在SOA中，可以在开发方案时采用以下的抽象层次[2]：

  • 业务：该层次对业务策划师、业务分析师或产品所有者来说是有意义的。在这个层次上，模型元素是业务目标、关键性能指标、业务方针和功能域之类的内容。
  • 分析：分析和设计通常要一起看，分析模型的元素有时会演进为设计元素。在SOA里，考虑分析是很重要的，因为分析是支持业务元素的技术模型元素的起点。
  • 设计[3]：SOA方案中，大多数在架构上重要的元素都是在这个层次建模的。设计时要用文档记录架构的关键元素，以及它们的实现方法。
  • 实现：实现是“代码”层次的抽象。在该层中，你可以用MDD基于设计生成代码存根，并在需要的时候让代码和设计保持一致。

　　另一方面会出现这样的情况：人们热衷于模型和MDD，甚至仅仅为了建模而建模，却忘了把模型转换成可操作或可执行的内容。架构师可以和利益相关者、设计者和开发人员沟通，但你仍然不能完全受益于MDD。在你策划MDD的策略和方法时，要思考一下如何利用模型。譬如，部署方案最终用什么平台？如何提高代码质量和开发人员的生产率？是否能将模型转换成代码存根？

　　另外，模型所包含的有用设计信息要多于生成代码所需的信息，所以我们还要看看其它方式，来利用这些已捕获的重要而有价值的信息。这包括文档的生成、测试用例、部署脚本等，这样就能显著提高项目的整体生产率。众所周知，实际的代码编写只是整个项目的一部分工作而已。

　　没有什么银弹。所需的代码并非都能自动生成（除非你的领域非常小）。最后，你必须处理模型和代码，MDD则会指导你利用模型、保持代码与模型之间的同步。

　　不过双向工程怎么样呢？如何利用自动化保持不同抽象层次之间的模型同步呢？这也是一般方案中较为棘手的问题。例如，从较高层次的模型向较低层次的模型转换时，许多元素会展开——一个元素会在较低层次上演化出多个元素。一旦创建了较高层次的模型，用户就可以更新、移除、添加较低层次上的模型元素。那又该如何映射回较高层次的模型去呢？若干组详细的元素又怎样转换/映射到少量的高层次元素呢？面临这样的挑战，就很有必要想清楚，追求的这种方法到底是不是开发方法的一部分。

　　由于修改极可能在代码级别发生，所以若没有保持模型和代码一致的方法，模型很快就只剩文档了。最近，Rational Software Architect之类的工具在“保持一致”方面有了很大的改进，提供了可视化代码、比较和合并的功能。请注意，用于协调这些变化的方法比工具化的能力更为重要，这和治理也是相关的。举例来说，架构师看到了代码和模型之间的差异，怎么办呢？去和开发人员讨论？让开发人员修改代码？还是架构师修改模型？正如你所看到的，这些都不是完全自动化的方法。

　　已经取得巨大成功的另一个方式是预先在工具化上投资（要么购买要么定制），通过约束、规则和假设减小问题空间。对问题空间所能做的限制越多，生成高比例解决方案、减少抽象层次、消除双向工程需求的可能性就越大。在这种情况下，今后的关注点只需放在工程上。

　　7-挑战：平台无关性面临挑战

　　虽然不确定平台无关性发生的时间或原因，但是在高层次上进行建模、然后生成解决方案的想法已经引起了广泛关注。或许平台无关性来自于MDA的平台无关模型，也或许来自其它地方。不管来源如何，都要认识到很难从很高层次的内容进行延展，也很难将一种表示定位到许多不同类型的实现上去。已经有一些解决方案能让用户利用模型生成全部的结果代码了。但在那些情况下，也正如前面小节中所讨论的，工具化对领域来说很有针对性，而且利用了一组约束、规则和假设才使转变成为可能。解决方案空间比较狭小，这样才为生成高层次的内容提供了可能性。随着解决方案空间的扩展，生成会变得越来越困难。

　　就连迁移到DSL上也会提出这样的问题：使用相同的模型作为输入，生成不同的底层实现有多容易。在利用DSL的时候，关键应该是具体的领域和当前的项目。正如从许多敏捷过程中（以及自己的经验）学到的，过度工程化、计算每种可能性都要付出代价。这同样适用于建模和使用的语言。针对具体领域并不一定就是什么坏事，事实上它反而是最佳利益。不过，创建一个领域特定的解决方案，再大范围地加以应用是不切实际的。

　　8 - 挑战：保持编码人员的创造力

　　在我们转向MDD，期望简化设计表达、改善沟通、生成部分解决方案的时候，我们还需要认识到这会对团队产生影响。有些团队成员可能喜欢在较低的抽象层次工作；他们也许会在场景建模时觉得拘束，反而在努力实现解决方案的时候感到自如。这些担心并非都是合理的，但还是要听出“弦外之音”。我们需要保证每个团队成员都能发挥最大的作用。

　　即使在处理模型的时候，我们也需要底层实现的相关专业知识。应该使用什么框架？这些框架如何整合？下面以模式为例进行说明。构建模式实现的关键输入是参考解决方案，也就是样例，它用来决定模式实现应该做什么以及怎么做。如果我们要构建自己的模式实现，那谁来构建样例？谁来判定该样例是不是解决问题的最佳方式？既然期望能简化建模体验，那又由谁来给出规则、假设和约束呢？又该怎样把它们编辑到人人都要用的工具中呢？这些问题都强调，有很多地方都需要专业知识、创造性、以及解决问题的技巧。MDD策划、启动时有一点非常重要，那就是与团队成员沟通这些挑战，并确保每个成员都能以有建设性、有效率的方式为项目效力。反思一下过去的项目，真正创新的工作花费了多少时间？而机械、乏味、重复的任务又占用了多少时间？

　　9 - 挑战：没有可利用的内容

　　和其它相对比较新的方法一样，在最佳实践被充分理解和基础设施就位之前，产出的内容都很有限。现在MDD在软件行业越来越成熟，有了越来越多的推进力，可以看到，高质量的MDD内容和资产也越来越多。让这些内容从一开始就可用，对采用MDD来说是至关重要的。

　　面对有挑战性的业务问题，仅有工具和基础设施还不足以交付解决这些问题的软件。最终解决问题的往往都不是工具，而是使用工具的人[4]。如果希望大家使用工具，那么最初就有工具的话，情况就会有很大不同。你是否曾经面对过一块白板、一张纸或IDE工作空间？如果你一开始就有参考或模板，或者有内容指导、组织你的方法，岂不是更容易一些？

　　这里讨论的MDD内容不仅仅是设计模式或UML项目模板。我们所说的内容是指行业或方案的参考架构（比如呼叫中心参考架构或银行参考架构）、作为可执行模型的行业标准集（比如保险业的ACORD或电信行业的SID）或实现存根的模板大全。这类资产的一个成功案例就是WebSphere Business Services Fabric（WBSF）的行业内容包（ICPs）。WBSF框架由运行时和相关工具组成。ICPs为特定行业（领域）提供了可定制的内容，从而成为框架的有益补充。这些内容包括不同抽象层次（比如业务、设计和实现）上的模型和模板，它们遵循行业标准，由组织加以裁剪和采用。

　　这些资产的核心价值在于提供了更多的业务价值，而且更接近组织的战略。换句话说，业务能看到它们会影响损益底线。如果我们比较可复用设计模式的价值和行业框架的价值，毫无疑问，行业框架能创造更高的价值。但行业架构的适用性是很有限的。譬如说，如果是保险业的行业架构，那就无法在电信行业中使用。与此相反，设计模式的应用与行业无关，但设计模式提供的价值却有限，而且离损益底线更远。跟基于资产的开发（ABD）社区所认可的一样，让内容可定制（技术术语是“可变点”）有助于扩大其适用性。

　　要注意的是，此类内容并不局限在高层次的抽象上（比如业务模型）。由于运营资产都是可执行的，所以它们会影响损益底线。例如安全领域的资产，能复用、改变的细粒度访问控制策略。可以确定的是，这些会对损益底线有所影响，人们也能从这里建立到高层次业务安全策略的联系。

　　10 - 误解：MDD仅用于开发

　　构建软件解决方案的时候，使用模型来指定架构、关联的服务和组件具有很大的价值，从解决方案的其它方面来说也是如此。但这仅仅是MDD给组织带来的一部分价值。要想利用模型并从中获益，就没必要把使用范围限定得这么窄。

　　我们之前曾将业务驱动开发（BDD）作为MDD的特例进行了讨论。那种情况下的焦点是业务建模——业务里的过程是什么？它们如何工作？如何对它们进行优化？如果在这部分没有做好，那就会遭遇“无用的信息输入和输出（Garbage In，Garbage Out）”。

　　此外，我们还能利用模型来支持规范一致性。模型能提供易于理解的表示，详细说明结果方案如何支持规范要求。比如说，要表明组织是如何对细分客户群、业务范围（LOB）或渠道持续应用某规则的，就能用模型来实现这一规范需求。只提供代码到文档的一致性并不足以成为一个最佳的方案。

　　如果要增强已有解决方案的功能，又怎么样呢？如果需求‘A’变化了，这对系统又会有什么影响呢？你如何确定IT布局中的哪些部分应该进行验证和修改呢？如果不能跟踪从需求到实现的过程，这个问题就很难回答，回答的代价也很高。

　　在企业里利用MDD的例子还包括对企业架构和运作建模的支持，但也不局限于此。虽然目标千差万别，但我们仍期望能够沟通、利用抽象、保证治理、支持一致性、提高生产率。

　　总结

　　MDD带来了很多好处，它能促进沟通、改进业务编排、提升质量、提高生产率。如果你以前关注过MDD，那现在应该换个眼光来看待MDD。如果你从没关注过MDD，那现在可是关注的好时机，因为工具支持已经很成熟了。

　　MDD在工具集里有点儿与众不同——就像你不会只使用一种语言，或是某种语言的单个库，为了达到目的，你需要选择合适的MDD方法和角度。如果想在项目中利用MDD，为了找到适合你的方式，你需要认真考虑下面的问题：

  • 处于怎样的情境？
  • 对建模工具有什么需求？
  • 对建模语言有哪些需求？
  • 需要哪几个抽象的层次？
  • 如何简化并自动化构建好的方案？
  • 需要哪些类型的图？需要多少个图？
  • 和谁进行沟通？他们要了解些什么？
  • 如何确定MDD方法和工具能被整个团队采用？
  • 如何发挥整个团队的优势，并让每个人都参与进来？
  • 问题空间里是否有现成的可用内容？
  • 如何利用MDD来支持业务？如何利用MDD支持IT？如何利用MDD提供业务和IT编排？
  • 有哪些可用内容？这些内容如何针对你的情况进行定制？

　　致谢

　　感谢Brian Byrne、Greg Hodgkinson和Alessandro Di Bari分享他们的洞见，提出了提高本文质量的宝贵建议。

　　资源

　　英文原文：Model Driven Development Misperceptions and Challenges

　　[1] 我们并不关注资金模型或战略创新等组织方面的内容。相反，我们要解决的是在尝试采用MDD时可能面临的挑战，并提供能克服这些挑战的MDD最新进展。

　　[2] 在抽象的SOA层面上，这个列表绝不是官方的、全面的。它在这里只是说明抽象的例子，而非代码（实现）。

　　[3] 高级设计和详细设计这两个层次的抽象都很常见。这里只是一个例子，你的选择还是应该视约束和目标而定。

　　[4] Scott Schneider和Randy Lexvold在EclipseCon 2008大会上所作的演讲：模式领悟！基于模式的自动化技术实践。

　　译者简介： 张兵，有Web应用开发、XML技术、消息中间件和企业服务总线等方面的开发经验，对SOA领域比较熟悉，关注软件架构技术和有效的项目管理。

it知识库：模型驱动开发的误解和挑战，转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

标签：

相关文章阅读

构建高可伸缩性的WEB交互式系统（下）构建高可伸缩性的WEB交互式系统（下）
关于工作效率的心得分享关于工作效率的心得分享
DevOps——现代开发高手的终极秘诀DevOps——现代开发高手的终极秘诀
构建高可伸缩性的WEB交互式系统（上）构建高可伸缩性的WEB交互式系统（上）