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

《程序员》：

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

Ivar：

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

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

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

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

《程序员》：

我注意到，这两项重要的技术（UML和RUP）都与您有着密切的联系，甚至可以说就是您的作品。

Ivar：

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

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

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

《程序员》：

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

Ivar：

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

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

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

《程序员》：

这听起来很像XP所提倡的“测试优先（testing first）”，不是吗？

Ivar：

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

《程序员》：

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

Ivar：

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

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

《程序员》：

您刚才提到了.NET和J2EE。那么，从面向对象的角度，您会如何评价它们？

Ivar：

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

《程序员》：

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

Ivar：

刚才说过的智能实体技术应该算一个，那是我非常关注的。另外，就是面向方面的程序设计（Aspect-Oriented Programming，AOP）。我现在不能确切地知道它将会发展成什么样子，不过我认为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：

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

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

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

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

《程序员》：

那么XP（eXtreme Programming，极限编程）呢？您认为XP和RUP是对立的吗？

Ivar：

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

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

《程序员》：

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

Ivar：

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

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

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

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

《程序员》：

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

Ivar：

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

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