Grady Booch谈.NET和软件开发艺术
Msdn Magazine
Grady Booch因在软件架构（software architecture）、建模（modeling）和软件工程过程（software engineering process）方面的开创性工作而为国际公认。自1980年Rational软件公司创立以来，他一直为该公司首席科学家。Grady是统一建模语言（UML）最早的开发者之一。他是六本计算机科学畅销书的作者，包括《The Unified Modeling Language User Guide》 （Addison-Wesley， 1999）、具有开创意义的《Object-oriented Analysis and Design with Applications 》（Addison-Wesley， 1994）。MSDN Magazine最近抓住Grady，请他谈谈Microsoft .NET和Visual Studio .NET对于软件开发世界的影响。
Msdn Magazine：
对于您所看到的过去五年中软件开发的趋势和变化，您怎么描述？您又如何描述您对这些趋势的影响？
Grady：
去年夏天，我应邀在软件工程国际会议上做关于软件未来的重要讲话。正如Alan Kay所说，“预测未来的最佳方法是将其发明出来。”我们当然正在帮助发明一些用于将来的东西。但考虑到还有许多人正在做同样的事，我决定会见来自世界各地大约500名令人感兴趣的人。那500人实质上包括每一个计算机协会（ACM）和IEEE中从事软件工程领域工作的会员，每一位健在的图灵奖得主，许多引人关注的CTOs、CIOs，以及一些CEOs。从中，我总结出一些关于商业和软件自身的未来的结论。实际上，我将专注于后者。
毋庸置疑，Web的出现改变了一切，这不仅体现在我们如何交付应用方面，它同时还是我们构建应用的手段。我们看到许多人把Web用作他们项目的虚拟会议空间，我认为这是一个意义重大的进步。
在我看来，软件工程的大体趋势的确有一些值得我们探讨。我认为，作为整个业界，实际上在90年代后期就开始懂得软件开发的最佳实践是什么了，什么能行得通，什么不能，以及将这些实践进行系统整理的各类工具都有哪些。当然，从那时起，就已经有一些象XP这样的有趣的发展成果了。在这里，我并不是指Windows XP，而是指extreme programming（极限编程）这个术语的原始定义。我认为它带来了一些关于小团队的社会动力学和心理学的有趣思想。目前的现实是，XP和Rational统一过程（Rational Unified Process）彼此并不对立，而是互补的很好。实际上，倘若你看看组织所拥有的团队的规模，尤其是那些创建以Web为中心应用的，它们倾向于保持适度的规模。事实是，没有哪个团队是孤岛，这些团队都趋向于和其他团队协同工作。因此，在每一个层面上，你的确需要恰当的过程（processes）。
从技术的角度来看，我认为应以此顺序来理解过去大约五年里发生的几件大事：第一是面向对象技术成为主流；第二是UML的创造，它为我们铺设了一个通用语言和软件蓝图的基础；最后一点，以“四人组”的工作为最佳代表的软件模式概念。模式的真正意义在于它们代表了对抽象层次的又一个提升。实际上，假如纵观软件工程的整个历史，其实就是一个通过提高抽象层次以减轻复杂性的努力的过程。后面跟着设计模式的面向对象技术，不过是大势所趋而已。
我认为象Microsoft .NET Framework这样的技术的来临，象征着业界的一个认识：中间层有相当多的东西可以编成规则。它真正代表利害关系的恰当分离—谁创建应用程序，谁又必须架构基础设施，因为.NET带来了大量的基础设施，而在过去的十几年里，组织都试图创建它们自己的基础设施。进一步而言，它创建了如此之多的奇妙标准，比如SOAP和XML，这使得组织很容易创建相当“性感”、相当复杂的应用，并且这些应用可为它们的业务做出巨大贡献。这就是我们今天的境况。
Msdn Magazine：
在即将到来的几年里，您预期会看到哪些变化？
Grady：
这正是我真正的角色：透视现在，洞察未来。对于接下来的三到五年，我对两个即将出现的东西兴趣尤为浓厚。第一个，我称之为协作开发环境（collaborative development environments，CDE），我认为这将被MSDN Magazine的读者立即使用。让我们稍加思索一下Windows 2000的构建过程。它由一个团队的人们开发，这个团队是如此之大，以至于他们无法居于同一物理意义上的房间内。我听说这个团队通常使用Microsoft NetMeeting来和更大的团队保持联络。在建筑业和制造业，我们可以看到同样的现象。Web的使用，是开发的基础。
我相信，接下来的几年里，针对软件开发环境，将会出现同样的东西。相对于传统而言，它真正象征着一个突变—针对协作开发环境的集成开发环境。它以Web和artifact为中心，意味着工具将更加不可见，并且对于不同的客户（stakeholders），它们可以展现不同的视图。今天，存在许多不同的技术，有象NetMeeting和WebEx这样的用于在Web上举办会议和进行媒体共享的东西，在Web上还有讨论组、虚拟会议空间以及虚拟项目空间。没有哪一个是杀手级应用，而是许多彼此协作的小东西形成了这些CDE。
我间接提到了多视图的概念，它们引导我到下一个伟大的飞跃—Xerox PARC的Gregor Kiczales以及其他一些人所开创的AOP（aspect-oriented programming ）的概念。实际上，Charles Simonyi在他的目的编程（intentional programming）工作里，其实有一部分与之类似。Charles、Gregor和我在去年夏天DARPA和国家科学基金会（National Science Foundation，NSF）会议上，展望了软件和软件研究的未来。我们三个人认识到，在如何从多维视角来达成软件开发方面，的确存在某些基础性的东西。Charles有一些关于IP的着实迷人的想法，Gregor也是。我们把多视图的概念和创建一个系统架构概念明确提了出来。我想，就我对接下来的几年的规划来看，我认为AOP将会成为有趣的发展。切记：不是AOP要取代OOP，我们看到目前关于AOP的所有工作，特别是作为Gregor的目标，趋向于对业已伴随UML和OO技术而来的东西，起到补充作用。
我认为我最后应该提的一件事情是，软件依然是世界上大多数至关重要的工业的基础。即使在经济收缩时期，商业、组织和个人仍然依赖于软件。它们对我们职业人员提供服务的需求是无止境的。这是令人亢奋的时代。
Msdn Magazine：
您认为您已经直接影响了您刚才所谈论的所有那些趋势吗？
Grady：
没错，尤其是在OO程序设计领域。我想我可以声明一下，或者说，我乐意作一个声明：我可能发表了第一篇使用OO设计概念的论文，那要追溯到1982或1984年。通过我们共同的作品，Bjarne Stroustrup和我在一定程度上彼此相识。在80年代后期，他和我一起开始了一个旅程，因为我们发现，他在C++中的工作和我在面向对象方面的设计工作其实彼此互补。因此，我认为在帮助人们有效地使用C++方面，也应该有我一小份功劳。
当然啦，对于UML的创建，Ivar Jacobson博士、James Rumbaugh博士和我是关键的“煽动者”。事实上，即便我们是UML最初的创造者，它的发展也已经超乎我们想像。我们看到UML被用于为实时嵌入系统进行业务过程建模，而且实际上，当前还有人正在进行UML到Web Servieces的映射工作。我认为那是意义非凡的，因为作为一个迁移到越来越复杂的东西（象Web Services这样的技术已经“淹没”了语言或XML自身）上的组织，我们发现，当你关心伸缩性方面的问题时，有一套让你所有的客户（stakeholders）都可以使用的通用蓝图集，会使得在系统复杂性的管理方面，大为改观。最后要说的是，我一直在摆弄AOP和模式以及诸如此类的东西，我是个闲不下来的家伙。
Msdn Magazine：
听说微软在搞.NET，您的第一反应是？
Grady：
我认为这是了不起的，因为当我看到在微软一方和COM/COM+世界里以及非微软一方CORBA技术里苦苦挣扎的人们时，我的反应一直是，这里面的复杂性已经远远超出了它们应有的那样。所以，我对.NET的到来拍手喝彩，因为它将人们以前不得不自己做的事情编成规范。我还要说.NET还象征着在抽象层次上的又一个提升。此前，人们没有什么可以依赖，所以会存在多个操作系统，所以会有什么中间件。现在，有了象.NET这样的东西，它提高了抽象的层次。因此，作为一名开发人员，我可以集中于对我来说从根本上具有附加值的东西—主要是我业务上的东西，我可以少担心在我之下的所有基础设施。任何可以降低复杂性并能让我更快地创建高质量应用的东西，我都欢迎，而.NET做到了这一点。
Msdn Magazine：
您认为.NET Framework会改变面向对象分析的实践吗？
Grady：
好的，我想从方法论的角度来回答这个问题，但也允许我从团队和过程的角度予以回答。过去几年来，我看到许多组织为使用所有这些技术而苦苦挣扎，已经有相当可观的技术搅和在一起，以至于去让他们说说到底应该采用什么技术，简直成了一件颇具挑战性的事，而这种情况日益加剧。我们发现，在组织内部，有一小部分人对“中间件”和“管件”了然于胸，而另外一部分人则对业务了如指掌。但是，让这两个团队的人彼此交流，却一直让人头大。你陷入混乱中。搞数据库的同志们差不多是活在模式（schemas）里，并且明了关于它的一切。糟糕的是，你还有那帮内容构建者，他们带来了额外的复杂性。这些人通晓HTML，他们能够创建精灵古怪的Web页面。突然，又出现了一个现代的系统，来了一系列远比过去复杂的客户（stakeholder）。因此，将这些人揉在一起，一直都具有挑战性。UML可以帮助团队执行软件开发最佳实践，它已为我们所证实。
随着Microsoft .NET的来临，你所看到的，正是所有这些东西可以更富有效率的进行沟通的时机。.NET提高了抽象的层次，只要有人了解我的全部业务，我就可以很容易地将这部份业务从我的项目中独立或分离出去，并在这些更高层次的抽象基础之上，进行构建工作。
从方法论的观点来看，我认为.NET的出现，和面向对象技术仍然是难以置信的彼此互补。因为我们看到的所有依赖于这种技术的结构良好的系统，骨子里依然是面向对象的。.NET（尤其是通过Web Services）提供了一套对象，人们可以感兴趣的方式，组合使用。
我认为，.NET还为构建更高层次的框架创造了一个契机。实际上，关于这方面的努力成果，我们Rational有一个称为可重用资源规范（Reusable Asset Specification，RAS）的东西，微软是这个社团的成员之一。这个团体由所有大的组件厂商组成，其它还有IBM、Component Source、FlashLine等等。最初的动机是指定一个交付资源的共通方式，包括代码资源、测试资源、发行资源、版本资源和需求资源，所有这一切都和主框架有关。RAS规范已经运作一年多了，并且相当稳定。我们首先处理.NET一方。现在，这个小组的注意力正集中于收集潜在的非.NET框架以及其它中间件，因此，我们能够交付更高级的模式。你可以认为这象征另外一个提升—从“四人组”的设计模式进入框架领域。一旦我交付了框架（并且，顺便提一下，这些先天性的都是基于OO的），我就提供了一种机制，应用的创建者就可以其为基础，进行应用构建工作。因此，它在.NET和以前已经交付的东西之间，架起了一座桥梁。
Msdn Magazine：
Visual Studio .NET整合了相当多的建模特性，对此您怎么看？
Grady：
我认为这很棒！这说明微软方面也认识到建模是一件好事。我当然一直都清楚这一点，但由我来指出这一点，难免有“王婆卖瓜”之嫌。我认为任何能够推动建模进步的，都是优秀的东西。这儿，我要提到另外一位先生Edward R. Tufte的工作，以及他的经典著作《Envisioning Information》（Graphics Press，1990）和《The Visual Display of Quantitative Information》（Graphics Press，2001）。据他的观察，恰当的模型和恰当的抽象，不但可以帮助你处理复杂性，还可以帮助你以根本不同的方式来看待问题，这样，你就可以突破这个复杂性。这正是UML的全部。这也是建模之所以意义重大的原因。建模帮助你处理复杂性，它也帮助不同的客户（stakeholders）彼此沟通。如果我是一名业务人员，我了解我的业务规则，但是我真的不愿意去学习C#或Visual Basic，我只想用我自己的语言去表达这些业务规则。顺便提一下，这也正是蕴藏于Charles Simonyi在IP方面工作背后的基本原理—领域相关的事物表示法的概念。把这个问题降至软件这个层面，恰恰就是UML的位置。这也是我为什么对看到Visual Studio .NET中有越来越多的建模支持而感到高兴的原因。
Msdn Magazine：
有了Visual Studio .NET，现在很容易在同一个项目里混用多种语言。对于它所导致的特别的机遇，或者说，特别的问题，您的看法是？
Grady：
我曾经是一个盲目的语言信仰者。多年以前，我以为ADA是上帝赐予的语言。然后，我发现了C++，于是我认为我错了，然后我改变了我的信仰。然后，我又看到了Smalltalk，然后，我又看到了其它一些语言。我意识到我需要一些在技术上对我适用的语言。然而，语言的选择往往并非出于技术上的考虑，还有与我的团队文化有关的文化上的决定—他们以前使用什么，他们已经工作的领域，等等。我考察了现有的大量的语言—C#、C++、Visual Basic以及很多其它处于同一空间的语言。我现在相信，没错，从某种程度上来说，它们是不一样，但从另外的层面来看，它们也大差不差。除非我在谈论象CLOS（Common Lisp Object System）这样的怪异的语言，对于我来说，语言并非太要紧。我们谈论绝大多数开发人员使用的语言，它对我来说没有太多的意义。这就是围绕着那些语言的东西：它的框架，它的工具，以及它的组件，等等。
现实是，我发现只有少得可怜的项目只涉及一种语言。我刚刚和一个蜂窝电话制造公司的架构师谈过话。他向我介绍了他们下一代的蜂窝电话，它将涉及一大把不同的语言，从汇编开始，一直往上。这就是绝大多数项目的实际情况。它们不是使用一种语言，它们并非同质，而是异质的。不管你喜欢与否，文化（culture）也要求组织同时处理多语言问题。一个小组或许使用单一的语言，但作为组织的整体来说，通常需要多种语言。因此，任何可以在这些鸿沟上架桥铺路的东西，以及任何可以打倒这些语言之间的藩篱的东西，都是了不起的，这正是.NET的擅长之一。
Msdn Magazine：
您用过C#吗？您认为它会带来什么影响？
Grady：
让我重申一下，多年以来，我已不再执迷于语言，所以，我不大关心新出现的语言。我想，C#应该具有某些奇妙的特性，并且，因为它不是我唯一可用于.NET的语言，这就是了不起的事情。相对于C++而言，在某些方面，它要简单些，并且优雅得多。在我所做的事情里，我依然主要使用C++，但是我多工作于Web密集型之外的系统。
Msdn Magazine：
关于.NET的另外一个方面是，它可以使用并存的装配件（side-by-side assemblies）。您认为这是优点，亦或，它可能会导致更草率的发行，因为它们可被很容易地修复？（译注：同一装配件的不同版本可以并存于同一机器中甚至是同一进程内。）
Grady：
对于马马虎虎的发行版本，我并不认为仅仅因为它们可被更容易地修复，市场就会比以前更能容忍它们。任何能够促进过程（process）的东西都是一个积极的进步。在Rational公司，我们有ClearCase，它是一个极具威力的工具，因为它几乎同时支持系统开发中多个发行版本和多种视图。在今天，你从来都不会只有单一的发行版，尤其是在分布式环境里。你有部署在不同地方的不同版本的东西，并且你要经常做出修改。因此，对于能够促进快速、高质量的、改善系统发行的任何东西，我们都需要。
Msdn Magazine：
您在Rational或其它公司看到过提早设定项目架构的指导方针吗？就象您可以在Visual Studio使用企业模板做的那样。这种方式有成功的先例吗？
Grady：
首先，我是一个不折不扣的架构信徒。这儿（在Visual Studio .NET中），我们有一个IDE，它让架构将视图强加于这个世界。从某种意义上来说，这允许某种程度的多维开发（multidimensional development），并使得架构能得到一些控制，这是一件好事。现在，组织是否能很好地控制架构，坦白地说，依赖于他们对架构重要性的理解。根据我们的经验，坚实的架构是项目成功的优秀“预言家”。我不是指重型架构，而是指预先在某种程度上，将重要的设计决策系统地整理过的架构。
我在Rational公司做的事情之一，就是充当一名项目架构顾问，因此，实际上我自己做了很多架构方面的工作。大约一年前，我和瑞士的一家大银行（刚刚和另外一家瑞士大银行合并）的首席架构师共事过。他考察了他们将要构建的系统，我从两个方面来表达他的意思。第一，他说，全欧洲没有他需要的足够的PhDs来构建他需要构建的东西。第二，他说，软件从根本上说，就是银行，所以，他们正在做的，对于组织的将来，至关重要。作为一名架构师，他意识到，可能有许多人编写代码，不是左了，就是右了，因此，前面有很多重大技术风险。架构小组的目的是建立基础框架和基本机制，所有的应用都以此来创建。通过对这些东西的开发并进行验证，在你开始雇佣许多其它人之前确保它们行得通，架构实际上充当了狙击风险的手段。说得再明白一些，正如Tom Gilb所言，“如果你不积极地狙击你项目中的风险，它们就将积极地狙击你”。一个主要的技术风险就是是否拥有一个强健的架构。说到架构，我并不是指“紧绷绷的限制”，我是指用于构建应用的关键机制的规范。
Msdn Magazine：
在这个杂志上，我们能听到两种截然不同的声音。我们有很多对.NET极其兴奋的开发者，他们已经探索它，甚至使用beta软件来构建和运行Web Services。然而，我们也受到那些仍然努力处理很多遗留系统并且仍然实在也不愿意听到关于.NET方面的东西的人的批评。您对今天的开发人员有什么建议，您认为他们在向前进的过程中，最好应该做哪些事情？
Grady：
技术的搅来拌去一直都是一种挑战。你知道，很多遗留系统能够让人们立刻开展业务，然而，它们仍然必须前进到某种新技术上。.NET通过Web Service所提供的东西，的确是一种非常不同的构建系统方式。系统变为以服务的形式来交付，而这些服务使用SOAP和XML穿透防火墙来传输对象。实际上，这正是Web密集型系统正在发展的非常自然的方向。如果你看看W3C正在做的所有那些事，以及Tim Berners Lee的关于Semantic Web的概念，所有这些技术，都越来越把我们往那个方向推动。因此，这种变化是必然的。我对那些致力于某些最佳开发实践的团队，给出一些普适的指导观点：架构先行，使用建模，对变动管理进行控制，这些都是基本原则，它们可以使你有备于对技术变化的承受，而那是你迟早都要应付的事。如果你从C++移到C#，并没有大的跳跃；从client/server移到Web密集型的系统，便会有些不爽；但从今天已经创建的Web密集型的系统迁移到Web Services，并没有那么大的动作。我预期我们将会看到组织努力去创建它们自己的Web Services，因为它们一开始并不会选择在公用的服务上来构建它们的系统，除非那些公用服务是由象微软这样的的平台成员提供的。它会处理可信任性、可用性、安全性和可扩展性这些问题。因此它们将先创建自己的服务来探探水性，然后再在公用服务上构建自己的系统。
Msdn Magazine：
我听到许多关于设计模式的东西，并且您也提到了AOP。您对团队给出一般性的建议时，包括这些吗？
Grady：
对于设计模式，那绝对包括。我所遇到的所有具有超高生产力的团队都使用设计模式。设计模式的伟大之处在于为团队提供了一个更高层面的抽象的交流方式。当我在一个项目组中时，我说，“这儿你应该使用一个proxy模式”，或者说“你应该使用X模式”，他们立刻就明白我说的是什么意思。而且，最好的项目还将着手创建它们自己的某种模式，那很棒。因此，设计模式就如某种平台独立的技术，因为它们是一种更高效地使用面向对象技术的方式。
至于AOP，它其实已经存在一些年头了。我们看到一些思想已经结出了果实，但是目前我当然还不想把我的业务赌在AOP上。然而，作为一个搞技术的人，它的确勾起了我的兴趣。我留意这些东西，也为之操心，因为我要帮助人们做好下一个飞跃，以创建高质量的系统。
Msdn Magazine：
您有什么评论要补充的吗？或者，有什么额外的消息愿意传达给我们的读者吗？
Grady：
如果来做个总结，我会强调三件事。首先，软件开发依然是世界上最重要的工业，因此，我们业界所做的依然是为世界经济加油。商务的质量和持久性，依旧依赖于软件。组织、国家、每一个人都依赖于软件，并且，这种情况将不会有什么变化。假如一定要说有什么变化的话，那就是随着时间的推移，软件将变得越来越重要。
我要说的第二点是，软件开发依然极端困难。这也是为什么作为这个领域的职业人员，我们必须使用一切可能的手段，以准时交付系统，并保证优异质量，因为从某种意义上说，世界依赖于我们。
我想提的第三件事情是，所有这一切，都使得对于软件业来说，正处于一个令人兴奋的时代。我很高兴看到.NET迈出了第一步。从Rational公司稳固地采用最佳实践，是对微软提供的东西的补充。我对RAS规范、设计模式以及诸如此类我所提到的东西，感到高兴。所有这一切，都是对个体开发者、团队开发者以及团队的团队的工具箱的贡献，可以帮助他们构建高质量的系统。
－全文完－
本文地址：http://com.8s8s.com/it/it46115.htm