CSDN博客

img gigix

尽快去学习RUP——专访Ivar Jacobson

发表于2003/5/3 22:17:00  3981人阅读

《程序员》:

在过去的五年中,您看到软件开发技术领域出现了哪些重要的技术?

Ivar

对于软件开发者,有两件重要的事情。

首先,我们在描述软件设计方面有了一个统一的标准,那就是统一建模语言(UML)。这是通行于整个世界的标准。全世界的软件开发者,不论他们是在美国、加拿大还是澳大利亚,他们都遵循这个标准,都使用同样的语言来交流彼此的思想。

但是,仅仅有标准还是不够的。不同的人使用UML的方式可能相去甚远,有些人用UML得心应手,有些人则事倍功半。你知道,仅有语言是不足以保证工作顺利完成的。因此,我必须提到的第二件重要的成果就是Rational统一过程(RUP)。RUP为软件开发团队指出正确使用UML的方法。世界各地无数的企业用他们的实践经验证明了RUP的价值。

这就是我所认为过去五年中最重要的两项技术:UMLRUP。请注意:语言和过程,它们都不足以使软件企业成功;只有把语言和过程结合起来,让过程指导语言的使用,才能收到良好的效果。

《程序员》:

我注意到,这两项重要的技术(UMLRUP)都与您有着密切的联系,甚至可以说就是您的作品。

Ivar

我的确参与了UML的设计工作。那是在1997年,我和Grady BoochJames Rumbaugh一起开始了UML的设计。但是,UML的思想其实一点都不新鲜,我们借鉴了许多有着多年历史的好点子。例如顺序图,那是我们从上世纪60年代末70年代初就开始使用的;再比如协作图,也是那个年代的产物。正是这些经受了时间检验的好点子,为UML构筑了坚实的基础。

实际上,UML背后的许多“金点子”都是爱立信(核对公司,gigix)在上世纪60年代末70年代初开发的,而我当时正好是爱立信的软件体系架构师。这些好点子当时是用于一个名为SDL的建模语言的。因此,UML的思想很大程度上是源自SDL的。

再说RUP吧。RUP最初的开发是从xxxx(核对公司,gigix)开始的,那正是我的公司。不过你也知道,开发这样一个过程需要很多很多人的共同努力,而我只是RUP最初的设计者而已。

《程序员》:

那么,再谈谈您对未来的展望吧。您认为软件开发技术将会有哪些方面值得关注的发展?

Ivar

呃……我想值得关注的东西还是很多的。如果让我预测的话,我会对下面的四项技术寄予特别的关注。

第一个值得关注的就是基于组件的软件开发(Component-Based DevelopmentCBD)。我想,不但这方面的技术将会有很大的发展,而且还会发展出一个组件的市场,人们可以在上面买卖大量的组件。而且,组件技术将向着各个应用领域深入,而不再仅仅是“中间件”。我们将可以买到用于银行业务的组件、用于航空业务的组件、用于电信业务的组件……这将是一个巨大的进步。

第二项值得关注的技术,则是所谓“全程质量保证”(Quality from the beginninggigix)。也就是说,软件开发过程中将没有一个单独的测试阶段,而是代之以贯彻始终的对质量的关注。不管你做什么,都需要同时保证自己所做的符合质量的要求。不管你是在编写用例、在设计系统架构还是在编码,都必须随时保证工作的质量。现在,我们已经有了一些测试工具。但为了达到全程质量保证的要求,我们还需要更多的测试工具,不但要测试最终产品,而且还要对组件、用例等等都进行测试,以随时保证它们的质量。这一切将成为我们的日常工作,我们的整个编程方式和编程思路都将完全改变。

《程序员》:

这听起来很像XP所提倡的“测试优先(testing first)”,不是吗?

Ivar

没错,测试优先。实际上,我们一直都是这样干的,这并不是什么新鲜的概念。我一直强调:用例就是测试案例(use cases are test casesgigix)。当你指定一个用例时,你也必须同时指定相应的测试案例。

《程序员》:

“用例就是测试案例”。这的确很有道理。好,下面请继续介绍第三项值得关注的技术吧。

Ivar

第三个值得关注的就是智能实体(Intelligent Agentgigix)技术。每个实体(agentgigix)实际上就是一个对象,它可以根据规则数据库的规定而采取一定的行为。并且,这种实体完全是组件化的,而不是以前那种对象实体,这意味着它将具有相当高的独立性和可复用性。智能实体技术将可以对软件开发起到相当大的辅助作用。

第四项重要的趋势则是可执行UMLExecutable UMLgigix)。实际上,在XDE这个工具中,你已经可以看到可执行UML的雏形了。你只需在建模环境中创建系统模型,工具就会立刻帮助你生成可执行代码;当然你也可以直接修改代码,而你对代码的修改也会立刻体现在建模环境中。而且,XDE非常灵活。你可以选择XDE+J2EE的方案,也可以选择XDE+.NET的方案,完全视项目需要而定。将来,我希望会出现真正意义上的、不依赖任何特定厂商平台的可执行UML——当然,这可能需要很长时间,十年或者二十年。也就是说,很多编程语言的生存都可能受到挑战,可执行UML将取代一大批的编程语言。今后,你只需画下类图,然后指定对象之间的交互,最后再选择运行平台,建模环境就会帮你生成可执行文件了。

《程序员》:

您刚才提到了.NETJ2EE。那么,从面向对象的角度,您会如何评价它们?

Ivar

这是两个平台,两个不同的、彼此竞争的平台,扮演的角色非常相似。它们各有长处,都非常强大,我很难在两者之间做什么比较。

《程序员》:

您现在关注些什么面向对象新技术?

Ivar

刚才说过的智能实体技术应该算一个,那是我非常关注的。另外,就是面向方面的程序设计(Aspect-Oriented ProgrammingAOP)。我现在不能确切地知道它将会发展成什么样子,不过我认为AOP是一项很有前景的技术。这是一种有趣的技术,它将简化软件开发的过程。

现在,当你编写完用例之后,你需要将用例变成系统中的若干个对象。今后,我们也许可以借助AOP直接对用例编程——你明白吗?不是对类编程,而是对用例编程。这将极大地简化软件开发的过程。你知道,从需求到设计的映射是软件开发中的一大难题,而AOP可以很好地解决这个问题。

很可惜,现在我没有太多的时间去仔细研究AOP。不过,我完全相信:我将会去研究它,因为它的确是一项很重要、很有用的新技术。

《程序员》:

在面向对象方面,我倒是在关注另外的两项技术:重构(Refactoring)和按契约设计(Design by Contract)。请问您如何看待它们。

Ivar

先谈谈重构吧。我认为重构其实并不是什么新鲜的东西。“改变软件的内部结构”,这是我们一直都在做的事情。Martin Fowler的贡献在于:他把这项工作归纳总结,并上升到理论的高度。但是,我对重构仍然存有疑虑:尽管我们经常不得不进行重构,但把重构变成日常工作似乎也不大可行。并且,如果你希望提高系统的质量,最好是首先设计一个良好的体系结构,这样在交付最终产品之前根本无须做太多的重构。

至于Design by Contract……我很欣赏它。系统各部分之间通过接口彼此交流、互相操作,因此接口可以说是系统中最重要的部分。从前的面向对象技术教我们如何从需求识别出接口、如何明确指定接口,但是还缺少了一个重要的东西:判断对接口的使用(以及使用后的结果)是否合法。Design by Contract正好弥补了这个缺陷。通过Design by Contract,在编译器的帮助下,我们可以更好地定义、使用接口。

其实Design by Contract的思想很早就已经出现了。但是,是Bertrand Meyer第一个正式地将它阐述出来,并在一种语言(Eiffel语言)中实现它。这是面向对象技术的一个进步。从长期来说,我们一定需要一种方式更详细、更准确地定义接口,这样才能保证组件之间的正常交流。从这个意义上来说,我认为Bertrand Meyer的方向——Design by Contract——是正确的。我们都会沿着他的足迹前进。

我相信,大型厂商(例如微软、IBM,当然还有Rational)都不会对Bertrand Meyer的成就坐视不理。我已经说过了,Design by Contract是正确的方向。所有这些大型厂商都会在这个方向上有所行动。至少我相信,UML会朝这个方向发展。

《程序员》:

哦?是吗?是不是说UML即将加入对Design by Contract的支持了呢?

Ivar

呃……你知道,谁也无法预测未来。毕竟UML现在是由OMG管理的,所以我也无法准确地预测它的发展方向。不过,我想UML正在逐渐向着Design by Contract的方向靠近。在UML今后的版本中,开发者将可以更准确、更细致地操作接口。总而言之,UML的确是离Design by Contract的要求越来越近了。

在面向对象这条路上,我们已经走了三十多年。我们所做的一切,其实就是越来越清楚、细致地定义接口。所以,我认为Bertrand Meyer的方向是正确的,并且敢于预言UML也将向这个方向发展。UML实现Design by Contract的方式可能会和Bertrand Meyer的方式有所不同,但一定会使得整个开发过程——用例、接口定义、建模——更科学、更简单。

《程序员》:

那么,对于设计模式(Design Pattern)呢?这是我特别感兴趣的一个领域。

Ivar

哦,设计模式当然是好东西啦,每个优秀的设计中都会有设计模式的身影出现。它们是前人设计经验的总结。1972年的时候,我在爱立信写过一篇文章,主题就是关于将电信系统中重复出现的、相似的问题(以及它们的解决方案)分类,这就已经有点模式的味道了。所以说,模式也是我们一直都在使用的东西。

但是,如果没有工具的支持,模式的实现是一件相当麻烦的事情。这也正是开发者们常常在使用模式时遭受挫折的原因之一。所以,你需要一个方便的工具。软件开发的过程应该是这样:你遇到一个问题,这个问题正好与某个模式的“问题”相符,因此你说“好吧,让我们用这个模式来解决它”,然后点一个按钮,这个模式的框架就搭建好了,你只需再针对问题的细节做一些调整就行了。有了这样的方便程度,开发者们才会很高兴地去使用设计模式。

据我所知,现在已经有了这样的模式辅助工具,XDE就是一个。你用过吗?没有?噢,那是个非常有趣的工具。它支持许多常见的设计模式和体系结构模式(Architecture Pattern),用起来很方便。我想,我们的ROSE也会向着这个方向发展,会加入对模式的支持,这对于ROSE这样的建模工具是非常重要的。

《程序员》:

这正好跟我最近一段时间在考虑的问题有关:模式的书面描述与其程序实现之间有着不小的距离。我们经常遇到这样的情况:一个模式在书上看起来很好,一旦实现起来就困难重重。那么,您所提到的这种辅助工具(例如XDE)有助于缩短这个距离吗?

Ivar

啊,是的。有了工具的帮助,模式的描述和实现将融合得天衣无缝。也正是因为这个原因,XDE受到了很多模式社群的研究人员和开发者的青睐。它的确是一个很好的工具,既然你对模式有兴趣,那么应该去关注一下这个工具。

你的思考是有道理的。实际上,如果没有工具的帮助,使用模式是一件相当困难的事情。开发者必须先去读很多书,了解模式的思想背景;然后再深入研究某个具体模式,充分理解这个模式之后才能应用它。显然,这对于一般的开发者来说太困难也太费劲了。所以,我认为:如果模式要得到更加广泛的认可和应用,必须有很好的辅助工具,这是非常重要的。

不过,现在的XDE还只能支持一些常见的模式。我想,需要不同领域的开发者来归纳、总结各自领域的模式语言,然后开发自己的工具来支持这些模式,这样模式才能真正起到应有的作用。

《程序员》:

对于使用RUP的项目和人员,您有些什么建议?

Ivar

我一直都认为:每个程序员、每个开发者、每个与软件开发有关的人员都应该至少对UMLRUP有一定的了解。为什么这样说?因为UML是软件开发的通用语言,而RUP则蕴涵着许多软件开发者应该知道的知识。

假如一个初学者想要进入软件开发这个行业,他应该从哪里入手?我会建议他从RUP开始。从RUP中,他可以学到管理的基本常识、分析设计、体系结构设计、测试、在.NET或者J2EE或者C++或者别的什么平台上的实现,他还可以学到进度管理、版本控制、分布式运算等等。总之,虽然不是所有方面的知识,但你的确可以从RUP中学到很多方面的知识,足以应付大多数的情况了。

并且,RUP是一个稳固的基础。在这个基础之上,你可以开发各种各样的软件系统。使用RUP,你可以开发小型项目,也可以开发像国防系统、大型银行系统这样庞大的项目。如果你的项目比较小,你可以采用RUP的“轻量级”版本;小范围的应用成功之后,再逐步深入并扩大范围。在我看来,没有什么项目是不适合采用RUP的。只要编程,就可以使用RUP

所以,我建议大家都去学RUP。在西方国家,如果你去应聘软件开发者职位,招聘者就会问你:“你懂RUP吗?”如果你说“不懂”,他就会让你回家去学RUP,然后再来应聘。中国大概还不这样吧?不过我相信很快中国的开发者和经理们也会看到RUP的重要性的。

《程序员》:

那么XPeXtreme Programming,极限编程)呢?您认为XPRUP是对立的吗?

Ivar

XP很好,很成功。我知道Kent Beck非常推崇XP,并且的确有很多小型项目采用XP获得了成功。但,我并不认为XPRUP是对立的。我认为XP其实就是小型的RUP。如果你要开发一个小型项目,只有很少的团队成员,并且要在比较短的时间内完成,你就可以并且应该使用这种轻量级的方法。这种方法更加灵活,迭代周期更短,但这并不意味着它与RUP相对立。实际上,随着项目的增大,团队的成长,XP也可以转变成为RUP。两者的确有差异,但这种差异也是因为不同项目的需要而造成的。XPRUP之间有什么截然不同的地方吗?我看不出来。

XP最引人注目的一点可能是:我们通常认为建模是非常重要的,但XP却不这么认为。当我们认为应该建模的时候,XPer们就已经开始编码了。当然,这是符合XP的要求的,的确也获得了很大的成功。不过,这也把XP限制在小型项目的范围内。你知道,如果在大型项目中这么干,系统很快就会陷入混乱的。当然,这并不是XP的错,因为XP本来就只是用于小型项目的。

《程序员》:

我的一个朋友告诉我:很多企业在一开始的时候走RUP的路,但在项目进行到一半的时候又回到了原来那种结构化的路上去了。您如何看待这个问题?如何能让RUP不在实施的过程中变味?

Ivar

没错,的确经常有这种事情发生。不过,说实话,这不是一个技术性问题,也不是从技术角度能够解决的。

很多企业都会有这样的想法:RUP(或者组件技术,反正是某种新技术吧)是个好东西,我们来试试吧。你应该知道吧?在1997年的时候,根本没有任何人对组件技术感兴趣,一个人都没有。现在呢?每家公司都在宣称自己的产品是基于组件的。可是,这些公司真的都有必要转向这些新技术吗?呵呵,很多时候他们采用新技术时都是抱着这种“试一试”的想法。

不,千万不要这样想。在采用某项新技术之前,你一定得有懂这项技术的人。不管是新雇一个人还是让以前的员工去培训,总之这是需要开销的。另外,你还需要购买新工具,需要做其他的准备工作,这些都是要花钱的。如果你半途而废,那么为新技术而投入的成本就全都泡汤了。不,你不能去“试”一种新技术。如果要做,就一定要做到底。如果要实施RUP,那就把全公司上下都统一起来,一定要坚持到底——当然,这也就意味着在选择技术之前需要更加谨慎。

我们经常看到一些公司采用RUP之后失败了。但是,我们不能简单地把失败归结于RUP。如果我们探究这些公司失败的深层原因,往往会发现:是管理上的失败导致了技术上的失败。尤其是,如果管理者对新技术抱一种“试一试”的心态,那么新技术多半都是要失败的。

《程序员》:

今天的最后一个问题:如果只能对中国的开发者说一句话,你想说什么?

Ivar

只有一句话吗?那么,凭我的经验,我从心底里真诚地告诉中国的开发者:尽快去学习RUP。因为这将是大势所趋。从RUP中,你将可以学到很多很多非常有用的知识。在晚上、在周末、在等女朋友的时候、在喝茶的时候,总之,抽出一切时间来学习RUP。这样的努力必将得到回报。

这就是我能给中国的朋友们最好的建议。

阅读全文
0 0

相关文章推荐

img
取 消
img