高级软件工程论文.docx

模型驱动的开发（MDD）摘要“十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高”，Frederick Brooks在1986年做出的这一论断被广泛称为“银弹定律”。Brooks给了这一定律一个10年的期限。然而事实证明他过于谨慎了，在他做出这个论断之后接近20年，银弹定律仍然像魔咒一样紧紧束缚住软件工业。尽管专业人士尝试了大量的新技术和新方法，但是效果令人失望。面向对象被证明有负众望，软件工程更是陷入泥潭，魔咒丝毫没有松绑的意思。我们应当像敬畏“没有永动机”的理论那样敬畏“银弹定律”呢，还是应当去挑战它、突破它？ 事实上，软件理论家和实践者一刻都没有停止过突破“银弹定律”的尝试。“模型驱动开发”可能是最新的一次尝试。本文通过从软件工程的未来发展趋势对MDD进行了一系列的分析。KEY：银弹定律，模型驱动开发，软件工业，永动机Abstractten years, there is no single software engineering progress can make the software of magnitude increase productivity, Frederick Brooks made in 1986, this argument is widely known as the silver bullet Law. Brooks gave the law of a 10-year period. But the fact that he was too cautious, he made this assertion in nearly 20 years later, the same silver bullet Law is still tightly bound to live as the curse of the software industry. Although a large number of professionals who try new technologies and new methods, but the effect is disappointing. Object-Oriented been shown to have fallen short of expectations, software engineering is stalled, the spell did not mean relaxation. We should like the fear of no perpetual motion machinetheory that fear of the silver bullet Law, or should be to challenge it, break it? In fact, theorists and practitioners of the software have not stopped a breakthrough moment, silver bullet Law attempt. Model-driven developmentmay be the latest attempt. This article from the future trends of software engineering, a series of analysis of MDD. KEY: silver bullet law, model-driven development, software industry, perpetual motion machine目录摘要2引言4探索模型驱动开发 (MDD) 和相关方法1: 实现模型驱动开发，增加您的 IT 系统的业务价值5探索模型驱动开发 (MDD) 和相关方法2: 结合模式与建模以实现架构驱动开发-明确地捕获您的架构决策8探索模型驱动开发 (MDD) 和相关方法3 : 进一步研究模型驱动开发和其他行业方法1115种使用模型驱动开发MDD的理由12模型驱动开发的误解和挑战15总结19参考文献：20引言关于软件工程的未来发展趋势，我们曾经讨论了很多次。但是软件工程的发展不可能是孤立的，依据计算模型和软件开发本身的变化和趋势，我们由此可以推测软件工程的发展趋势。 需求工程，渐成热点：专业化的角色，日益复杂的业务创新，全球分布的团队以及互联网级的交付速度，这些都对需求获取的正确性和有效性提出了更高的要求。 DSSA和MDD，老树新花（基于领域的构架（DSSA）与模型驱动的开发（MDD）：随着软件应用的日益普及，软件已经超出了将手动流程自动化的范畴，而开始成为业务创新的主要推动力。因此，引入捕获特定领域内最先进需求及其实现架构的DSSA成为行业客户的热点之一。而且，DSSA的引入将MDD门槛大大降低了，也使基于DSSA的MDD支撑工具成为可能，从而可以极大地提高开发效率并保证软件质量。 迭代/敏捷，渐成标准：随着软件交付周期的日益加快，迭代化开发已经成为大多数软件开发团队的必选项。但是迭代对整个团队的需求、架构、协同及测试能力都提出了更高的要求，现在许多开发团队都在试图导入迭代化开发的过程中，敏捷可是被看成迭代化开发的一种导入方式，这不过敏捷的范围其实比迭代化开发更大一些。 持续集成，蓄势待发：持续集成是保证迭代化开发质量的主要方式，通过持续集成可以利用自动化的方式来尽量自动地、尽早保证代码质量。随着迭代和敏捷的流行，持续集成相关的工具成为现在市场上的新热点。 基于实践的过程框架，方兴未艾：开发角色的专业化的和分布的全球化都要求软件开发过程更加规范，而敏捷又要求过程必须紧密贴合项目的实际需要，因此传统的大一统的过程无法符合这一需求。新一代的过程将是以实践为核心的，项目可以通过组装所需的不同实践来获得贴近项目要求的过程。 配置管理，昨日黄花：随着开发团队规模的日益减小，配置管理的复杂性大大降低了，我们注意到越来越多的用户转向使用开源的配置管理工具；未来的配置管理工具更多的以一种全生命周期管理平台（Application Lifecycle Management）的方式出现，弱化了单项的配置管理能力而强调了全流程的整合。探索模型驱动开发 (MDD) 和相关方法1: 实现模型驱动开发，增加您的 IT 系统的业务价值Tracy Gardner 博士是英国 IBM Software Group Services 的解决方案架构师。她在模型驱动开发方面有着五年以上的行业经验。她在模型驱动开发方面撰写大量文章并做了大量演讲。她拥有 Bath 大学的软件工程博士学位。您可以通过 联系 Tracy。了解您目前的业务环境IT 开发不会孤立出现。IT 的目的是简化业务运作，这意味着业务环境的需求推动着我们开发 IT 的方法。表 1展示了一些当前的业务推动力。推动力描述随需应变的业务由于商家应该更具适应性和灵活性，所以 IT 系统要做得太多了。业务关联大家强烈关注 IT 部门交付业务价值。软件必须是与业务相关的。业务及 IT 人员之间的错误传达会导致从 IT 交付观点看成功的项目，被视为业务上的失败。成本控制根据承诺的力度对 IT 投资的时代早已过去。现在，IT 部门在强大的预算约束下运作，并且应该证明其金钱方面的价值。不断增加的复杂性软件系统在规模和复杂度上不断的增加，从而满足业务需要。对小规模开发有效的技术，不一定适用于按企业级的计划。技能可用性当今 IT 平台的成熟意味着交付软件需要专家的经验。许多组织努力寻找着有充足技能的专业人员支持它们的开发。项目常常依赖于一些关键的人物，如果这些人离开了，损失会很严重。变化的中间件环境现今的应用程序都部署到极为多样的中间件平台上，平台技术的变更率没有表现出减慢的迹象。商家希望利用中间件中的先进技术，但不愿意重复地编写它们的应用程序。表 1. 当前的业务推动力了解软件开发的模型驱动方法模型驱动开发（Model-driven development，MDD）是软件开发的一种样式，其中主要的软件工件是模型，根据最佳实践，可以从这些模型生成代码和其他工件。模型是从特定角度对系统进行的描述，它省略了相关的细节，因此可以更清楚地看到感兴趣的特性。例如，结构工程师会创建适合于确定建筑物承载特性的模型。在 MDD 中，我们引入了附加的标准，即模型必须是计算机可读的。例如，我们必须能够以自动化的方式估计模型的内容。模型的计算机可读性是它能够生成工件的必要条件。白板上的图也许满足作为模型的其他标准。然而，直到我们以计算机可读的方式获取它时，才能够在 MDD 工具系列中使用它。软件模型一般用统一建模语言（Unified Modeling Language，UML）表示。UML 是用于说明、可视化，并文档化软件系统的语言。它为软件模型提供了可视化的表示和基础的语义。UML 还拥有用来确保自动化的标准化的计算机可读的序列化格式。软件模型隐藏了技术实现的细节，因此，我们可以利用来自应用领域中的概念来设计系统。为 MDD 项目估计任务MDD 对我们构建业务应用软件的方式有着深远的影响。它获得了顶级技术人员的经验及决策，通过为项目的需求所定制的工具使余下的团队可以获得这些经验和决策。由于大量的低层次编码工作已经自动化了，所以开发的成本，以及测试业务软件的成本极大地减少了。错误的数量减少了，并且在工作完成的方式上增加了一致性。然而，MDD 确实创建了项目的不同一面，需要管理一个项目中的另一个项目。内部工程包含了 MDD 工具的开发，这些工具可以供开发团队在外部项目中构建业务应用程序时使用。一般来说，开始要将一个业务应用程序确定为利用 MDD 工具构建的，着重于需求，并且可以对该方法进行一些调整的第一个项目。一旦开始开发了，就可以将 MDD 工具用于构建许多业务应用程序了。对于两个项目，谨慎地组织和计划是非常重要的，特别是在一开始的时候。在与开发项目相关的平常问题之上，存在着管理额外的内部依赖集的需求。MDD 工具需求必须在应用程序开发人员需要它们之前进行确认和开发。两个项目的任务流要互相联结的，这样可以确保由 MDD 工具项目而来的交付产品是及时的。图 1 展示了 MDD 项目中的任务流。阴影的任务可能在传统项目中执行。白色的任务是为具体项目构建 MDD 工件的附加任务。图 1. 开发 MDD 工件的步骤MDD 拥有极大地提高当前主流软件开发实践的潜能。表 2 展示了 MDD 方法的优点。好处说明增加了生产力通过由模型生成代码和工件的方式，减少了软件开发的成本，同时增加了开发人员的生产力。您必须考虑转换开发（或购买）的成本，但谨慎的计划可以帮助确保成本的整体减少。可维护性许多解决方案组件是使用遗留平台技术实现的，但组织不再掌握这方面的技术了。MDD 形成了可维护的架构，在其中可以快速一致地做出变更，可以将组件更有效地移植到新技术上。 高层次的模型与不相关的实现细节无关，这使得处理底层平台技术及其技术架构中的变更更加容易。您可以通过更新转换来变更实现的技术架构。转换被重复地应用于原有的模型，用于生成依据新方法的实现工件。您可以在做出最终决策之前尝试不同的想法。不好的决策很容易变更。人们经常按照错误的决策继续进行软件项目，而成本过高难于修复。遗留系统的复用一贯地在 UML 中为现有的遗留平台建模。如果有许多组件是在同一个遗留平台上实现的，那么您可以开发从组件到 UML 的逆向转换。您可以将组件移植到新的平台上，或者生成包装器（wrapper），通过集成技术，例如 Web 服务，来访问遗留组件。适应性由于已经在自动化方面进行了投资，因此添加或修改业务功能就是很简单的了。当添加新的业务功能时，您只需要开发针对该功能的行为。生成实现工件所需的剩余信息可以在转换中获取。一致性手动地应用编码实践以及架构决策是容易出错的。MDD 确保一致地生成工件。可重复性当在程序或组织层应用时，MDD 尤其强大，来自开发转换的投资回报在每次复用时都有所增加。使用经过试验和测试的转换还增加了开发新功能的可预测性，并且减少了风险，因为架构和技术问题已经解决了。改进了涉众的交流模型省略了与了解系统逻辑行为无关的实现细节。它们更接近于问题领域，减少了涉众所了解的概念，与表示解决方案所用语言之间的语义差异。简化了与业务目标更好地结合的解决方案的交付。改进了设计的交流模型帮助您在设计层上了解系统，引出了对系统的改进的讨论和交流。因为模型是系统定义的一部分，比起文档，它们从不会过时，而且是可靠的。经验获取项目或组织经常依靠重复地做出最佳实践决策的重要专家。他们的经验可以在模式和转换中获得，因此，他们不需要直接面对项目的其他成员。而且，有了伴随转换的充足文档，即使当专家离开时，组织的经验仍旧保留在模式和转换中。模型可以作为长期的资产模型是获取组织的 IT 系统的功能的重要资产。高层的模型对最新平台级上的变更具有弹性。它们只在业务需求变更时才发生变更。推迟技术决策的能力早期的应用程序开发针对建模活动。您可以推迟具体技术平台或产品版本的选择，直到有更多的信息可用时再选择。在出现极其长的开发循环（例如，航空交通管制系统）的领域中，这是至关重要的。在开发开始时，目标平台可能还不存在。表 2. MDD 好处探索模型驱动开发 (MDD) 和相关方法2: 结合模式与建模以实现架构驱动开发-明确地捕获您的架构决策Larry Yusuf 是在英国 Hursley Labs 设计软件团队策略和技术的解决方案设计师。他在业务集成和建模方面有四年的经验，着重于业务过程管理、事件及解决方案管理，以及集成模式。他在这些方面写了大量文章并进行大量演讲。您可以通过 联系 Larry。利用模式和模型驱动开发（model-driven development，MDD）可以进行架构驱动开发。这种开发类型可以使我们明确地获得架构决策，并且在系统中对架构决策自动化编码。通过使用模式及 MDD，您可以减少工作中的复杂性，并且进行按需设计及开发。MDD 概述在 MDD 中，模型不仅用作框架或蓝图，而且作为通过变换的应用来生成的有效实现所依据的主要工件。在 MDD 中，当开发新的软件组件时，面向应用领域的模型是主要焦点。代码和其他领域工件是利用将来自建模专家和目标领域专家的意见作为输入的转换来生成的。定义架构和架构风格IEEE 将架构定义为：软件系统的架构（在一个特定的时间点）是通过接口，那些由连续的较小组件和接口组成的组件，交互的重要组件进行组织或结构化的。架构反映了有关功能在系统中如何分布，要使用哪些技术，及要采用哪些设计模式的决定。架构包含了一组架构原则和决定。有时候这些架构原则被记录下来，但常常推论的原因却无从得知。在一些情况下，甚至没有对架构原则进行过充分的考虑，这导致了糟糕或不一致的架构。当然，编写架构原则是一个好的主意，但是如果可以更进一步，并以变更或引入架构原则会实际地改变系统架构的方式获取它们会怎样呢？而且，如果能将那些同样的原则应用于多个组件、服务和解决方案会怎样呢？这些优势是 MDD 所涉及的。MDD 还将架构风格自动化。在 MDD 中，不仅仅简单地将所实现的解决方案的架构原则、模式，和转换编写为文档。MDD 方法还要求明确地做出架构决策。当获得了新的理解时，MDD 能够更容易地矫正不好的决策。当原则手工地应用于整个系统中时，修改是很困难的。但如果在转换中获取，并被自动地应用，修改转换和再生成是较容易的。在做出最终决策之前，尝试许多其他选择也是花费较少成本的。当通过重复地应用模式和转换以确定最佳匹配来验证解决方案满足非功能需求时，该方法是有价值的。 了解模式在 MDD 中，利用具体领域的概念来建模。例如，在企业整合领域中，可能会用到消息、代理和适配器。应用领域的词汇中还常常包含模式。在企业整合领域中，可以保证交付和发布订阅模式。这些模式不是单个的元素，而是引入元素和对其行为的约束之间的关系。每个模式都包含它所适用的环境的信息，以及它与其他模式的关系。软件开发的特点意味着，额外地将用模式语言进行设计的过程自动化是可行的。我们可以通过从较大的模式转移到较小的模式来设计软件系统，如图 1 所示。通常，将建筑物的物理构建自动化是不可能的。然而，软件系统是用根据实现模式自动生成的信息工件构建的。建筑者必须手工地应用构建模式，而软件架构师可以充分详细地描述软件实现模式，使在已知具体应用环境的时候生成这些模式。如在图 2 中所看到的，依据所选择的模式和技术架构原则，详细的系统模型可以转换为一组运行时工件（源代码、部署描述符，等等）。在某些情况下，可能会使用直接实现了应用模式的实现模式。在其他情况下，可能要应用多个较低层次的实现模式来实现应用模式。结合模式与 MDD模式 与 MDD 的互补性是架构驱动开发的关键。模式与 MDD 以下面两种重要的方式相关联： MDD 可以将模式的应用自动化。 传统上，模式是以文档的形式记录下来，UML 常常帮助说明模式。然后手工地应用模式。 模式为 MDD 提供内容。 MDD 让您从设计良好的模型转移到设计良好的实现上。模式在建模和实现层获取最佳实践。在不了解应用领域的模式和实现领域的模式的情况下，MDD 是不可能的。软件模式可以在抽象层中应用，并可以跨抽象层应用。可以将模式组合起来，为解决较大的问题生成复合模式，并为覆盖领域的最佳实践生成模式语言。当使用本文中的架构驱动的方法来开发时，系统的设计就如图 3 所显示的那样进行。模式和 MDD 是填补商业和 IT 之间鸿沟，并确保商业价值交付的关键。模式及 MDD 的采用： 减少了响应的时间 使随需的设计和开发成为可能 减少复杂性模式和 MDD 已经成熟，并且正交付着切实的结果。探索模型驱动开发 (MDD) 和相关方法3 : 进一步研究模型驱动开发和其他行业方法Larry Yusuf 是 Software Group Strategy and Technology 的一名解决方案架构师，在英国的 Hursley Labs 工作。他拥有 4 年的业务集成和建模经验，重点进行业务流程管理、事件和解决方案管理以及集成模式方面的工作。他撰写过这些方面的大量文章，并多次进行相关演讲。重温模型驱动开发在 MDD 中，模型不仅用作纲要或蓝图，而且还用作主要的构件，通过应用转换可以在这些构件基础上生成高效的实现。在 MDD 中，面向应用领域的模型是开发新软件组件时的主要重点。代码和其他目标领域构件通过转换来生成，这些转换是使用来自建模专家和目标领域专家的输入来设计的。 OMG 和模型驱动架构OMG 是负责制定企业应用程序领域的互操作性标准的开放协会。OMG 负责开发作为 MDD 核心的统一建模语言（Unified Modeling Language，UML），同时还推动模型驱动架构（model-driven architecture，MDA）活动。MDA 是 MDD 方法的一种形式化法。根据 OMG 的定义，MDA 是一种在自动化的工具和服务支持下组织和管理企业体系结构的方法，并同时用于定义模型和促进不同模型类型之间的转换。术语 MDA 和 MDD 经常交换使用。在本文中，MDD 指的是由软件开发人员执行的活动。MDA 保留用于其正式的 OMG 定义，此定义更多地集中于创建一个可在其中实行 MDD 的正式框架。OMG 的 MDA 指南将 MDA 描述为具有三个主要目标： 可移植性 互操作性 可重用性其目的是通过将系统的操作规范与在特定平台上实现系统的方法细节分离，从而实现这些目标。MDA 使得工具能够通过执行以下任务来帮助满足这些目标： 指定与平台无关的系统 指定平台 为系统选择平台 将系统规范转换为针对特定平台的规范MDA 模型MDA 定义了三种模型： 计算独立模型（Computation-Independent Model，CIM）描述系统的需求和将在其中使用系统的业务上下文。此模型通常描述系统将用于做什么，而不描述如何实现系统。CIM 通常用业务语言或领域特定语言来表示，仅当 IT 系统的使用是业务上下文的一部分时，才会非常有限地涉及到 IT 系统的使用。平台独立模型（Platform-Independent Model，PIM）描述如何构造系统，而不涉及到用于实现模型的技术。此模型不描述用于为特定平台构建解决方案的机制。PIM 在由特定平台实现时可能是适当的，或者可能适合于多种平台上的实现。平台特定模型（Platform-Specific Model，PSM）从特定平台的角度描述解决方案。其中包括如何实现 CIM 和如何在特定平台上完成该实现的细节。15种使用模型驱动开发MDD的理由2009-12-03 21:45转自：1. MDD is faster MDD很快（真正快速开发）在MDD应用模型中能够指定一个比传统的编程语言更高的抽象层次。该模型能够自动转化为可立即运行工作的应用程序（通过UML工具），生成可解释/执行模型代码。模型中的每个元素代表了多行代码，这样使得模型在一个更高的抽象层次比相应的代码要精简得多，更能大道至简。2.MDD is more cost-effective MDD更具有成本优势因为MDD快速开发所以比较快地推向市场，MDD意味更少的人员 专家，更高的质量，成本只是你学习MDD的成本以及工具采购，使用MDD拓展和维护应用程序的做法也更符合成本效益。通过更高级别模型阅读，比较容易理解应用程序。3. MDD leads to increased quality MDD引导质量提高因为软件架构是在一个更高模型级别定义，然后通过引擎或框架转换成代码，这样我们能够让我们最优秀的人员从事引擎和框架的开发，进而提高平台的质量。 我们在项目中学习到的最佳实践模式可以被导引到引擎或框架代码产生器中，这样将被重用到所有使用MDD的项目中。4. MDD is less error-proneMDD很少出错 测试会浪费很多时间，因为MDD可以确保代码的质量，这样让你可以专注于测试应用程序的特点功能即验收测试上，不必关注通用的一些测试项目，如基础设施相关的技术问题或安全漏洞。5. MDD leads to meaningful validationMDD引导有意义的校验业务验证都已经在更高级别的模型中完成，编程工具只能帮助你验证代码语言的错误，不能验证业务上的错误。6. MDD results in software being less sensitive for changes in personnelMDD可以不在乎人事变动不需要特别的技术高手或架构师就能够建立软件，节约人力成本。此外，如果有人加入一个项目，比较容易理解高层次的软件应用模型，这比试图通过阅读理解源代码要轻松多(banq个人体会：本人曾经只用两三个月就理解了一个中型NGOSS级别的BOSS系统(通过together逆向工程模型化)，当然也主要因为原系统基于Hibernate的模型对象化，如果是纯粹基于SQL就没有这么幸运了)。7.MDD empowers domain expertsMDD授权领域专家业务领域专家能够注重建模，而技术专家可以专注于建立一个MDD需要的框架或DSL等工具。一个软件系统不再只是程序编制就可以了，领域专家可以通过符号（如文字，图形，表格）等直接表达他们对业务领域的深入理解 。8. MDD let advanced programmers focus on the hard stuff MDD能够让高级程序员专攻难关在MDD中，高级程序员的重复性工作要少得多，他们可以专注于他们工作的创造性方面。他们可以集中精力建设MDD的工具。他们还可以指导初级开发或领域的专家，也可以申请领取困难攻关，领域专家可以专注例如模型的图形用户界面，流程和业务规则。而应用程序的集成部分（使用webservices，API调用，数据库集成等）对于领域专家来说，存在太大困难，可以由高级程序员来完成。9. MDD bridges the gap between business and IT MDD在业务和IT之间架设了桥梁领域专家（或系统分析师）可以直接参与业务发展进程（见第7点）。技术专家（软件应用）可以在一个更高的层次定义尽可能和领域概念的定义声明有关模型。通过在模型和模型实现之间定义一个重要的转换机制，就可以在业务和IT技术之间建立一个桥梁，比如使用一个基于model-driven SOA的框架。10. MDD results in software being less sensitive for changes in business requirements MDD可以减少业务需求带来改变的影响面对软件开发的问题之一是业务需求经常变化速度超过了软件系统支持改变，这对于企业是一个重点战略问题：能够保持足够长的时间调整其核心业务与IT流程。MDD使软件开发更快（见第1点），它也导致更容易改变应用（因为第2点和6）。如果在业务需求和软件之间的存在一个联系，那么应用程序甚至有可能自动适应部分模型的变化（见第9点）11. MDD results in software being less sensitive for changes in technology MDD导致技术对变化不是太敏感技术变化很快， Java EE, SOA / SOBA, webservices,REST, SCA, OSGi等等，甚至迁移到云计算环境，当您希望您的应用程序迁移到其他技术时，MDD可以确保你不必改变你的应用模型，。唯一需要改变的代码生成器（或DSL解释器）。改变后的代码生成器（或添加额外的代码生成选项）可以帮助所有的应用程序模型直接转换成基于新技术架构的代码。12. MDD really enforces architecture MDD增强架构当使用MDD开发软件应用程序，保证符合选定架构。你可以真正实现架构标准化， 构建架构原则Constructional architecture principles能够知道设计构建，并且能够反映在代码生成器或解释器中。13. MDD captures domain knowledge MDD可以截获领域知识关于MDD的优点是，你不是只创建软件，但你也捕捉正式高层次的领域知识模型。在大多数情况下这方面的知识是不明确，见文章基于DDD的DSL14. MDD provides up-to-date documentation MDD提供最新的文档当使用MDD是，您不会遭遇不完整或过时的文件，因为该模型使用正确的抽象，可以让领域专家和客户都能看懂。15. MDD enables to focus on business problems instead of technology MDD能够关注业务而不是技术停止讨论使用WS-* 或者 REST，MDD能够让你专注于业务问题如何解决，而不是着眼于如何解决这些问题的技术支撑。模型驱动开发的误解和挑战 2009年11月30日 来源： 作者：Bertrand Portier, Lee Ackerman 1-挑战：方法不当且不可用 过去，MDD的一个关键抑制因素是人们实施活动的时候没有现成的MDD最佳实践。比如说，人们在阅读有关如何执行特定任务（诸如设计高可用的解决方案）的过程文档时，文档里并没有任何MDD的内容。为了得到MDD实践，人们不得不到论文或书本里去找，然后再应用到现有的非MDD文档上。如今，MDD从业者在进行日常工作时，可用的MDD指南已经越来越多，而且那些信息嵌在他们每天使用的工具中。我们先看看开发过程，它包括利用MDD原则的“工具向导”最佳实践，这些“工具向导”隶属于整个方法和过程。 以前还有另一个阻碍因素，就是MDD与特定开发方法过度掺杂，人们无法提取MDD最佳实践，并将其应用到不同的场景中。一个典型的例子就是面向对象分析和设计（OOAD）中存在大量工具，你要么采用全部的OOAD内容，将其作为从MDD受益的一部分内容，要么就完全抛弃OOAD。MDD的最佳实践曾是OOAD框架的一部分，但人们并不知道如何在框架之外利用这些最佳实践。抽取出MDD的内容并将其应用到不同的场景中是不可能的。 2-挑战：基础设施和工具不能从MDD获益 近几年，我们看到建模工具已不局限于对特定图形符号（比如UML）的支持了，经过发展，它已然能帮助从业者完成工作。这些工具不仅支持图形建模符号，也内置了MDD特性，这些特性有利于：业务编排高质量 提高的生产率 改善的沟通 影响分析 让我们以设计模式为例，来说明工具如何给MDD带来了活力。假设某本书中描述了设计模式，我们将其称为模式规范。该规范非常有用。它描述了模式的使用时机、模式的特征，以及使用模式的好处和意义。模式规范能帮助人们理解模式并做出恰当的选择。但模式规范并不能确保设计的高质量和生产率的提高。为了从中受益，你必须将这些模式“自动化”。我们将其称为模式实现，也就是模式规范在工具中的可复用编辑。使用模式实现，设计者可以将模式快速应用到他们的设计中，也能确保这些应用准确无误。 领域独立的工具不太可能内置领域所需的所有MDD工件。工具除了提供开箱即用的MDD工件外（比如一组设计模式实现），也允许你扩展现有的工件、创建自己的工件。现在的工具包含“扩展框架”，以及最佳实践、模板和API。Rational Software Architect之类的工具还允许你构建适用于领域的MDD工件（例如模式实现、规则、约束等）。 既然你能构建这些MDD工件，那么基于资产的开发（ABD）就能让你与他人共享工件、提升复用的实践和基础设施。换句话说，ABD最佳实践和基础设施的改进支撑了MDD的采用进程。诸如Rational Asset Manager的可复用资产库能让你管理可复用的软件工件，让开发社区共享和复用工件。试想一个为领域创建的模式实现，你现在可以把它提交到资产库中，该模式经过评审和认可，社区中的其他从业者就可以复用它了。作为这个生态系统的一部分，你可以监控资产被复用的时机和方式，收集反馈信息并确保整个团队在使用合适资产的正确版本。3-误解：MDD=UML？ 有一个误解是MDD意味着你必须使用统一建模语言（UML）现状如此，完全是因为来自对象管理组织（OMG）的UML规范进行了这样的描述。消除这一误解的方法有很多。 打消这种念头的第一种方法是用MDD的方法工作，这只需要你在执行任务时把模型作为关键的工件使用，并使用利用这些模型的自动化机制。在这种情况下，模型是用语言简化了的现实，而这些语言具有定义良好的语法和语义。因此，可以在MDD中使用的语言有很多，而不仅仅是UML。 在大多数情况下，我们确实要为手头上的任务选择合适的工具。如果我们的MDD需要标准化、为人熟知、被广泛支持的语言，那UML就是一个不错的选择。UML也是可扩展的。严格来说，它能通过配置（提供定制的元素、属性和约束）进行定制。这能让UML对所作的工作来说变得具体，也能让语言更加易学易用。增强建模语言可用性或针对性的另一种方式是创建你自己的领域特定语言（DSL）。要记住的是，我们受益于使用的语言和创建的模型。为了指导投资，我们要权衡以下问题： 是否能有效地设计和理解解空间？ 能否轻松地和其他人沟通？ 是否能基于已经创建好的模型生成方案的其他部分？ 能否有效利用开发生命期之外的结果？ 是否能从实现追溯到设计？甚至需求？ 4-误解：MDD放之四海而皆准 根据前面的误解可以看出，MDD显然不是放之四海而皆准的解决方法，任何非预设的生产线工具集都可以用来构建产品。MDD就是用模型为特定情况增加价值，它适用于特定领域，跟你所开发的软件类型也是配套的。因此，我们能在自己的场景中看到很多使用MDD、有意义的方式。 5-误解：图表就是模型 MDD中关键的一点是要认识到我们在创建模型正如前面所讨论的，模型是用语言简化现实，该语言要具有良好定义的语法和语义。我们在模型中可以发现大量模型元素和一组图表。每种图表都提供了模型元素之上的一个视图。每个模型元素属于零或多个图表。我们要关注模型元素它们是什么？有哪些关系？有什么属性？我们通常使用图表来帮助我们理清这些问题。此外，我们还将图表作为和其他人沟通的方式。但模型的关键信息存在于模型元素中因为这能让我们生成所需的视图、创建所需的图表，从模型生成其他元素。如果MDD只是图表，那工具能画出漂亮的图片就能满足我们的需求了。这并不是说图表不重要。创建模型和图表的工具需要进行调整，以适合目标受众。 6-误解：代码就是模型，模型就是代码 以前对MDD的误解之一就是它只能应用于代码。MDD基本上被局限在一个较低的抽象层次，因此它的影响也很有限。很多人只用MDD工具“可视化”代码（也就是将代码图形化的逆向转换）。这样是有好处的，比如说，更好地理解大段代码，以及组件或类之间的关系。但撇开这些来说，代码可视化并不能获得先前讨论的那些MDD优势（比如业务编排、改善质量、提高生产率或影响分析），因为它所作的一切也就是让你以图形化的方式查看代码而已。这是基本、初级的图形使用方法，和预期的一样，它的投资低，收益也低。 再复杂一点儿，在代码可视化之后，让可视化结果和预期的设计保持一致。例如设计师或架构师想评审开发团队开发的代码，代码的可视化视图就能让他们对代码和设计进行比较，因为可视化结果和设计使用了相同的可视化技术（比如UML类）。不过，尽管可视化结果和设计用相同的语言表示，但两者之间仍然有很大差距，因为它们所处的抽象层次不同。MDD工具凭借可视化、可追踪性、分析和发现功能、重构支持能帮助设计师完成工作。一旦标注出设计和代码之间有分歧的地方，人工干预就必不可少了，设计师就要和开发团队进行沟通。这能提升价值，但仍然无法完全拥有MDD的优势。为了支持分析和沟通，需要增加时间和精力，而且每个项目都需要投入多次。 另一方面会出现这样的情况：人们热衷于模型和MDD，甚至仅仅为了建模而建模，却忘了把模型转换成可操作或可执行的内容。架构师可以和利益相关者、设计者和开发人员沟通，但你仍然不能完全受益于MDD。在你策划MDD的策略和方法时，要思考一下如何利用模型。譬如，部署方案最终用什么平台？如何提高代码质量和开发人员的生产率？是否能将模型转换成代码存根？ 另外，模型所包含的有用设计信息要多于生成代码所需的信息，所以我们还要看看其它方式，来利用这些已捕获的重要而有价值的信息。这包括文档的生成、测试用例、部署脚本等，这样就能显著提高项目的整体生产率。众所周知，实际的代码编写只是整个项目的一部分工作而已。 没有什么银弹。所需的代码并非都能自动生成（除非你的领域非常小）。最后，你必须处理模型和代码，MDD则会指导你利用模型、保持代码与模型之间的同步。 不过双向工程怎么样呢？如何利用自动化保持不同抽象层次之间的模型同步呢？这也是一般方案中较为棘手的问题。例如，从较高层次的模型向较低层次的模型转换时，许多元素会展开一个元素会在较低层次上演化出多个元素。一旦创建了较高层次的模型，用户就可以更新、移除、添加较低层次上的模型元素。那又该如何映射回较高层次的模型去呢？若干组详细的元素又怎样转换/映射到少量的高层次元素呢？面临这样的挑战，就很有必要想清楚，追求的这种方法到底是不是开发方法的一部分。 由于修改极可能在代码级别发生，所以若没有保持模型和代码一致的方法，模型很快就只剩文档了。最近，Rational Software Architect之类的工具在“保持一致”方面有了很大的改进，提供了可视化代码、比较和合并的功能。请注意，用于协调这些变化的方法比工具化的能力更为重要，这和治理也是相关的。举例来说，架构师看到了代码和模型之间的差异，怎么办呢？去和开发人员讨论？让开发人员修改代码？还是架构师修改模型？正如你所看到的，这些都不是完全自动化的方法。7-挑战：平台无关性面临挑战 虽然不确定平台无关性发生的时间或原因，但是在高层次上进行建模、然后生成解决方案的想法已经引起了广泛关注。或许平台无关性来自于MDA的平台无关模型，也或许来自其它地方。不管来源如何，都要认识到很难从很高层次的内容进行延展，也很难将一种表示定位到许多不同类型的实现上去。已经有一些解决方案能让用户利用模型生成全部的结果代码了。但在那些情况下，也正如前面小节中所讨论的，工具化对领域来说很有针对性，而且利用了一组约束、规则和假设才使转变成为可能。解决方案空间比较狭小，这样才为生成高层次的内容提供了可能性。随着解决方案空间的扩展，生成会变得越来越困难。 就连迁移到DSL上也会提出这样的问题：使用相同的模型作为输入，生成不同的底层实现有多容易。在利用DSL的时候，关键应该是具体的领域和当前的项目。正如从许多敏捷过程中（以及自己的经验）学到的，过度工程化、计算每种可能性都要付出代价。这同样适用于建模和使用的语言。针对具体领域并不一定就是什么坏事，事实上它反而是最佳利益。不过，创建一个领域特定的解决方案，再大范围地加以应用是不切实际的。 8-挑战：保持编码人员的创造力 在我们转向MDD，期望简化设计表达、改善沟通、生成部分解决方案的时候，我们还需要认识到这会对团队产生影响。有些团队成员可能喜欢在较低的抽象层次工作；他们也许会在场景建模时觉得拘束，反而在努力实现解决方案的时候感到自如。这些担心并非都是合理的，但还是要听出“弦外之音”。我们需要保证每个团队成员都能发挥最大的作用。 即使在处理模型的时候，我们也需要底层实现的相关专业知识。应该使用什么框架？这些框架如何整合？下面以模式为例进行说明。构建模式实现的关键输入是参考解决方案，也就是样例，它用来决定模式实现应该做什么以及怎么做。如果我们要构建自己的模式实现，那谁来构建样例？谁来判定该样例是不是解决问题的最佳方式？既然期望能简化建模体验，那又由谁来给出规则、假设和约束呢？又该怎样把它们编辑到人人都要用的工具中呢？这些问题都强调，有很多地方都需要专业知识、创造性、以及解决问题的技巧。MDD策划、启动时有一点非常重要，那就是与团队成员沟通这些挑战，并确保每个成员都能以有建设性、有效率的方式为项目效力。 9-挑战：没有可利用的内容 和其它相对比较新的方法一样，在最佳实践被充分理解和基础设施就位之前，产出的内容都很有限。现在MDD在软件行业越来越成熟，有了越来越多的推进力，可以看到，高质量的MDD内容和资产也越来越多。让这些内容从一开始就可用，对采用MDD来说是至关重要的。 10-误解：MDD仅用于开发 构建软件解决方案的时候，使用模型来指定架构、关联的服务和组件具有很大的价值，从解决方案的其它方面来说也是如此。但这仅仅是MDD给组织带来的一部分价值。要想利用模型并从中获益，就没必要把使用范围限定得这么窄。此外，我们还能利用模型来支持规范一致性。模型能提供易于理解的表示，详细说明结果方案如何支持规范要求。比如说，要表明组织是如何对细分客户群、业务范围（LOB）或渠道持续应用某规则的，就能用模型来实现这一规范需求。只提供代码到文档的一致性并不足以成为一个最佳的方案。总结 MDD带来了很多好处，它能促进沟通、改进业务编排、提升质量、提高生产率。如果你以前关注过MDD，那现在应该换个眼光来看待MDD。如果你从没关注过MDD，那现在可是关注的好时机，因为工具支持已经很成熟了。 MDD在工具集里有点儿与众不同就像你不会只使用一种语言，或是某种语言的单个库，为了达到目的，你需要选择合适的MDD方法和角度。如果