本文来自于 Rational Edge：作为迭代开发框架，Rational Unified Process 或称为 RUP，足够灵活地适应多种项目管理方式。随着基于 RUP 的团队开始采用模型驱动体系架构（model-driven architecture，MDA）策略，为成功地采用 MDA，他们需要了解 RUP 中的哪些任务、工件和阶段需要特别关注。

使用模型驱动体系架构（MDA）方法建立解决方案需要改变开发过程。虽然我们的经验是许多当前关于企业软件开发的最佳实践仍旧适用，但是解决开发过程的模型驱动方法要求对这些实践进行一些重要的变更。

在本文（关于 MDA 系列文章的第三部分，也就是最后一个部分）中，我们将探究那些变更以及 MDA 在现代软件开发环境中的应用。在本系列的第一部分中，我们讨论了如何将建模应用到当今的行业中，以及 MDA 与现今系统的相关性。在第二部分中，我们用这种设计并使用 IBM 的 MDA 工具包的观点来检验模型驱动开发的方法。当我们从开发过程的角度来结束本系列文章的时候，我们将分析一个众所周知的开发过程，即 Rational Unified Process 或称为 RUP，并考虑在 MDA 项目上说明并执行过程的方式。

RUP 概述

Rational Unified Process 是当今使用中的实际标准的软件工程过程。¹RUP 的目标是确保能够按时并在预算之内生成能够可预见地满足最终用户需求的高质量软件。RUP 为在开发组织内分配任务和职责提供规程式的方法，并已经应用到许多项目中，这些项目有各种大小和复杂度，开发团队有大有小，且开发时间有延续几周的，也有延续几年的。

图 1 以二维的形式说明 RUP 的整个体系架构。水平轴代表时间并显示了过程生命周期的各个方面。生命周期阶段的管理视图在顶部，迭代的软件工程和项目管理视图在底部。垂直轴代表按照逻辑分组的规程，表示过程的静态方面 —— 如何用过程部件、规程、活动、工作流，工件和任务来描述 RUP。

图 1. 规程、阶段和迭代的 RUP 概念

在基于 RUP 项目的任何时间点，都会有按照多种规程发生的活动。区别不同生命周期阶段的东西不是缺少某些规程，而是不同规程在整个工作流中所做出贡献的相对量。活动的混合会随着项目的重点和优先权的变更而随时变化。例如，在早期的迭代中，您将更多时间花费在需求上，而在晚期的迭代中，您将更多的时间花费在实现上。

RUP 阶段和迭代

从管理观点出发，RUP 软件生命周期包括四个顺序的阶段，每个阶段都以一个主要的里程碑结束。进行评估以确定是否达到阶段的目标。令人满意的评估结果可以使项目向下一个阶段进行。简要地说，RUP 生命周期的阶段是：

• 初始：初始阶段的目标是在所有涉众之间达成关于项目的生命周期目标的协议。具有代表性的是，在项目进行之前必须确定重要的业务和需求风险。对于那些少量增强现有系统的项目来说，初始阶段是简短的，但仍旧着重于确保项目即值得做又可能实现。生命周期目标里程碑是初始阶段的主要出口标准。它估计了项目的基本生存能力。
• 细化：细化阶段的目标是为系统体系架构设定基础，用来为构建阶段的大多数设计和实现工作提供稳定的基础。细化阶段会描绘出一个将必要的业务需求结合了技术体系架构的可执行的系统，并论证所选技术方法的生存能力。该体系架构进化了对最重要的需求（哪些需求对系统的体系架构有很大的影响）的考虑和对风险的评估。生命周期体系架构里程碑为系统的体系架构建立了一个受控的基线，并令项目团队在构构建段进行测量。
• 构建：构建阶段的目标是澄清剩余的需求并完成基于基本体系架构的系统的开发。构建阶段在某种意义上说是一个制造过程，在此阶段要强调对资源的管理和对操作的控制，用来优化成本、进度和质量。在这个意义上说，管理团队经历着一个从初始和细化阶段的知识产权的开发到构建和产品化阶段的可部署产品的开发的变迁。初始的操作能力里程碑确定是否可以将产品部署到用户能够接受的环境中。
• 产品化：产品化阶段的重点是确保软件对最终用户是可用的。产品化阶段可以跨越若干次迭代，该阶段包括为发布而进行的产品测试，以及根据用户反馈做出较小调整。在生命周期的这个阶段，用户的反馈应主要用于对产品进行微调、配置、安装和解决可用性问题，在项目生命周期的更早期就应该解决所有的主要结构问题。产品版本里程碑是一个您需要在此决定项目是否达到目标，及您是否应该开始另一个开发循环的位置。从软件工程和项目管理的观点出发，随着迭代的进行，事情会逐日的发生。阶段由若干迭代组成 —— 依照基本计划和评价标准的不同序列的活动会致使工件的发布（内部或外部的）。生命周期的每个阶段都由一系列迭代组成，迭代的特性根据您所在的生命周期的位置不同而不同。

RUP 和 MDA

目前，RUP 没有提供对如何将软件开发的 MDA 式样整合到整个过程中的具体指导。这不奇怪，RUP 反映当前行业的最佳实践，且只有在领域内很好地确定之后才能编制方法。MDA 是一个新兴的方法，应用到 RUP 项目中重要的 MDA 最佳实践仅到现在才变得可以得到。

然而从我们的经验中可以得来许多重要的方式，我们可以以这些方式用 MDA 项目的最佳实践来增强 RUP。特别是，RUP 的灵魂，即以体系架构为中心的迭代的开发过程，与 MDA 概念保持高度一致，并为在 MDA 方面取得成功提供极好的基础。

然而，存在着一些领域对 MDA 提供额外的适当指导。在此，我们考虑许多重要的关于将 RUP 应用到 MDA 项目中的重要方面。

• MDA 项目所影响的主要阶段是细化阶段。观察细化阶段的活动并简要地描述 MDA 改进是很重要的。
• 架构师是细化阶段的主要角色，需要对其进行额外的考虑。随着“架构师”的专业化，许多 MDA 项目都需要 MDA 架构师角色。从本质上说，该角色规定了具体的 MDA 活动和工件，创建转换等。因此，出自该角色的主要 MDA 工件是映射文档、转换和 UML profile 文件。
• MDA 如与模型驱动自动化一样与模型驱动体系架构有关。这提供了某种关于如何观察 MDA 和 RUP 的指导。有代表性的是，MDA 自动操作 RUP 中的活动。MDA 利用针对支持将许多主要 RUP 活动自动化的额外工作来扩充 RUP 活动，而不是改变它们。
• MDA 的应用涉及许多 RUP 任务，但它们不需要额外的活动。相反地，每个任务中的标准活动将要求加入关于那些活动如何利用所选的具体工具和 MDA 技术来实现自动化的细节。在 RUP 中，我们称这些额外的细节为 RUP Tool 指导。例如，一个进行关于对象的数据映射的团队可能会利用建模工具进行一组 MDA 转换。但在高级别上，他们关于“定义设计类”的工作流会基本上保持不变。
• 更深入的是，对 RUP 的主要变更包含对开发过程的视图的更微秒的改变。MDA 促使架构师和开发人员在比非 MDA 项目中期望的更高的抽象级别上工作。这在构建阶段是最明显的，在此阶段，MDA 的代码自动化方面较大地改变了实现工作的重点。开发人员能够在对 MDA 转换进行输入时继续进行更抽象的分析并设计模型。他们发现他们更少地处理实际的实现模型和源代码，而更多地进行针对解决方案的适当的着重于业务的工作流的设计。会有更少的开发人员实现模型到代码的转换。
• MDA 转换常常形成于预先建立的解决方案框架（也称为“参考体系架构”或“应用程序框架”）周围。MDA 转换用具体领域的业务逻辑扩充这些框架。这种将 MDA 和解决方案框架结合的方法具有很大的意义，因为完整的 MDA 方法是作为自动化一组可重复技术和资产的中心。然而，它更进一步地使开发过程更着重于重用、管理资产和增加了的解决方案的交付。

使用 MDA 定制解决方案框架

当今的企业软件系统很少是（如果有的话）在集成开发环境（IDE）中从零开始，一行行地被开发出来的。相反，它们是通过用具体领域的业务逻辑来扩展现有解决方案框架，通过连接（并利用）来自不同源头的信息，并通过设计丰富环境的用户显示和迭代服务创建而成的。因此，随后的开发方法不是典型的“瀑布”方案，在瀑布方案中，收集需求之后进行分析和设计，并进行系统的实现。相反，此种开发方法是连续地扩展并细化现有的部分解决方案，通过一组迭代向解决方案中添加值来达到所期望的目标。

这些形成了新系统核心的部分解决方案可能出自以下几个来源之一：

1. 一组现有的应用程序。主要的途径是拿到一个现有的解决方案并按照业务需求的指示以有效的方式进行扩展。因此，大量设计工作会涉及对那些现有应用程序如何构建，以及在不损害现有应用程序质量的情况下将有意义的扩展添加到何处的理解。在多数情况下，原有的应用程序并不是以重用为目的而设计的，这一事实使得过程变得复杂。
2. 组织所使用的专有应用程序框架。在建立了许多种特殊领域内的相似解决方案之后，一些组织就萃取出核心的应用程序功能作为可重用的专有服务在未来的解决方案中使用。这些服务帮助提高共享公共特性的一系列系统的生产率，并增加未来系统开发的可预测性。举个例子 Accenture 的 General Reusable Netcentric Delivery Solution (GRNDS) 框架²。
3. 已获得的应用程序框架，不管是开源的还是商业的。识别一致的体系架构模式（用于设计某些种类的应用程序）已经使得许多技术帮助组织创建符合这些模式的解决方案。结果的应用程序框架可以用作商业产品，也可以用到开源团体中，且可作为独立框架，或与工具绑定来帮助创建、管理及扩展那些框架。例子包括用来创建某些种类的 n 层 J2EE 解决方案的 Struts 及 JSF 框架。
4. 一组对封装的应用程序的扩展和定制。许多组织从封装的应用程序的供应商那里得到了对于关键业务过程的综合解决方案。然而，组织需要使那些解决方案满足他们的需要。所以，封装的应用程序的供应商 1) 构造他们的解决方案以支持不同种类的扩展和定制，2) 提供定义明确的 API 以访问封装的应用程序的内部，或者 3) 用详细设计文档、扩展实例和具体包装的工具扩充封装的应用程序。

倘若这些都是可能的，许多 IT 项目管理人所面对的主要任务是生成对领域的清晰理解，在独立于平台的领域模型（其支持各种类型的分析以确保正确性和一致性）中表达那种理解，并且将那种领域模型映射到一个具体平台上，通过扩展解决方案框架进行实现。模型到模型的转换帮助细化领域，而模型到代码的转换将领域模型映射到具体的解决方案框架上。

在模型到代码的转换中，解决方案框架起到了关键作用，因为它约束并指导那些类型的有意义的转换。例如，如果您正在使用基于 Struts 的应用程序框架，那么正在创建的应用程序就具有容易理解的结构，包括可以实现业务逻辑的众所周知的扩展点。您可以根据该知识创建一组转换。甚至，您可以创建向导驱动的工具来将那些用于包含适当类型信息的领域模型的转换的创建自动化。这就是方法，例如，以这种方法，工具（如 IBM Rational Application Developer）使用聚焦领域的可视化设计工具来自动生成基于 Struts 或 Java ServerFaces（JSF）的应用程序框架的代码。更一般的是，通过将解决方案框架作为系统的基础，撰写模型到代码的转换工作就特别简单了，并且我们获得了结果解决方案的更大的效率、可预测性、重复性和易管理性。

总之，我们再次重申，创建软件很少从零开始，并且模型转换（到另一个模型或代码）可以帮助利用现有的解决方案框架。随着这种建立在现有软件上的方法不断提升，通过帮助我们将扩展并定制那些框架的方法自动化来提升 MDA 的作用和价值。一些人将这种“定制自动化”视为创建不断复杂的系统的唯一可行的选择，并利用我们部署的组件和技术来回应施加给我们的约束。

总结及未来方向
软件和系统开发的模型驱动方法已经使用了一段时间了。最近，关注的焦点集中在如何增大基于 OMG 的 MDA 方法的模型驱动技术的自动化。MDA 技术可以使组织为模型到模型和模型到代码的转换构建自定义自动化。利用这些转换，技术专家可以在大型开发团队中分享他们的专家经验。特别地，MDA 提供许多优于其他方法的益处：

• 通过促使将大部分开发人员与他们不需要考虑的技术细节进行分离来执行他们所设计的满足业务需求的企业解决方案的任务来增长开发的生产率。更多时间花在他们手头的工作上：实现系统的业务功能。
• MDA 通过支持已知的行为模式的复用来提高质量，建立在现有的体系架构设计之上，并更有效地利用专家经验。自动化的使用也促进一致性并改进系统设计和实现的质量，特别是解决方案在维护和升级过程的演进中。
• MDA 的可重复的实践集是适合当今迭代开的发需求的，因为 MDA 提高了开发过程和要交付的解决方案本身的可预见性。自动化的使用加快了开发，特别是当开发人员的许多任务是重复且麻烦的时候。

在本系列文章中，我们已经探究了实现基于我们通常所使用的建模技术的 MDA 方法的许多实际的方面，以及对具体的 MDA Toolkit for IBM Rational XDE for Java 的设计和使用。这些经验表明，虽然传统的设计和实现实践与 MDA 项目有关，但是仍旧存在额外的需求需要满足以确保方法是最佳应用的。我们已经描述了许多这样的需求并用实际例子进行了说明。

在第 2 部分中，我们将我们的重要发现分为对 MDA 实际应用的 12 个经验。然而，这些经验不是具体针对一组专一的技术。它们还可以应用于其他的 IBM Rational 工具中。根据我们对现有技术和实践的经验，包括那些在此叙述的，来自 IBM Rational 的最新一组解决方案通过提供我们认为必要的功能来支持 MDA 开发项目。因此，IBM Rational 工具为所有类型的自动化提供了一组丰富的功能，包括预定义的转换和用于定制转换的工具。³支持 MDA 的最新实例出现在 IBM Rational Software Architect 产品中。这是一个大范围的工作平台，它可以用来设计并构建支持企业系统的分析、设计和实现的各个方面的服务，包括复杂模型的编制及支持 UML 可视化建模的管理功能。具体到 MDA 项目，IBM Rational Software Architect 产品含有一个灵活的定制模式编写环境，并支持以许多方式编制模型到模型和模型到代码的转换（根据预定义式样和设计目的）：

• 普通插件（使用 Eclipse 插件开发环境）
• Pluglet（小型的，简单的自动安装助手，可以进行快速的一次性自动作业）
• 转换（用来构造大型复杂的转换的基于规则的框架）

对这些技术的支持是一组帮助组织采用模型驱动方法的最佳实践。与 IBM Rational Software Architect 整合到一起的产品利用基于 RUP 的技术来指导具体环境的开发过程。此外，可以用具体项目的额外实践和来自在线资源（如 IBM developerWorks）的可重用资产来扩充此指导。⁴

致谢
本文中提到的工作已经由许多人加以贯彻，并且我们很高兴对他们的贡献表示感谢。此处讨论的想法反映出 IBM 中一个很大团队（包括 Grady Booch、Gary Cernosek、Jim Conallen、Pete Eeles、Sridhar Iyengar、Simon Johnston、Grant Larsen、Martin Nally、Jim Rumbaugh 和 Bran Selic）的思想。我们还要感谢 Mike Perrow 对本文进行有帮助地审阅。

参考资料

您可以参阅本文在 developerWorks 全球站点上的 英文原文。

[1] J. Rumbaugh，G. Booch，I. Jacobsen，“The Unified Modeling Language Reference Manual，”Second Edition，Addison-Wesley，2004。

[2] P. Kruchten，“The Rational Unified Process: An Introduction，”Addison-Wesley，1998。

[3] P. Kroll and P. Kruchten，“The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP，”Addison-Wesley，2004。

[4] Evans Data Corp.，“North American Development Survey: Volume 1, "Response to question on "Use of UML in Application Design，”Fall 2003。

[5] Codagen，www.codagen.com。

[6] ArcStyler，www.arcstyler.com。

[7] AndroMDA，www.andromda.org。

[8] openMDX，www.openmdx.org。

注释

¹例如参见 P. Kruchten，“The Rational Unified Process: An Introduction，” Addison-Wesley，1998。

²参见 http://www.accenture.com/xd/xd.asp?it=enweb&xd=services%5Ctechnical%5Ccapabilities%5Cgrnds.xml

³要了解更多细节，请参见 http://www.ibm.com/rational/mda。

⁴要了解更多细节，请参见 http://www.ibm.com/developerworks/cn/rational。