MDD (Module-Driven Development)第 1 部分: 实现模型驱动开发，增加您的 IT 系统的业务价值

探索模型驱动开发 (MDD) 和相关方法，第 1 部分: 实现模型驱动开发，增加您的 IT 系统的业务价值 发现使用 IBM Rational 软件中的建模工具的优点

级别： 中级

Larry Yusuf (yusuf@uk.ibm.com), 解决方案设计师, IBM　
Mandy Chessell (mandy_chessell@uk.ibm.com), 高级技术职员, IBM　
Dr. Tracy Gardner (tgardner@uk.ibm.com), 解决方案架构师, IBM　

2007 年 5 月 31 日

您是一位试图增加 IT 系统业务价值的领头架构师或项目经理吗？如果您是，本文可以为您提供帮助。本文解释了影响现代 IT 开发的业务推动力，并且向您介绍了模型驱动开发（model-driven development，MDD）。MDD 是主流软件开发实践的提高，并且让您的 IT 系统能够对业务推动力更加敏感。了解 MDD 方法以及您如何可以将其应用于实现业务价值最大化，并且减少解决方案开发的成本。利用 MDD，通过利用转换和重复性的消除将实现模式自动化，并将低层次的开发工作自动化，您可以提高解决方案的一致性和质量。

了解您目前的业务环境

IT 开发不会孤立出现。IT 的目的是简化业务运作，这意味着业务环境的需求推动着我们开发 IT 的方法。表 1展示了一些当前的业务推动力。

表 1. 当前的业务推动力

推动力	描述
随需应变的业务	由于商家应该更具适应性和灵活性，所以 IT 系统要做得太多了。
业务关联	大家强烈关注 IT 部门交付业务价值。软件必须是与业务相关的。业务及 IT 人员之间的错误传达会导致从 IT 交付观点看成功的项目，被视为业务上的失败。
成本控制	根据承诺的力度对 IT 投资的时代早已过去。现在，IT 部门在强大的预算约束下运作，并且应该证明其金钱方面的价值。
不断增加的复杂性	软件系统在规模和复杂度上不断的增加，从而满足业务需要。对小规模开发有效的技术，不一定适用于按企业级的计划。
技能可用性	当今 IT 平台的成熟意味着交付软件需要专家的经验。许多组织努力寻找着有充足技能的专业人员支持它们的开发。项目常常依赖于一些关键的人物，如果这些人离开了，损失会很严重。
变化的中间件环境	现今的应用程序都部署到极为多样的中间件平台上，平台技术的变更率没有表现出减慢的迹象。商家希望利用中间件中的先进技术，但不愿意重复地编写它们的应用程序。

回页首

了解软件开发的模型驱动方法

模型驱动开发（Model-driven development，MDD）是软件开发的一种样式，其中主要的软件工件是模型，根据最佳实践，可以从这些模型生成代码和其他工件。模型是从特定角度对系统进行的描述，它省略了相关的细节，因此可以更清楚地看到感兴趣的特性。例如，结构工程师会创建适合于确定建筑物承载特性的模型。

在 MDD 中，我们引入了附加的标准，即模型必须是计算机可读的。例如，我们必须能够以自动化的方式估计模型的内容。模型的计算机可读性是它能够生成工件的必要条件。白板上的图也许满足作为模型的其他标准。然而，直到我们以计算机可读的方式获取它时，才能够在 MDD 工具系列中使用它。

软件模型一般用统一建模语言（Unified Modeling Language，UML）表示。UML 是用于说明、可视化，并文档化软件系统的语言。它为软件模型提供了可视化的表示和基础的语义。UML 还拥有用来确保自动化的标准化的计算机可读的序列化格式。

软件模型隐藏了技术实现的细节，因此，我们可以利用来自应用领域中的概念来设计系统。应用程序一般是利用 UML 建模工具，例如 IBM Rational® Software Architect，并使用与应用领域相关的概念进行设计的。例如，当我们工作于企业集成领域中时，我们会利用消息、代理和适配器这样的概念为应用程序设计建模。随后，我们可以精练该软件模型，并且为其组件设计详细内容。

作为示意图和蓝图的模型

利用模型来设计软件是一个公认的实践（尽管的确不普遍）。目前，模型大多用于通俗地传达系统某个方面的示意图，或用于描述您手动实现的详细设计的蓝图。

将模型作为文档和规范是有价值的，但是这需要严格的规程来确保模型与实现进度保持一致。通常，时间约束意思是在没有首先变更模型的情况下，对实现进行了更新。不准确的模型比没有模型更有害。

在本文中，我们用术语 MDD 来表示由模型自动生成工件的方法。

利用准确的模型进行自动生成

在 MDD 中，模型不仅用作示意图或蓝图，它们还作为通过转换的应用，生成有效实现的主要工件。在 MDD 中，当开发新的软件组件时，首要的焦点是面向应用领域的模型。代码和其他目标领域的工件是利用由建模专家和目标领域专家的参与所设计出的转换，来生成的。

MDD 能够极大地减少解决方案开发的成本，并且提高解决方案的一致性和质量。这些好处是通过自动化带有转换的实现模式来形成的，它消除了重复的低层次开发工作。在构建解决方案工件时，与其重复地手动应用技术经验，不如将这些经验技巧直接编入转换中，并且还带来一致性和可维护性的优势。修改了的转换可以快速地重复应用，用于生成反应出对实现架构做出的变更的解决方案工件。

MDD 将应用程序开发的重点从平台上移开，让具有应用程序开发经验的开发人员，在不用关注具有平台经验的开发人员的领域中的平台级概念的情况下，设计应用程序。平台经验直接在转换中获取，而不是编制为项目指导，或者更糟的是，在项目进行的过程中重新去多次发现。同样，关于实现架构的决策也直接编入转换中，而不是编制为架构决策的文档。

根据情况的不同，合适的成品转换会用于直接的使用，或者作为扩展的基础。另外，您可以为项目构建定制的转换。

不仅是代码

虽然代码和其他平台工件的生成是 MDD 的重要部分，但是 MDD 样式的自动化有更深的意义。软件开发项目需要生成许多非代码的工件，其中一些完全或部分地来源于模型。以下的列表提供了一些由模型生成的通用工件实例，但您可以考虑其他的。

文档

在遵照正式的开发方法的组织中，生成文档用去了大量的开发精力。将文档与实现保持一致出了名的困难。当使用 MDD 时，文档由模型生成，它们确保了一致性，并且使开发人员日常处理的模型中的信息可用，比在很难将信息定位的文档中要好。工具，例如 Rational SoDA 和 Rational Software Architect Report Generator （参见 参考资料）可以生成文档，或者文档由转换来生成。

测试工件

由软件模型中所包含的信息生成基本的测试，例如利用 JUnit，是有可能的。如果执行了额外的具体到测试的建模（例如，利用 UML Profile for Testing），那么就可以生成完整的测试实现。基于模型的测试是关于由模型生成测试的规程。

构建及部署脚本

基础结构架构师利用他们的经验可以创建生成构建及部署脚本的转换。

其他模型

一个系统中会涉及到许多不同抽象层次上（分析、设计、实现）的相互依赖的模型，它们代表系统的不同部分（UI、数据库、业务逻辑、系统管理）、不同的关注点（安全性、性能，及可靠性），或者不同的任务（测试、部署建模）。在许多情况下，由一个模型部分地生成另一个模型是有可能的，例如，从分析模型到设计模型，或者从应用模型到测试模型。

模式应用

模式获取最佳实践解决方案来重现问题。模式指定模型元素的特性，以及那些元素之间的关系。您可以将模式自动化，以便创建新的元素，以及修改现有的元素来遵照该模式，然后将模式应用于模型中。

在本文中，我们介绍了所有这些技术，除此之外还有利用 MDD 进行的代码生成。

回页首

为 MDD 项目估计任务

MDD 对我们构建业务应用软件的方式有着深远的影响。它获得了顶级技术人员的经验及决策，通过为项目的需求所定制的工具使余下的团队可以获得这些经验和决策。由于大量的低层次编码工作已经自动化了，所以开发的成本，以及测试业务软件的成本极大地减少了。错误的数量减少了，并且在工作完成的方式上增加了一致性。

然而，MDD 确实创建了项目的不同一面，需要管理一个项目中的另一个项目。内部工程包含了 MDD 工具的开发，这些工具可以供开发团队在外部项目中构建业务应用程序时使用。一般来说，开始要将一个业务应用程序确定为利用 MDD 工具构建的，着重于需求，并且可以对该方法进行一些调整的第一个项目。一旦开始开发了，就可以将 MDD 工具用于构建许多业务应用程序了。

对于两个项目，谨慎地组织和计划是非常重要的，特别是在一开始的时候。在与开发项目相关的平常问题之上，存在着管理额外的内部依赖集的需求。MDD 工具需求必须在应用程序开发人员需要它们之前进行确认和开发。两个项目的任务流要互相联结的，这样可以确保由 MDD 工具项目而来的交付产品是及时的。

图 1 展示了 MDD 项目中的任务流。阴影的任务可能在传统项目中执行。白色的任务是为具体项目构建 MDD 工件的附加任务。

图 1. 开发 MDD 工件的步骤

您可以在业务应用程序开发之前开发所有的工具，或者利用更加迭代的“准时制（just-in-time）”方法。不论采用哪种方法，重要的是，在业务应用程序项目开放过程中，允许有额外的时间来开发被确定为第一次使用的工具的增强。

任务

开发 MDD 工具的最初任务出现在所有的传统开发方法中。您的解决方案架构师执行了这些任务，并且定义了业务应用程序的高层结构。

创建解决方案架构

定义业务应用程序的概念结构。这可以表示为，在构建业务应用程序时，开发人员将要采用的许多架构风格。

定义运行时环境

定义业务应用程序运行所处的运行时环境。这包含所有的测试环境，其中包括单元测试和最终的产品环境。

一旦开始的两个任务完成了，解决方案架构师就会很好地了解了为业务应用程序开发什么需求了。到此，具体到 MDD 的任务可以开始了：

确定通用的模式和标准

解决方案架构师确定出在业务应用程序中的重复模式。这些模式的经常出现，是由于架构风格的一致使用，或者由于运行时平台的需求。通用的模式可以利用对组织的开发过程来说标准的方式进行描述。

确定用于复用的现有 MDD 资产

解决方案架构师比较他们用现有 MDD 资产确定出的通用模式，对他们的架构做出任何必要的小调整，从而使用已经可用的内容。现有的 MDD 资产可以来自先前的 MDD 项目，或者来自标准的工具和包。

定义设计模型

解决方案架构师定义开发人员在开发业务应用程序时必须依据的建模规则。一般开始会选择 UML，且解决方案架构师会更精确地定义如何利用 UML 来获取设计。解决方案架构师需要了解不同类型的 UML 图（例如，类图、协作图、活动图）以及什么时候适合使用哪一种。

确定独立于运行时的组件模型

该任务创建了一个 UML 模型的定义，该模型以独立于运行时的方式为业务应用程序指定了组件。该任务可以由解决方案架构师执行，或者由了解所有运行时环境的有经验的应用程序开发人员执行。

生成示例工件

应用程序设计人员为典型的场景手动编制结果的业务应用程序工件。这些示例工件是作为 MDD 模板和转换的蓝图的。该任务应该由您的最佳应用程序设计人员执行。

确定工具系列

该任务确定了开发项目所需的 MDD 工具。该任务是由掌握 MDD 工具开发的人来完成的。一旦完成了该任务，您就可以创建构建 MDD 工具所需的工作的详细计划了。

 

接下来的五个任务构建了 MDD 工具：

从示例工件中抽取模板

MDD 工具开发人员审阅示例工件，并且将它们用作为每个待生成的工件开发模板的基础。模板包含了对于已生成工件的每个实例都相同的代码。MDD 工具开发人员需要掌握已生成工件的语言和格式方面的技能。它还包含转换所使用的，根据模型的内容插入工件的具体部分时所需的标志。

设计、代码、测试转换及模式

该任务需要 Java 程序设计能力。对于每个转换或模式，MDD 工具开发人员需要书写阅读 UML2 模型的 Java 代码，然后更新模型，或者对模板进行适当填充，生成新的工件。

包装 MDD 工具

MDD 工具必须打包成可以安装到每个人或您的应用程序开发人员的工作台中的形式。这里有一些选择：

• 根据打包的指导，将所有的文件放入 zip 文件中
• 使用标准的 Eclipse 插件管理
• 使用可复用的资产（reusable asset，RAS）存储库
• 提供完整的下载 Web 站点

该选择依赖于可能安装 MDD 工具的人数。一种合理的方法是着重于支持您最初的应用程序开发人员，然后当更多人开始使用它时，按照需要升级打包机制。

为应用程序开发人员生成文档及培训资料

解决方案架构师或技术作者介绍了应用程序开发人员如何构建模型，并且选择恰当的转换来生成正确的工件。

利用关键的场景来验证工具系列

这个最后的 MDD 工具开发任务是一个测试角色。MDD 工具建模并生成每个运行时平台所需的所有工件，来支持一些关键的场景。

 

现在已经准备好 MDD 工具让应用程序开发人员开始使用了：

培训应用程序开发人员使用 MDD 工具

在使用 MDD 工具之前，告诉应用程序开发人员新的开发过程是如何工作的。他们需要了解什么时候以及如何使用 MDD 工具，并且还要知道这些工具如何配合他们的传统工具，例如配置管理。

开发业务应用程序

到此，应用程序开发人员使用 MDD 工具来构建业务应用程序。

 

MDD 工具系列

图 2 中的流展示了开发人员如何能够利用 MDD 工具开发部分业务应用程序。在此实例中，开发人员审阅了业务问题，并且选择了设计模式。该模式部分地填充了设计模型，而开发人员填写他们正在构建的具体业务功能的细节。此后，开发过程就完全自动化了。开发人员选择一项来生成工件，这些工件被打包并放入构建区。然后开发人员可以选择更多选项，为个别的运行时平台生成附加的工件。

图 2. MDD 工具链

回页首

好处

MDD 拥有极大地提高当前主流软件开发实践的潜能。表 2 展示了 MDD 方法的优点。

表 2. MDD 好处

好处	说明
增加了 生产力	通过由模型生成代码和工件的方式，减少了软件开发的成本，同时增加了开发人员的生产力。您必须考虑转换开发（或购买）的成本，但谨慎的计划可以帮助确保成本的整体减少。
可维护性	许多解决方案组件是使用遗留平台技术实现的，但组织不再掌握这方面的技术了。MDD 形成了可维护的架构，在其中可以快速一致地做出变更，可以将组件更有效地移植到新技术上。 高层次的模型与不相关的实现细节无关，这使得处理底层平台技术及其技术架构中的变更更加容易。您可以通过更新转换来变更实现的技术架构。转换被重复地应用于原有的模型，用于生成依据新方法的实现工件。 您可以在做出最终决策之前尝试不同的想法。不好的决策很容易变更。人们经常按照错误的决策继续进行软件项目，而成本过高难于修复。
遗留系统的复用	一贯地在 UML 中为现有的遗留平台建模。如果有许多组件是在同一个遗留平台上实现的，那么您可以开发从组件到 UML 的逆向转换。您可以将组件移植到新的平台上，或者生成包装器（wrapper），通过集成技术，例如 Web 服务，来访问遗留组件。
适应性	由于已经在自动化方面进行了投资，因此添加或修改业务功能就是很简单的了。当添加新的业务功能时，您只需要开发针对该功能的行为。生成实现工件所需的剩余信息可以在转换中获取。
一致性	手动地应用编码实践以及架构决策是容易出错的。MDD 确保一致地生成工件。
可重复性	当在程序或组织层应用时，MDD 尤其强大，来自开发转换的投资回报在每次复用时都有所增加。使用经过试验和测试的转换还增加了开发新功能的可预测性，并且减少了风险，因为架构和技术问题已经解决了。
改进了涉众 的交流	模型省略了与了解系统逻辑行为无关的实现细节。它们更接近于问题领域，减少了涉众所了解的概念，与表示解决方案所用语言之间的语义差异。简化了与业务目标更好地结合的解决方案的交付。
改进了设计 的交流	模型帮助您在设计层上了解系统，引出了对系统的改进的讨论和交流。因为模型是系统定义的一部分，比起文档，它们从不会过时，而且是可靠的。
经验获取	项目或组织经常依靠重复地做出最佳实践决策的重要专家。他们的经验可以在模式和转换中获得，因此，他们不需要直接面对项目的其他成员。而且，有了伴随转换的充足文档，即使当专家离开时，组织的经验仍旧保留在模式和转换中。
模型可以作为 长期的资产	模型是获取组织的 IT 系统的功能的重要资产。高层的模型对最新平台级上的变更具有弹性。它们只在业务需求变更时才发生变更。
推迟 技术决策的能力	早期的应用程序开发针对建模活动。您可以推迟具体技术平台或产品版本的选择，直到有更多的信息可用时再选择。在出现极其长的开发循环（例如，航空交通管制系统）的领域中，这是至关重要的。在开发开始时，目标平台可能还不存在。

总结

本文阐述了，您能够如何利用 MDD，交付改进的来自 IT 的业务价值。像所有的工具或技术一样，MDD 可以很好地应用，或不好地应用。MDD 拥有生成本文中概括的好处的能力，但该方法必须有效地应用。

本文中的信息是基于作者的 MDD 行业应用程序中的经验集的。还是同样的作者，在 IBM 红皮书 Patterns: Applying Model-Driven Development with Rational Software Architect中更详细地介绍了该主题。它包含详细的案例研究，并且介绍了如何利用 IBM Rational Software Architect 来执行 MDD 项目的任务。利用红皮书中的实践将极大地提高 MDD 项目成功的机率。