IBM®
跳转到主要内容
    中国 [选择]    使用条款
 
 
Select a scope:Search for:    
    首页    产品    服务与解决方案     支持与下载    个性化服务    
跳转到主要内容

developerWorks 中国  >  Rational  >

Grady Booch 预言软件开发的未来

Grady Booch 谈软件开发的过去、现在和未来(提示:软件开发这仍然是个难题)

developerWorks
文档选项

未显示需要 JavaScript 的文档选项


级别: 初级

Grady Booch, 首席科学家

2004 年 2 月 01 日

Grady Booch把他的时间花在思考如何改进软件开发上。为此,他一直在思考预见了当前的趋势(UML、面向方面编程、Web服务,等等)将如何演化到未来的开发环境中。最重要的是,Grady认为,我们能够通过不断地提升抽象级别来解决复杂问题。在本次developerWorks总编辑Michael O'Connell对Grady的独家访谈中,看看Grady是如何看待这些问题以及其他问题的。

J2EE(Java 2 Platform,Enterprise Edition)将击败 Microsoft 的 .NET 吗?Web 服务结合 XML 模式将提升抽象级别吗?Rational Software 首席科学家Grady Booch 正在思考这些有关软件开发未来的问题。如果您认为这样一个人具有洞察开发过程将如何跟着时代演化的能力,您是正确的。



由于 IBM 收购了 Rational Software,Grady 现在任职于 IBM ,他是4月9-12日在新奥尔良 Morial 会议中心召开的 IBM developerWorks Live! 大会的专题演讲者之一。我们请求他和我们共享该演讲的预演。Grady就是Grady,他在这次 developerWorks 的访谈中让我们收获颇丰。

developerWorks:让我们首先了解一下您的技术背景。

Booch:当我12岁的时候,在德克萨斯州阿玛里洛市构造了我自己的第一台计算机。当时我对硬件非常感兴趣,因为那时还不能真正地进行编程。没有计算机课程或者书籍,而且作为一个12岁的男孩,我无法向伙伴们请求帮助。于是,我经常去当地的IBM销售部门,直至一位销售人员开始同情我。在我们闲聊一阵之后,他递给我一本 Fortran(手册)。我肯定他在给我那本手册时想道"我将再也听不到这个孩子的消息了"。但是一周后我返回了,说道"这确实很不错。我已经阅读了整本手册,并且编写了一个小程序,但。在哪里可以找到计算机呢?"让我高兴的是,那位朋友为我安排了周末和深夜在IBM 1130上的编程时间。那就是我的最初编程经历,冶匦敫行荒俏徊恢?IBM 销售人员,他开启了我的职业生涯。谢谢您,IBM。

dW: 现在 IBM 正在收获红利?

Booch:是的。记住这个教训:不管你身在IBM中的何处,请小心,因为您的行动可能产生您远无法想象的后果。

dW:我猜测,您早期对硬件的关注与您对建模感兴趣有关?

Booch:是的。事实上,我的硕士学位就是从加州大学圣﹒巴巴拉分校硬件专业获得的。我从空军军官学校获得了良好的软件工程学位,但是后来我认为自己需要对软件运行所在的硬件环境具备更深厚的基础,因此我的硕士课程主要是关于计算机体系结构的。

我在自己的一生中仅从事过三个工作:Baskin Robbins、空军和 Rational Software。作为Rational 的首席科学家,我是公司指定的完全自由人员,因为我要考虑未来三到五年的事。

因而,我工作在这样一个前提下,即软件开发过去是、现在是、将来仍然是一个非常艰苦的职业,没有哪一件事情能够改变开发软件的这种困难状况。放眼未来,映入眼帘的几件事情似乎会根本性地改变开发人员的体验--从当今我们所看到的基础上的状态变化完全不同于我们今天所看到的。从硬件的一面,我看到了网格计算的出现升起,因为它带来了纯粹的经济意义,我很欣喜地看到技术和标准适得其所。

dW:从这个角度出发,您能描述一下将会改进应用程序开发性能能力、可靠性、可伸缩性,并且简化开发过程的最重要的新技术或者新工具吗?

Booch:我看到了诸如J2(Java 2平台)以及Microsoft的.NET等平台的成熟。虽然两个平台都会继续主宰中间件市场,但是它们只能逐渐地成熟。例如,人们将对其中任一个平台付出如此大的投资,以致他们无法承担这些平台发生根本变化。因此,我们将会看到一定程度的稳定--这对整个行业来讲是有利的,因为技术剧变会给公司带来极大压力和矛盾。

此外,如果让我预测未来,我预见面向方面编程(aspect oriented programming)的崛起。今天的大型软件系统和高性价比的系统包括数万个移动部分,因此我们倾向于从来不关闭它们。所以,面对随之而来的挑战就是如何在不关闭系统的前提下对系统进行改进变这样的系统而又不关闭它们,使之通过包容众多的利益相关人的解决方案来提供附加价值。同时还要利用众多风险投资者来增加价值,用以作为解决方案的一部分。利益相关人风险投资者可以是包括图形艺术家、网络人员、安全人员和业务专家。在这样的情况下,您不能把这个问题看成是传统的编程问题。事实上,您不再构建一个程序,而是在不断对 -- 程序是某个大型系统的可变部件,那些部件彼此相互关联的部件进行改变连接。在这种环境中,通过使用方面(aspect),您将基于横切(cross-cut)那些部分的线程来构建系统,让领域专家从那些特定视角"表达一个方面(aspect)"。我认为在接下来的两年左右,面向方面编程(aspect-oriented programming,AOP)将在测试、部署和业务规则方面取得成果。

dW: 您能详细说明一下"表达一个方面"的意义吗?

Booch:当然可以。让我举一个低级别的例子--日志记录,然后再举一个高级别的例子--安全。WebSphere存在一个日志记录问题,因为每个WebSphere部分都包括自己的日志记录机制。如果我们能够申明断言一种日志记录策略为"您应该这样记录日志",那么开发人员就会受益。如果那样的话,您只需表达一个日志记录方面(aspect),表达该策略,然后使用工具将日志记录方面(aspect)织入系统的其余部分。

在较高的级别上,考虑申明断言一个横切系统的安全策略。对于如今存在的系统,您必须触及如此多离散的部分,才能创建严密的安全策略。事实上,大多数单独的开发人员无法构建并发的、安全的、分布式的系统--他们根本不具备那样的技能集合。而且,单独的开发人员在局部所做的事情,可能产生极大的全局影响。因此,围绕一个方面(aspect)加强安全性,您就可以是在对问题进行划分,从而在实施中使得开发人员不必考虑担心这种安全问题。

作为另一个预言,我认为Java就像我们知道的那样,不会成为下一个十年中的主要编程语言。相反,我看到文本的和图形的编程元素正在融合。我认为我们不会出现看到一种纯粹的图形编程语言;相反,我们将看到一些图形和文本相互共存的表示语言。

开发人员体验的另一个重大变化将以协同开发环境为中心。开发环境已经从独立的命令行工具演化为集成开发环境(IDE),在IDE中,开发人员需要的基本工具位于单一的桌面上。但是请注意我使用的最重要的词语"单一的桌面"。

现今的开发是一种团队活动,但是团队不一定处在相同的地点。如何凝聚成员散布四处的团队呢?那就是Web发挥作用的地方:我们可以将Internet用于软件开发本身,而不只是作为软件开发的目标

然而,这个跨越在IDE和协作开发环境的结合过程中尚未发生。协作并不表示某是单个的超级程序个招人喜欢的应用程序(killer app)--它,而是成百上千个小程序的协同工作。作为基础的,如即时消息传送、情景讨论组、工件、知识库、集成配置管理,等等,--这些元素必须交织在一起才能提供协作开发环境。实际上,我认为IDE将通过这些元素逐渐演变为协作开发环境。

dW:说到软件应用程序,为什么字处理程序和电子表格程序都是单一的,而不是廉价的交互式组件的组合?

Booch:您的问题讲的是这些组件本身的经济学。虽然听起来有些奇怪,但是最终用户基本上很憎恨软件:它碍事、花钱,还要阻止他们做想做的事情。但是他们必须使用软件,因为他们的业务需要这些软件。我们通过构建复杂的(但是通过创建简单的错觉来隐藏了软件的复杂性)软件来解决这个矛盾。作为一个独立信息工作者,我不想拆开字处理的这些部分,然后再组合它们。我的桌面上有Microsoft Office套件,这点不假,但是我使用了它的全部功能并对它进行编程吗?否,因为我仅挑选自己需要的部分,然而我的后机器全部吸收了全部这些部分。

我说过,在很大程度上,我们还没有看到软件系统的组件化,因为坦诚地讲,单独的大多的项目都面临尚有如此大的压力,使之就没有时间和经济动力机再返回去,并完成那种组件化。

dW: 您是如何看待敏捷开发的?

Booch:在Rational,我们是敏捷开发的忠实信徒。我特别着迷于与小型开发团队的社会性心态相关的敏捷开发。敏捷开发方法解决了这种社会性心态问题,从而有助于开发团队力量的凝聚。

dW:极限编程(XP)怎么样呢?

Booch:Rational的经验表明,虽然XP提供了一些不错的思想,但它还没有触及一些大型较大的软件的开发问题。目前我们根本没有足够的XP经验,以便将XP扩展到跨越多个办公部门的大型开发团队。

dW:您如何看待Java技术与Microsoft的.NET之间的竞争?

Booch:世界上有两种主要的阵容信仰:Microsoft阵容 和非 Microsoft阵容。今天的市场表明,对于企业系统,您必须要么选择.NET,要么选择J2EEava企业技术。我认为两种平台都会在未来几年继续存在,因为从宏观,虽然从6万5千英尺高的层面上看,它们看起来很相似,只但是在最基本的层面上,它们是不同的。

然而,避开中间件领域不谈,我对与Web服务和XML Schema更感兴趣,因为您可以独立于中间件平台来描述断言系统架构体系结构。话虽这样说,我却没有从Microsoft的Web服务观点中看到可行的经济模型;相反,Web服务将通过为开发人员提升抽象级别来证明自己的强大功能。对普通开发人员的使用来说,事实证明.NET和J2EE都过于复杂了--它们都具有太多纠缠不清的细节。值得赞扬的是,.NET和J2EE都在通过吸收一般惯例共同的经验来提升抽象级别。

dW: 您如何看待现今对程序员可用的各种面向对象(OO)编程模型--COM+、Java技术、.NET Framework、Perl?

Booch:好,这话说来就长了。可用的编程模型多,既是好事又是坏事。因为如此多的编程模型表明了一个充满活力活泼的市场。随着公司构建企业系统不断汲取经验,有些模型将被抛弃。

这些相异的编程模型将会继续存在一段时间,但是随着模式(pattern)运动和设计模式(design pattern)社区的发展,我们最终会终于有了一种描述那些模式的语言。该语言那样将通过提升抽象级别来帮助减少编程模型的数量。

让我们把视野放大一点:回顾和展望软件工程的发展,这个行业已经面临着一直在通过提升抽象级别来处理所带来的复杂性问题。例如,我们从中间件的兴起中就可以看到这点。中间件代表了通过统一编码公共体验共同的经验来实现表示的操作系统之上的抽象级别--这带来了规模经济,从而提供了经济动机。

dW:您是否认为过度提高抽象级别的也存在风险太大?

Booch:是的,如果您爬得过高,就无法控制底层的系统,不过那也不一定就是坏事。如果把抽象级别提升得太高,使得在发生不可理解的事情时难于调试,问题就会随之而来。

dW:人们鼓吹OO编程到现在已经多年了。在OO编程的现实与广告宣传之间,你站在那一边?

Booch:我一般不相信广告宣传。或许我是那种愤世嫉俗的人--世上不存在万能药!不带虚假的。正如前面提到过的,软件开发过去是、现在是、将来也仍然是很艰难的,并且我没有预见到任何事情能改变这一点。就对象而言,其广告宣传声称它会增加重用。是的,它确实如此,不过不是是以我们不曾经期望的方式,因为OO编程语言导致了设计模式的产生。结果,我们在与编程语言不相关的层面上看到了重用,也就是在设计本身这一层面。我们实现了对重用的承诺吗?是的,不过不是我们最初期望的那种方式--对许多技术来说,这都是不变的真理。

dW:因此,您没有看到OO最初的重用意图得以实现,对吗?

Booch:我对OO编程的目标从来就不是复用。相反,对我来说,对象提供了一种处理复杂性的方式。这个问题可以追溯到亚里士多德:您把这个世界视为过程还是对象?在OO兴起运动之前,编程以过程为中心--例如结构化设计方法。然而,系统已经到达了超越其处理能力的复杂性极点。有了对象,我们能够通过提升抽象级别来构建更大的、更复杂的系统--我认为,这才是面向对象编程运动的真正胜利。

dW: 作为总结,您认为UML的下一步是什么?

Booch:开发人员不会在UML 2.0中看到明显的变化。2.0版中的许多变化将帮助把工具开发商人员转向的工作简化为模型驱动的开发。我们将在组件语义方面看到切实的改进进展,因为,给定现今的从中间件的发展现状来看,组件的概念已经成熟。另一个改进进展将允许我们图形化地对业务规则和过程进行建模。简而言之,UML2.0将为模型驱动的开发奠定更加坚实的技术基础。最后,对于进行模型驱动的开发来说,UML 2.0的重大胜利将赋予我们更坚实的技术基础。



关于作者

Grady Booch,Grady Booch在软件架构,建模和软件工程过程领域的创新性工作是被国际公认的。他的工作已经改经了开发人员世界的效力。Grady是统一建模语言的创始人,并且他也是一些Rational产品,包括Rational Rose,业界领先的可视化开发工具的创始人。Grady是六本最热销的书籍的作者,他也发表了几百篇关于软件工程的技术文章,他在世界各地进行讲演和咨询。Grady是IBM Rational的首席科学家。




对本文的评价

太差! (1)
需提高 (2)
一般;尚可 (3)
好文章 (4)
真棒!(5)

建议?




回页首


IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可,请勿转载。如果您希望转载,请通过 提交转载请求表单 联系我们的编辑团队。
    关于 IBM 隐私条约 联系 IBM 使用条款