模型驱动开发 —在RUP与Agile之间找到平衡点

　　文 / 姚冬

　　本文介绍了集统一软件开发和敏捷开发方法优点于一体的新型软件开发方法——模型驱动开发。

　　当今是一个快速发展的时代，软件的功能更强大，应用更广泛，系统架构更复杂。与此同时，软件开发的难度也越来越大，软件质量难以得到保障。在与业界同行交流的过程中，我感受到更多的不是自信，而是对软件质量的无可奈何与力不从心。为了解决软件开发存在的问题，业界不断涌现出许多开发方法、过程以及模型，试图从方法论、工程学等角度对软件开发过程进行改进和管理。其中最为知名的，要数RUP（Rational Unified Process，统一软件开发过程）和近十年涌现的各种Agile（敏捷）开发方法了。但从实际效果来看，似乎都没有达到预期的目的。 

　　本文试图以模型驱动开发（MDD）为契合点，在RUP的坚实与Agile的灵动之间找到一种平衡。

　　模型驱动开发概述

　　模型驱动开发就是以“模型”为核心的软件开发过程，业界存在许多特定领域的建模语言（如DoDAF、AUTOSAR等）。但是以UML最为通用、规范和科学化，成为业界建模事实上的标准。

　　模型驱动开发专注于业务的建模和抽象，而不是具体的语言和算法。这种软件开发方法使开发人员把更多精力放在产品的需求分析和功能划分上，而不是纠缠于软件的实现细节。模型以图形化的方式来表述所研究的系统、过程、事物或概念，而图形化的方式更符合人脑的思维方式。

　　用文字去表述的概念，例如软件需求，很容易造成误解。相比较人类的语言文字，模型在表述时更加准确，尤其是标准化的建模语言，例如UML。

　　模型驱动的开发方法使软件实现和模型设计完美地统一起来。软件发展的模型驱动方法不是一种全新的方法，随着UML2.0（目前最新版本是2.3）及相关工具的推出，其支持性技术越来越成熟，也愈加受到重视。

　　模型驱动开发的成熟，不仅体现在效率方面，更体现在可测量性方面。这种能力是与方法及工具密不可分的。UML2.0版本在语言定义精确程度有了相当的提高，是模型驱动开发的必要条件。UML2.0从通信界代码生成技术最成功的SDL语言汲取了大量语法语义，使得代码完全自动生成成为可能。自动化意味着模型转换时的不明确和不精密的消除，同时能够保持良好的一致性，使由模型直接生成最终代码成为切实可行的方案，也为最终生成代码的质量提供了保障。同时对特定领域的改进和支持也使得UML能够更好地适应各种应用需要，例如嵌入式领域。

　　从图1可以看出，软件开发的整个过程都是围绕着模型与需求展开的，这里有三个驱动力。

　　需求驱动的开发：以需求为核心，需求是关键，是第一驱动力。一切任务都来源于需求，需求是定义开发范围，验证开发结果的唯一标准。

　　模型驱动的开发：建模活动贯穿始终，模型是我们工作的方式，通过模型去描述需求和设计系统，进行具体的实现，甚至通过模型进行测试以验证我们的设计和实现。测试驱动的开发：测试驱动用来验证各阶段任务是否正确合理，保障各阶段始终保持一
致，测试过程并不是只存在于开发的后期，而是分布于开发过程的每一个阶段。

　　可以说，需求、模型、测试，三者相互关联，贯穿开发生命周期的各个阶段，有机地推动开发过程向前发展。

　　模型驱动的开发过程，也是迭代的开发过程。在需求分析、系统设计阶段，我们可以随时进行验证和迭代。在软件具体的开发阶段，我们按不同的粒度，进行多次迭代，使一个周期就是从设计到开发再到测试的过程。

　　模型驱动开发与RUP、Agile

　　在模型驱动开发的实践中，已经总结出了一些需要遵循的基本原则，很多原则都与RUP以及Agile的思路一致，从中我们也可以看到，模型驱动开发与RUP和Agile的关联。

• 可工作的软件为核心和评估标准。

• 模型驱动。

• 计划，追踪与调整。

• 持续反馈，重视质量及优化。

• 持续的代码生成。

• 持续的调试与测试。

• 持续集成。

• 测试驱动开发。

　　模型的天然特性结合相关工具的支持，既可以借助RUP完整定义的流程，又可以有效地实施敏捷开发的最佳实践。通过模型建模，快速地构建系统框架，建立起快速原型，并借助模型的仿真和执行，来模拟目标系统的运行行为。这种方式可以尽早将软件系统原型与客户进行沟通和呈现，更形象化地与客户进行交流，快速捕获客户的需求和反馈，进而指导下一步开发和下一个原型的产生。

　　这使得“以更低的成本交付高质量系统”成为事实上的可能。

　　模型驱动与RUP的关联

　　UML是模型驱动开发中最常见的语言，它本身就与RUP一脉相传，因此模型驱动开发与RUP关联紧密。RUP强调的软件开发过程，在MDD模型驱动开发中同样适用，而且会遵循得更加有效。

• 迭代的开发

　　模型的分层构架，从不同层面、不同角度对系统进行描述，通过UML对系统良好的描述和内建的关联，使迭代开发成为必然。借助工具的仿真和执行，我们可以在不同阶段对模型设计加以验证，而每一次的迭代，都可以由模型直接生成可运行的原型。图2是一个从分析到开发再到测试的以模型为中心的连贯的迭代过程，它关注持续集成，同时测试驱动的理念贯穿始终。

• 需求管理

　　需求同样可以进行建模，并且能够在工具中管理起来，进行需求的关联分析、覆盖度分析、变更影响评估、需求的回溯、需求风险分析，从而使得需求管理变得容易，实现从软件开发的根源把控质量。

• 基于构件的体系结构

　　工具支持由模型生成不同架构的目标代码，模型又可以支持不同的设计模式，甚至有专门针对模型开发的设计模式，有效地保障了生成代码的质量，并且良好地支持模型的可重用性。

• 可视化软件建模

　　在这方面，RUP与模型驱动开发是一致的。不同的是，MDD工具的出现，使得可视化建模变得更简单、更合理，而且可以支持整个生命周期的开发建模，从需求捕获，到系统设计开发、模型测试、代码生成，都可以围绕建模展开。

• 验证软件质量

　　软件质量通常由测试来保障，而传统软件开发之所以测试不利，一个原因是不能更早地介入，无法在早期阶段针对需求分析和设计进行测试验证。而借助工具的支持，模型驱动开发得以将模型仿真，支持设计的验证，生成快速原型，及时有效地与客户交流。

• 控制软件变更

　　软件变更的控制，一方面需要评估变更造成的影响，这一点通过模型之间建立起来的关联可以轻易达到；另一方面需要测试验证变更涉及模块，保证修改在准确实现变更的同时，不影响其他功能模块。这可以通过工具支持的模型回归测试等手段实现。

　　MDD对敏捷开发的借鉴

　　模型驱动开发在很多方面与敏捷开发的思想非常契合，而模型自身的特点，也使得它在实践敏捷开发多种实践时来得更容易、更自然、效果更好。

• 持续迭代，持续反馈

　　使用短周期的迭代可以加速开发过程，例如Scrum的一次Sprint。基于开发出的快速原型，客户可以更好地理解自己的需求，开发者也能了解到如何才能更好地满足客户的需求。模型的可执行性决定了模型驱动的开发可以快速地生成可执行的原型，从而使得持续迭代成为简单的事情，与客户的持续反馈也变得更加容易沟通和理解。

　　通常一次迭代会由一系列任务组成，而每一个任务的进展都可以看作是一次更短周期的迭代过程，如图3所示。需要强调的是，其中的分析设计与实现以及测试和执行都是围绕模型展开的。

• 可工作的软件

　　模型可执行性决定了设计、开发出来的软件是天生可执行起来的，而是否正确工作则完全可以通过模型的仿真进行验证，模型驱动开发的原则之一就是以可工作的软件作为核心和评估标准。

• 响应变化

　　我们从不同层面不同角度对系统进行建模，建立起模型之间的关联，在系统发生变更时，可以便捷地发现变更所造成的影响，同时通过模型的仿真与验证快速验证我们的改动，从而快速地响应变化。

• 测试驱动

　　模型驱动的测试是部署在整个软件开发生命周期的，从系统需求的捕获阶段、系统设计到各个测试阶段，都可以通过执行模型来进行验证。

• 持续集成、持续构建、持续测试

　　通过工具软件，我们可以很方便地进行持续集成、持续构建，而模型既可作为开发建模的输出，又可作为测试用例的输入来源，测试的进行也同样可以依赖于工具自动进行。

• 团队协作

　　整个开发团队是以需求为核心、以模型为活动方式展开的。UML模型可以适应不同规模、不同复杂程度的系统，从而使得围绕在模型驱动周围的开发团队也同样可以适应不同的团队规模。所有开发活动都可以围绕着模型构架进行，模型构架的层次性使开发团队的分工和合作变得简单。

　　结束语

　　模型驱动开发是一种新的软件开发方法，它结合了RUP和Agile开发的优点，借助强有力的工具支持，可以良好地实施多种最佳实践。

　　需要强调的是，模型驱动开发不是万能良药，企业和开发团队在实施的过程中，应当根据自身情况以及项目需要，进行量体裁衣。而且由于是基于模型的开发，使我们在学习和适应模型上需要时间的投入，在实践的初期很可能效率上反而不如原有模式。这时就需要一点点坚持和投入的决心。

　　完全有理由相信，模型驱动开发将是推动软件开发向前迈进的强有力支撑。也希望越来越多的行业人员能够了解、熟悉并对其加以实施推广，模型驱动开发的道路将越走越广！

　　作者简介：姚冬，北京邮电大学软件工程在职研究生。现就职于某知名跨国企业，关注复杂系统开发，以及软件过程改进等方面的研究。拥有12年的系统软件开发和软件工程实践经历。

　　参考文献
　　《统一软件开发过程》（美）Ivar Jacobson, Grady Booch, James Rumbaugh等著，周伯生, 马学民, 樊东平等译, 机械工业出版社 ISBN 7-111-07572-2/TP.1200

　　文章点评：

　　首先，我并不认为模型驱动开发已经成为流行的开发模式，这一构想在方法学上仍有很多难于实施的地方。其次， 我并不认为建模语言比编程语言表述更准确， 编程语言有其严密而精确的正确性论证， 但即使如此，一个再高明的开发者也会写出不可理喻的错误代码，这对建模语言所谓的“精确性”是同样的挑战。最后，仅从本文的探索来说，我认为作者的某些不严谨的陈述仍显出矛盾的核心，即：项目全程建模的结果与工程实施的目标分别是模型与产品，二者仍然有相当远的距离。这即是说，即使模型与代码之间的转换成本为零（当然，目前这仍然是梦想），那么转换的结果仍然不是产品。进而说，MDD并不是产品开发的解决之道。以如上，尝作一家之言。然而作者在本文中的尝试，仍然可以为工程界新辟思路，即：在新的理论面前，旧的方法究竟是主动去融合他们，还是守住理论上的严密、谨慎求变呢？这是我对阅读本文的一点建议。