模型驱动开发 —在RUP与Agile之间找到平衡点
文 / 姚冬本文介绍了集统一软件开发和敏捷开发方法优点于一体的新型软件开发方法——模型驱动开发。当今是一个快速发展的时代,软件的功能更强大,应用更广泛,系统架构更复杂。与此同时,软件开发的难度也越来越大,软件质量难以得到保障。在与业界同行交流的过程中,我感受到更多的不是自信,而是对软件质量的无可奈何与力不从心。为了解决软件开发存在的问题,业界不断涌现出许多开发方法、过程以及模型,试图从方法...
![模型驱动开发——在RUP与Agile之间找到平衡点_1 模型驱动开发——在RUP与Agile之间找到平衡点_1](http://www.programmer.com.cn/wp-content/uploads/2011/05/%E6%A8%A1%E5%9E%8B%E9%A9%B1%E5%8A%A8%E5%BC%80%E5%8F%91%E2%80%94%E2%80%94%E5%9C%A8RUP%E4%B8%8EAgile%E4%B9%8B%E9%97%B4%E6%89%BE%E5%88%B0%E5%B9%B3%E8%A1%A1%E7%82%B9_1.jpg)
- 可工作的软件为核心和评估标准。
- 模型驱动。
- 计划,追踪与调整。
- 持续反馈,重视质量及优化。
- 持续的代码生成。
- 持续的调试与测试。
- 持续集成。
- 测试驱动开发。
- 迭代的开发
模型的分层构架,从不同层面、不同角度对系统进行描述,通过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并不是产品开发的解决之道。以如上,尝作一家之言。然而作者在本文中的尝试,仍然可以为工程界新辟思路,即:在新的理论面前,旧的方法究竟是主动去融合他们,还是守住理论上的严密、谨慎求变呢?这是我对阅读本文的一点建议。 点评人:资深软件工程师、技术作家周爱民 (本文选自《程序员》杂志11年05期,更多精彩内容敬请订阅05期杂志) 《程序员》11年05期精彩内容:云计算应用之路! 《程序员》杂志订阅更多推荐
所有评论(0)