模型驱动开发（Model-driven development，MDD）是软件开发的一种样式，其中主要的软件工件都是由代码和其他工件所生成的模型。其目标是提高企业应用程序开发的生产力和质量。模式在 MDD 的模型转换和代码生成中扮演重要角色。本系列文章详细地讨论了利用 IBM ® Rational® Software Architect（支持 MDD 的集成开发环境）进行模型驱动及基于模式的开发范例。 引言模型驱动开发（Model-driven development，MDD）是由模型驱动体系架构（Model-driven Architecture，MDA）技术支持并驱动的新软件开发范例，是对象管理组织（Object Management Group，OMG) 发布的软件设计方法。MDA 提供一组指南，用于构建表示为模型的规范，从独立于平台的模型（platform-independent model，PIM）开始，通过适当的具体到领域的语言，然后转换为用于实际的实现平台的一个或多个具体到平台的模型（platform-specific models，PSMs）。它可以是很多种平台，例如 Java™ 2 Platform、Enterprise Edition (J2EE™)、CORBA 或 .Net，以通常的程序设计语言实现，例如 Java™、C# 和 Python。MDA 通常用自动化的工具来执行，如 IBM® Rational® Software Architect。MDD 由 MDA 驱动，并更着重于模型转换和代码生成。 然而，MDD 所使用的基于代码生成的方法有它不利的方面，这是由于例如所生成代码中的约束、技术不强的开发人员和与模型的紧耦合等因素造成的。当企业 100％ 地投入到代码生成中时，就没有余地进行调整了，尤其是在开发人员仔细检查其模型的时候。 基于模式的开发方法能够帮助解决该问题。模式是在已知环境中重现问题的解决方案。模式将设计人员的时间、技能和知识进行萃取，从而解决软件问题。此外，当模式在许多不同的项目中重复地使用时，它就成为了最佳实践。通过设计特殊的设计模式，开发人员可以更灵活地控制所生成的代码，这就不简单地拘泥于抽象模型了。 而且，MDD 可以通过转换自动化地实现模式，这将排除重复的低层次开发工作，并且可以将技术性的专家经验加入到代码中，以提高一致性和可维护性。为了生成能够将变更反映到实现架构的解决方案工件，就要迅速地重新应用被修改的转换。 本文关注于如何用基于资产的开发来优化作为集成开发方法的 MDD。使用该方法，开发人员首先用统一建模语言（Unified Modeling Language，UML）构建对象模型，然后通过利用了模式存储库的代码生成工具来生成代码。 使用 Rational Software Architect 来应用 MDD阅读了此信息，您可能发现，应用该开发方法需要可以支持以下内容的集成开发环境（Integrated Development Environment，IDE）：
Rational Software Architect 是提供以上所有功能的工具。Rational Software Architect 是能够利用 UML 进行模型驱动开发的集成设计和开发工具，用以创建良好架构的应用程序和服务。有了 Rational Software Architect，您可以：
本系列的这些文章按照如下顺序进行组织： 第 1 部分：本文，着重于 MDD 和基于模式的开发方法的概述 第 2 部分（即将发布）：利用 Rational Software Architect 进行 MDD 和基于模式的开发的方法 第 3 部分（即将发布）：案例研究 UML 模型MDD 的主要特点之一是将模型作为重要工件。模型是以特定的观点对系统的描述，忽略了不相关的细节，同时更清晰地看到关注的特性。在 MDD 中，模型必须是计算机能够处理的，这样您可以用自动化的方式访问模型的内容。为了让您能够生成工件，模型必须是计算机可以处理的。白板上的图可能会满足作为模型的其他标准，但直到您以计算机能够处理的方式获取它时，您才能在 MDD 工具链中使用它。 软件模型一般用 UML 表示。UML 模型隐藏了技术实现细节，这样可以利用来自应用领域的概念来设计系统。一般应用程序设计用 UML 建模工具，例如 Rational Software Architect，以及与应用领域相关的概念来实现。 甚至在 MDD 之前，使用 UML 模型来设计软件就是很好的实践。在大部分情况下，以两种方式来使用模型：
在 MDD 中，模型不仅用作框架结构或蓝图，而且作为主要工件，通过应用转换，由这些工件生成有效的实现。在 MDD 中，在开发新软件组件时，准确的描述面向领域的应用程序模型是主要关注点。代码和其他目标领域工件利用根据建模专家和目标领域专家而设计的转换来生成。 转换UML 建模是有价值的技术，但人工地将模型和代码同步是容易出错且消耗时间的。转换是区别 MDD 与其他使用建模的方法的主要特征。MDD 是将开发过程自动化，从而生成任何工件，这可以源于模型中的信息。除了代码，由转换而生成的工件包括，但不限于以下内容： 文档：在遵照正式的开发方法的组织中，生成文档占据重要的开发工作。保持文档与实现的一致是众所周知的难题。当使用 MDD 时，由模型来生成文档。这既确保了一致性，又使得开发人员每天处理的模型中的信息可用，而不是在很难导航的文档中搜寻。文档可以通过工具，例如 Rational Software Architect 的 Report Generator 来生成，或者通过转换来生成。 测试工件：由软件模型中包含的信息很可能生成基础的测试工件（例如，利用 JUnit）。 构建并部署脚本：利用专长，构建和部署架构师可以创建生成构建及部署脚本的转换。 其他模型一个系统包含不同的抽象层次（分析、设计、实现）上的相互依赖的模型，表示系统不同的部分（UI、数据库、业务逻辑、系统管理），不同的关注点（安全、性能和弹性），或不同的任务（测试、部署建模）。在许多情况下，由一个模型部分地生成另一个模型是可能的事情（例如，从分析模型转换为设计模型，或者从应用模型转换为测试模型）。 模式MDD 的另一个主要特征是获取专家经验。模式获取最佳实践解决方案来重现问题。在 MDD 中，模式可以出现在建模的所有抽象层次上。例如：
模式是可以进行组合的，用以为解决更大的问题而生成模式菜单，并且涵盖领域的最佳实践。 模式指定模型元素的特征，以及那些元素之间的关系。当您将模式应用到模型中时，您可以将模式自动化，在转换中新的元素被创建，已有的元素被修改，以符合模式的定义。 模式提高解决方案的一致性和质量。这可以通过在 MDD 中使用转换来自动化模式的实现来完成这一点，这样可以排除重复的低层次开发工作。与其在构建解决方案工件时重复且人工地应用技术专家经验，倒不如将专家经验直接编入转换之中。这样做就拥有了一致性和可维护性的双重优势。迅速地再次应用修改了的转换，从而生成将变更反应到实现架构上的解决方案工件。 从业务问题到软件解决方案图 1 展示了如何利用 MDD 将业务问题转换为软件解决方案。评审业务问题，并且应用一些通用的业务模式。这样做部分地填充了设计模型，并且在构建的具体业务功能中加入细节。然后，应用平台独立的设计模式，以将设计模型转换为运行时独立的组件。在那之后，选择运行时平台，并且使用具体到运行时的实现模式来生成工件。 图 1. 利用 MDD 将业务问题转化为软件解决方案
使用带有模式的 MDD 的好处软件开发行业已经发现了采用带有模式的 MDD 的很多好处。一些重要的包括： 提高生产率： MDD 通过从模型生成代码和工件来减少软件开发的成本，这样做提高了开发人员的生产率。 增加复用： MDD 在应用于大型项目或组织层时优势尤其明显。这是因为在每次复用它们时，开发转换的投资回报率都有所提高。使用可靠且经过测试的转换还可以提高开发新功能的可预计性，并且减少项目风险（因为架构和技术问题已经解决了）。 提高可维护性：技术的演进导致解决方案组件逐渐成为先前平台技术的遗产。MDD 帮助解决这一问题，它引出可维护的架构，在该架构中可以快速且一致地进行变更，使您更有效地将组件迁移到新技术上。 灵活性更强：高层次的模型与实现细节无关。保持模型与实现细节无关可以使得处理底层平台技术及其技术架构中的变更成为更容易的事情。通过更新转换来完成对实现的技术架构的变更。再次对原来的模型应用转换，从而生成依照新方法的实现工件。 一致性： 人工地应用编码实践和架构上的决策是容易出错的活动。MDD 确保一致地生成那些工件。 提高沟通性： 模型省略了与了解系统逻辑行为不相关的实现细节。因此，模型更接近问题领域，减少了涉众所了解的概念和解决方案所用的表示语言之间的语义鸿沟。模型还简化了设计层系统的理解及退出。这形成了对系统的沟通性的增加。 保留专家经验： 项目或组织经常依赖于重复做出最佳实践决策的重要专家。有了模式和转换中获取的专家经验，他们不需要出现在项目的其他成员面前来应用（得益于）这些经验。 降低风险： 当使用 MDD 方法时，早期的应用程序开发着重于建模活动。这意味着，直到晚些时候才选择具体的技术平台或产品版本是可能的（当进一步的信息可用时，从而减少风险）。 经验教训MDD 是可靠的开发方法。然而，行业反馈指出，不是所有使用 MDD 的项目都是成功的。这一般源于一些因素：
要帮助您从 MDD 中获得最大利益，以下是一些从过去项目中获得的经验。 选择恰当的候选项目： MDD 在应用于大型项目或组织层之上时特别强大，因为来自转换的开发或购买中的投资回报（return on investment，ROI）在每次复用时都增加了。好的候选项目也应该有良好的架构和可重复的行为的模式，以便可以对那些模式进行抽象，从而获取专家经验，并且在转换中使用。 考虑附加的成本： 您可能需要考虑开发或购买转换的成本，但是谨慎的成本计划可以确保长期内的成本降低。 取得小的成功： 在许多组织中，一些怀疑论对新的方法进行质疑，直到新方法得到证实。如果这是您使用 MDD 方法的第一个项目，那么明智的做法是将 MDD 工具的开发分割为许多迭代。后继的迭代建立于您所获得的经验之上，允许您支持越来越广的业务应用程序的情景集。 发展适当的技能： MDD 要求架构师和开发人员要熟悉 UML 和 MDD 的 IDE。在团队中培养成这些技能最初要花些时间，这导致了项目延迟。然而，对于同样的项目团队，后继的项目将更容易。如果这是您第一个使用 MDD 的项目，那么引入专家来发动团队是很好的选择。 时刻考虑复用：在应用程序开发人员为业务应用程序生成工件时，它们会多次使用为项目而构建的 MDD 工具。该工具在后继的项目中得到复用也是可能的。时刻考虑在更大的环境中复用将在长期内为您的组织带来重大的好处。 选择适当的开发工具。 拥有适当的工具将确保您从 MDD 中获得最大价值。项目团队（包括项目经理、业务分析人员、解决方案架构师、开发人员，和测试人员）应该评估并验证正在使用的开发工具。 总结本系列第 1 部分描绘出模型驱动和基于模式的开发范例的全景。概括地说，MDD 开启了模式的潜能，以创建设计优良的解决方案，而模式为 MDD 提供内容。 参考资料学习
|
版权所有：UML软件工程组织