利用模式和模型驱动开发（model-driven development，MDD）可以进行架构驱动开发。这种开发类型可以使我们明确地获得架构决策，并且在系统中对架构决策自动化编码。通过使用模式及 MDD，您可以减少工作中的复杂性，并且进行按需设计及开发。阅读本文以了解更多关于这些问题的信息，这些内容是建立在对本文的同系列文章“实现模型驱动开发，增加您的 IT 系统的业务价值”的讨论之上的。

引言

在同系列的文章，“实现模型驱动开发，增加您的 IT 系统的业务价值”中，您了解了模型驱动开发（model-driven development，MDD）如何交付价值。在本文中，您将发现 MDD 如何支持架构驱动方法来进行开发。

MDD 概述

在 MDD 中，模型不仅用作框架或蓝图，而且作为通过变换的应用来生成的有效实现所依据的主要工件。在 MDD 中，当开发新的软件组件时，面向应用领域的模型是主要焦点。代码和其他领域工件是利用将来自建模专家和目标领域专家的意见作为输入的转换来生成的。

定义架构和架构风格

IEEE 将架构定义为：

软件系统的架构（在一个特定的时间点）是通过接口，那些由连续的较小组件和接口组成的组件，交互的重要组件进行组织或结构化的。

在软件架构的开发方面，我们投入了大量的工作和专家经验。架构反映了有关功能在系统中如何分布，要使用哪些技术，及要采用哪些设计模式的决定。

架构包含了一组架构原则和决定。有时候这些架构原则被记录下来，但常常推论的原因却无从得知。在一些情况下，甚至没有对架构原则进行过充分的考虑，这导致了糟糕或不一致的架构。当然，编写架构原则是一个好的主意，但是如果您可以更进一步，并以变更或引入架构原则会实际地改变系统架构的方式获取它们会怎样呢？而且，如果您能将那些同样的原则应用于多个组件、服务和解决方案会怎样呢？这些优势是 MDD 所涉及的。

在名为 Convergent Architecture: Building Model-driven J2EE Systems with UML 的书中，Richard Hubert 引入了术语 architectural style（架构风格） 来描述一组可以重复地应用的架构原则。他将架构风格定义为架构家族：

• 与公共原则和属性相关
• 传达原则和方法，从而最有效地实现设计构想

MDD 还将架构风格自动化。在 MDD 中，不仅仅简单地将所实现的解决方案的架构原则、模式，和转换编写为文档。MDD 方法还要求明确地做出架构决策。当获得了新的理解时，MDD 能够更容易地矫正不好的决策。当原则手工地应用于整个系统中时，修改是很困难的。但如果在转换中获取，并被自动地应用，修改转换和再生成是较容易的。在做出最终决策之前，尝试许多其他选择也是花费较少成本的。当通过重复地应用模式和转换以确定最佳匹配来验证解决方案满足非功能需求时，该方法是有价值的。

MDD 项目所采用的架构风格是受很多因素影响的，它们包括：

• 被开发软件的类别（例如，企业整合、实时的嵌入的、最终用户界面）
• 要使用的软件平台的类别（例如，消息传递中间件或基于规则的系统）
• 公认的软件开发范例（例如面向服务的或面向方面的）
• 软件的领域（例如电信、金融，或零售）
• 系统或被开发系统的架构原则
• 架构风格的范围（从整个行业的到具体项目的）
• 软件开发组织的机构风格（例如，建模惯例）
• 解决方案的非功能需求（从服务的质量到表现风格和现有的基础架构）

获取专家经验

许多 IT 项目都缺乏能够做出架构决策的有技能的专家。这常常导致对关键角色的过渡依赖，缺少了他们将会使项目面临巨大困难。

MDD 的一个关键的方面是专家经验的获取。与其每次需要专家在现场做出最佳实践的决策，到不如在自动的模式和转换中获取他们的专家经验，这样您可以再次运用这些经验。该方法让不具有专家知识的开发人员能够构建成熟的系统。

为了构建 MDD 框架，您需要获取两个主要类型的专家经验：逻辑的（功能的）架构经验和技术的架构经验。逻辑和技术的架构经验都是整个架构风格的一部分。

逻辑的架构经验

解决方案的逻辑架构涉及必须表现出来的功能，而不是利用特定技术实现功能的方式。当使用 MDD 方法时，目标是在逻辑层建模，并且生成实现工件。

在 MDD 中，您定义出逻辑架构风格并且开发了支持该风格的统一建模语言（Unified Modeling Language，UML）概要文件、模式和建模惯例。与定义逻辑架构相关的许多专家经验是在 MDD 框架中获取的，并且在每次开发新的应用程序时应用它们。新应用程序的设计师能够更多地关注问题领域，并且在应用程序间通用的软件架构的一些方面上少投入精力。

技术的架构经验

现代的中间件平台为了支持那些构建在其上的各种应用程序提供了丰富的特性。然而，单个的项目经常使用那些功能的子集，并且它们以专门的方式来使用这些子集。

一个特定的项目（或计划）利用其所选择的中间件平台的方式确定了技术架构。在最佳实践文档中可以获得技术架构，或者可以将技术架构从开发人员传递给其他开发人员。实际上，当处于手工过程中时，很难确保技术架构被一致地应用。

MDD 向您提供了直接实现技术架构的机会。与其在文档中记录，例如，“对所有公共方法的入口和出口都将利用 log4j 来记录”，到不如您实现一个转换来根据该规则生成日志代码。 MDD 方法的一点好处是让您集中在项目较早时期，并且更彻底地考虑技术架构。如果您一开始就了解到这点，并且分配了充足的时间来定义技术架构，那么这将会带来实在的收益，并且在项目的后期节省您很多时间。

了解模式

在 MDD 中，您利用具体领域的概念来建模。例如，在企业整合领域中，您可能会用到消息、代理和适配器。应用领域的词汇中还常常包含模式。在企业整合领域中，您可以保证交付和发布订阅模式。这些模式不是单个的元素，而是引入元素和对其行为的约束之间的关系。

（建筑）架构师 Christopher Alexander 在其著名的 Timeless Way of Building 中引入了模式语言的概念。他的想法，模式作为一般设计问题的最佳实践方法，已经得到软件团体的广泛采纳。他引入了模式语言的概念，他将其定义为可以一起为特定环境或问题领域中的设计提供词汇的一组相关的模式。

在后继卷，A Pattern Language 中，Alexander 介绍了拥有面向城镇设计（目标为计划者）和建筑物（目标为架构师）的子语言，以及面向构建（目标为建筑者）的子语言的具体模式语言。

Alexander 的模式实例是：

城镇模式

环形路、夜生活和连排房

建筑物模式

屋顶花园、室内日照，和避暑别墅

构建模式

好材料、支柱连接，及半英寸的装饰

每个模式都包含它所适用的环境的信息，以及它与其他模式的关系。Alexander 解释说，当使用模式语言时，“我们总是将其用作顺序，经历模式，总是从较大的模式转移到较小的模式，总是从创建结构的到修饰那些结构的，再到修饰那些装饰的模式。”

模式语言的想法就像适用于适用于建筑物架构一样，也适用于软件开发，而本文始终在使用该术语。软件开发的特点意味着，额外地将用模式语言进行设计的过程自动化是可行的。

就像用 Alexander 的方法一样，您可以通过从较大的模式转移到较小的模式来设计软件系统，如图 1 所示。需要人的专家经验来选择设计环境中适当的软件模式。

当把模式应用于软件时，有了一个额外的好处：可以将模式的应用自动化，以便当选择模式时，可以用所有与该模式相关的结果展开设计。一个简单的软件模式实例是 Getter/Setter 模式，在该模式中，总是通过一致命名的操作来访问属性。该模式可以自动化，以便将模式应用于类 Customer 的属性名，向 Customer 类添加名为 getName 和 setName（以及恰当的参数）的操作。

通常，将建筑物的物理构建自动化是不可能的。然而，软件系统是用根据实现模式自动生成的信息工件构建的。建筑者必须手工地应用构建模式，而软件架构师可以充分详细地描述软件实现模式，使在已知具体应用环境的时候生成这些模式。

如您在图 2 中所看到的，依据所选择的模式和技术架构原则，详细的系统模型可以转换为一组运行时工件（源代码、部署描述符，等等）。例如，如果您使用了 Getter/Setter 模式的模型，那么您可以针对具体平台，例如 Java™，根据该平台的实现模式，为那些方法生成实现代码。在某些情况下，您可能会使用直接实现了应用模式的实现模式。在其他情况下，您可能要应用多个较低层次的实现模式来实现应用模式。

结合模式与 MDD

模式 与 MDD 的互补性是架构驱动开发的关键。模式与 MDD 以下面两种重要的方式相关联：

• MDD 可以将模式的应用自动化。

  传统上，模式是以文档的形式记录下来，UML 常常帮助说明模式。然后手工地应用模式。

• 模式为 MDD 提供内容。

  MDD 让您从设计良好的模型转移到设计良好的实现上。模式在建模和实现层获取最佳实践。在不了解应用领域的模式和实现领域的模式的情况下，MDD 是不可能的。

软件模式可以在抽象层（例如设计模式和实现模式）中应用，并可以跨抽象层（将设计元素与代码相关联的模式）应用。您可以将模式组合起来，为解决较大的问题生成复合模式，并为覆盖领域的最佳实践生成模式语言。

当使用本文中介绍的架构驱动的方法来开发时，系统的设计就如图 3 所显示的那样进行。

活动的顺序不意味着在下一步开始之前必须完成这一个步骤。我们可以使用迭代的方法，通过多次经过这些步骤，每次添加一些功能来构建解决方案。

利用 IBM 电子商务模式复用资产

利用模式和 MDD 的互补性，利用架构驱动开发方法的项目的成功依赖于模式和 MDD 框架的质量。您必须确保将覆盖了商业、应用和运行时层的模式语言自动化，同时，当应用每个模式时，提供服务和行为的预期质量的定义。IBM 电子商务模式提供了每个层次上的模式，可以让您从中选择特定的模式（根据我们的解决方案需求），来构成您的模式语言。

IBM Patterns for e-business 可以帮助简化资产的复用，通过使未来的合约更简单且更快的方式来获取 IT 架构师的经验。对这些资产的复用节省了时间、金钱和工作量，并且帮助确保坚固的、构架恰当的解决方案的交付。IBM 电子商务模式的目的是获取并发布被使用、测试、并证明是成功的电子商务工件。假定所获取的信息符合大多数，或 80/20 情况。通过最佳实践的方针及相关链接，IBM 电子商务模式在进一步的发展。

分层的资产模型

电子商务模式方法让架构师通过复用来自已证实的成功经验的组件和解决方案元素来实现成功的电子商务解决方案。模式方法是基于一组任何现有的开发方法都可以使用的分层资产。构建分层的资产，以便每个详细的层次构建于前一层次之上。这些资产包括：

商业模式

确定用户、企业和数据之间的交互。

整合模式

当不能提供根据单个的商业模式而来的解决方案时，将多个商业模式连在一起。

组合模式

表现为通常出现的商业模式和整合模式的组合。

应用模式

提供描述了商业模式或整合模式之中的应用程序组件和数据如何交互的概念上的布局。

运行时模式

定义了支持应用模式的逻辑中间件结构。

运行时模式描述了主要的中间件节点、它们的角色和这些节点之间的接口。

产品映射

为每个运行时模式确定已证实的并测试过的软件实现。

最佳实践指导方针

用于电子商务应用程序的设计、开发、部署及管理。

参见图 4，观察可视化的表示。

模式和 MDD 是填补商业和 IT 之间鸿沟，并确保商业价值交付的关键。模式及 MDD 的采用：

• 减少了响应的时间
• 使随需的设计和开发成为可能
• 减少复杂性

META Group（现在是 Gartner Group 的一部分）的 Thomas Murphy 所说的“使用模型驱动、基于模式的开发框架和工具的组织，可以获得开发团队中引人注目的生产力和质量提高”得到广泛的引用。

MDD 促进了商业灵活性的提高，这是在不断地随需应变的世界里取得成功的关键。模式驱动开发、IBM 电子商务模式和 MDD 的成功是这些技术的互补性的结果。

IBM 电子商务模式是分层的、可复用的、整合的，且已证实的模式，它向 MDD 方法提供了质量输入。MDD 通过将电子商务模式自动化来增大它们的可复用性，所以它们可以很容易地被再应用。电子商务模式在创建企业级 MDD 框架时提供关键内容，这些框架对于跨企业中的 IT 系统获取并实现公共的架构风格是特别重要的。

系列文章 随需构架解决方案 的第 11 部分很好地说明了此概念。它使用了一个实例，在该实例中，IBM 电子商务模式向 MDD 框架提供输入，用于生成基于消息传递模式的企业服务总线（Enterprise Service Bus，ESB）组件。

总结

在本文中，您了解了如何用模式与 MDD 的组合来进行架构驱动的开发，这样可以明确地获取架构决策，并且在系统中对架构决策自动化编码。您还探究了实现架构驱动方法的好处。

参考资料

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
• 阅读本系列的第 1 部分：实现模型驱动开发，增加您的 IT 系统的业务价值（developerWorks，2007 年 5 月）：阅读本文的同系列文章，它解释了通过 MDD 方法可以交付的价值。
• 阅读本系列的第 3 部分：进一步研究模型驱动开发和其他行业方法（developerWorks，2008 年 7 月）：阅读本文的同系列文章，它将带领您深入了解模型驱动开发（MDD），比较软件工厂、领域特定语言（DSL）和 MDD 方法。并探索如何将开发构件可视化为模型，以及使用可执行的统一建模语言（UML）方法等内容。
• 阅读 IBM 红皮书 Patterns: Model-Driven Development using IBM Rational Software Architect，从中了解更多关于 MDD 的信息。该红皮书介绍了一个详细的案例研究，并且说明了如何利用 Rational Software Architect 工具来实现该方法。
• 阅读 Timeless Way of Building，作者 Christopher Alexander（Oxford University Press，1979 年 8 月）。ISBN 0-195-02402-8。
• 阅读 A Pattern Language Towns, Buildings, Construction，作者 Christopher Alexander。（Oxford University Press，1977 年 8 月）。ISBN 0-195-01919-9。
• 阅读 Richard Hubert 的书，Convergent Architecture: Building Model-driven J2EE Systems with UML。（John Wiley & Sons, Inc.;2001 年 11 月）。ISBN 0-471-10560-0。
• IBM 红皮书，Patterns: Model-Driven Development using IBM Rational Software Architect 向您介绍更多关于 MDD 实践的信息。（IBM，2005 年 12 月）ISBN 0-738-49288-4。
• 了解更多关于 IBM Patterns for e-business 的信息，这是一组可以帮助加速基于 Web 的应用程序的开发过程的可服用资产。
• 密切关注 developerWorks 技术活动和网络广播。
• 订阅 developerWorks 模型驱动架构（MDA）与模型驱动开发（MDD）相关内容的 RSS。

• 参与论坛讨论。
• 参与 developerWorks blogs，讨论 MDD，并加入 developerWorks 社区。