四十年软件工程故事

2008年5月14~16日，在德国迷人的小镇Garmisch，举办了软件工程四十年纪念会议，Peter Naur、Brian Randell、M. Douglas McIlroy、Albert Endres、Luigi Dadda等40年前软件工程会议的关键人物重聚旧地。

40年前的1968年，正是在此地举行的NATO（北约）科技委员会会议上，“软件工程”作为正式的术语被确定下来，标志着一个新学科的开始。 Peter Naur和Brian Randell主编的会议报告中这样写道：“我们特意选择‘软件工程’这个颇具争议性的词，是为了暗示这样一种意见：软件的生产有必要建立在某些理论基础和实践指导之上——在工程学的某些成效卓著的分支中，这些理论基础和实践指导早已成为了一种传统。”

软件工程这个学科还很年轻，Peter Naur和Brian Randell今天依然健在。作为著名的编程语言归约BNF范式中的N，Peter Naur因设计和定义了ALGOL 60而在2005年获得图灵奖。因IBM System360的工作于1999年获得图灵奖的Fred Brooks在《人月神话》的结尾比较了化学工程和软件工程。他认为：软件系统可能是人类所创造的最错综复杂的事物，软件工程还很年轻，需要继续探索和尝试。

这四十年的过程就是探索和尝试的过程，让我们来细细品味其中的科学精神之美。

软件工程是什么

软件工程的定义有很多版本，比较权威的是IEEE给出的定义：（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即，将工程应用于软件。（2）在（1）中所述方法的研究。

所以，软件工程远没有想象中那么高大神秘，它研究的就是我们日常开发软件的工作方式。“程序员”这三个字本就属于软件工程的范围。

关于软件工程和计算机科学的区别，Fred Brooks说：A scientist builds in order to learn; an engineer learns in order to build. 更详细的可以看看David Parnas的“Software Engineering Programs Are Not Computer Science Programs”和Steve McConnell所著“Professional Software Development”的第4章。或者对照一下图灵奖获得者：软件工程领域的David Parnas、Frederick P. Brooks和计算机科学领域的Donald E. Knuth、《程序员》上期介绍的YAO。

软件是为人开发的，软件是由人开发的。正是因为人的心理难以捉摸，人的大脑处理复杂性时速度和容量的局限，我们才需要过程来规范人的行为，需要方法来帮助人脑面对复杂性，需要工具来贯彻这些过程和方法。所以，软件工程的知识体系分为以下几层。我们按照这个金字塔结构，逐层回顾四十年来的历史。

过程

一开始，软件团队是没有过程的，甚至没有团队概念。没有需求规格说明，没有设计，程序员在大脑中直接将代码思考出来，拼凑到一起，交给客户使用。客户如果有要求，再修改代码，如此反复。这种“编码－修改”做法对于小程序可以应付，当程序规模变得复杂时，付出的代价就很大了。

瀑布

“软件工程”概念的提出，促进了需求、分析、设计、实现、维护等软件生命周期概念的成熟。瀑布模型是最早的软件过程模型，从名字“瀑布”可以看出，通常人们认为瀑布模型中的各个步骤是一条线完成的。实际上在Winston W. Royce1970年的经典论文“Managing the Development of Large Software Systems”中有反馈的过程（见图3），作者本人也并不提倡以顺序模型作为团队的过程模型，另外，Royce并没有在论文中把他的过程模型叫做“瀑布 ”，只是后来其他人这么叫了。很多团队使用时是按照线性的方式使用的，这是一种误解。

这里要提一下，瀑布模型的提出者Winston W. Royce（已于1995年去世）有时被简写为W. Royce，所以经常会引起误会，把他当成Walker Royce，后者是软件项目管理专家，曾任Rational软件公司副总裁，著有《Software Project Management: A Unified Framework》一书。

增量和迭代

使用瀑布模型，可以运行的产品很迟才能看到，这就潜伏了巨大的风险：很可能，集成之日也就是爆炸之日。为了提早获得可以运行的版本，可以先实现一些功能，再实现一些功能……每个增量交付一个可以运行的版本。

增量开发显著降低了风险，而且还因可运行产品的出现大大提升了士气。最有名的实践应该是Microsoft在1989年就开始使用的Daily Build（每日构建）,被称为项目的“心跳”。当然，增量开发不一定意味着每日构建，如Fred Brooks所述，Bell Northern Research是“每周构建”。

增量经常和迭代连在一起说，不过两者是有区别的。增量是逐块建造的概念，迭代是反复求精的概念。二者不一定要绑在一起使用，但很明显，结合这两种方式是一种有效的做法。现在很多过程所说的迭代开发，默认的意思就是增量&迭代。Jeff Patton最近用两幅图表达了增量和迭代（http://www.agileproductdesign.com/blog/dont_know_what_i_want.html）。

统一过程

1987年，Ivar Jacobson离开Eric-sson，成立了Objective Systems公司。他吸纳了增量迭代的思想，开发出Objectory过程，并且把过程当软件卖，价格卖到25000美元一份，以至于Ivar Jacobson不想在Addison-Wesley等出版社出书公开他的方法，因为卖一本书才得到3美元。1991年，Ericsson收购了该公司，并更名为Objectory AB（北欧出大师，所以我们常在软件开发的书籍和文章中看到××AB等文字，AB是瑞典语Altiebolag的缩写，意思是“公司”），Ivar Jacobson又回到了Ericsson。

1995年，Rational从Ericsson收购了Objectory，Ivar Jacobson开始和Grady Booch、James Rumbaugh一起开发UML。Philippe Kruchten则负责把Objectory过程和Rational公司多年的积累Rational Approach融合在一起，开发出了“Rational Unified Process”以及4+1视图模型。RUP的中心思想是：用例驱动、架构为中心、迭代和增量。虽然是一个商业产品，但详尽的内容和灵活的组织，使得RUP成为软件团队中流传最广的软件过程模型，也成为团队学习软件工程和实施过程改进的重要资料。

Ivar Jacobson在IBM收购后离开了Rational。2005年，他发布了Essential Unified Process（EssUP）将之描述为“超轻和超敏捷的”RUP，并且提出了过程定义（PD）和过程（P）的观点，他认为统一过程是一个过程定义（PD），不是过程（P），团队不能看着别人的P好，就想着拿来就用，必须要找到自己的点。

2007年，Ivar Jacobson的新观点是“过程够了，实践吧（Enough of Processes: Let's Do Practices）”。
Doug Rosenberg和Kendall Scott的ICONIX过程借鉴了Ivar Jacobson和统一过程的思想，而且以其小巧易懂，受到不少开发人员的欢迎。

敏捷运动

敏捷运动在20世纪90年代中期兴起，当时敏捷过程被称为“轻量”过程。2001年，Kent Beck、Alistair Cockburn、Ward Cunningham、Martin Fowler、Jim Highsmith、Ron Jeffries、Jon Kern、Robert C. Martin、Steve Mellor、Ken Schwaber等人聚集在犹他州的Snowbird，决定把“敏捷”作为新的过程家族的名称，并提出以下宣言：

随后，敏捷联盟成立，这是一个致力于传播敏捷过程的非营利组织。敏捷联盟每年召开敏捷大会，今年已经是第6年。

关于敏捷过程，比较全面的介绍文章是Martin Fowler的“The New Methodology”。每隔一段时间，Fowler会随着形势的变化更新此文。该文2005年12月版本列出的各种流行敏捷过程包括：极限编程（XP）、Scrum、Crystal、上下文驱动测试（Context Driven Testing）、精益开发（Lean Development）、统一过程（Unified Process）。

极限编程（XP）是敏捷过程的代表。1996年，Kent Beck为了挽救Chrysler Comprehensive Compensation （C3）项目而创建了XP过程，虽然Chrysler最终取消了该项目，但是Ron Jeffries和Ward Cunningham等人参与到了XP的工作中。1999年，Kent Beck出版了“Extreme Programming Explained: Embrace Change”一书。XP一代相当于程序员的宣言，受到了程序员的热烈欢迎。2004年，该书第2版出版，Kent Beck说自己几乎完全重写了整本书，书中关于程序员是宇宙中心的内容少了很多，更多的是谈程序员和编程工作必须处于业务环境中，他们需要成为正常商业世界中的一部分。

过程评估和CMM

从1968年开始，Watts S. Humphrey是IBM负责软件部门的副总裁。1986年，Watts S. Humphrey离开IBM后，加入了SEI（卡内基?梅隆大学软件工程研究所），开始开发CMM（Capability Maturity Model，能力成熟度模型）。CMM一开始的目的是为军方制定一个好用的评估承包商的标准，因为SEI本来就是军方资助的机构。

1989年，在《Managing the Soft-ware Process》一书中，Humphrey描述了CMM。CMM可以看作是一个软件过程元模型，定义软件组织达到一定能力成熟度所需的关键过程域（KPA）。
20世纪90年代中期，CMM开始在世界范围内流传开来，成为一些政府采纳的评估软件组织的标准，政府甚至对通过评估的软件组织加以资助。在这种激励下，想获得政府订单或者政府资助的软件组织纷纷力争通过CMM评估。目前，通过CMM/CMMI评估的组织数量前三位国家是：美国、印度和中国。

方法

在20世纪60年代，程序员随意地编写代码。虽然当时已经出现了FORTRAN等高级语言，但程序员把代码写在一起，代码中使用GOTO语句来跳转，使得程序的内部结构像“意大利面”，整个程序又像一块铁板，无法单独抽取其中一部分复用。

功能分解

1968年，Edsger W. Dijkstra发表《Go To Statement Considered Harmful》，认为GOTO语句是有害的，应该把程序划分成多个子单元，每个子单元只做一件事，当重复的语句集合出现时，只需要调用相应子单元(函数)。这相当于封装和复用了共同的行为。

数据流

当软件的规模不断变大，大到不能一下子映射到代码级别时，就需要更大颗粒的分析设计方法。20世纪70年代，数据流法出现了，有三种流行的流派：DeMarco方法（1978）、Gane/Sarsen方法（1979）以及Yourdon/Constantine方法（1979）。

数据流法把系统看作数据的加工机，数据流进去，经过加工，变成新的数据流出来。从最顶层开始（因为此时系统看作是一个整体，所以表达的就是功能需求），一层一层向下求精，一直求精到泡泡所代表的加工成为可以编码的动作。

实体/关系

20世纪70年代末，关系数据库开始变得流行。Peter Chen（陈品山）在1976提出实体关系（ER）模型，用实体和关系映射现实中的事物和概念。该模型提供了数据的图形视角，并能轻松转换为关系数据库模型。分析员很快认识到，ER模型可以用来表达大型软件的数据库设计，更宏观地把握业务，而且还有助于分析员和用户交流。

数据流法结合实体关系法，曾经是比较流行的开发软件的方法。这种做法的一个问题是数据和行为是分离的，行为可以随意读写数据。另一个问题是分析和设计之间表达不一致，使得从设计回溯到分析相当困难。这正是面向对象分析设计所要改进的。

面向对象

Alan Kay说“面向对象”这个词是他在1967年首先使用的（http://www.purl.org/stefan_ram/pub /doc_kay_oop_en），但人们普遍认为，1967年由挪威的Ole-Johan Dahl和Kristen Nygaard设计的Simula-67是第一门面向对象语言，它是作为ALGOL的一个超集出现的。虽然Simula没有后继版本，但这个语言对后来的许多面向对象语言的设计者产生了很大的影响，80年代初，Alan Kay在Palo Alto研发的Smalltalk语言被广泛使用（Kent Beck就是Smalltalk的拥护者），掀起了一场“面向对象运动”，许多面向对象语言随之诞生。Grady Booch在他的最新著作“Object-Oriented Analysis and Design with Applications”第3版中归纳。

面向对象的思想就是：假设系统由“对象”这样一种东西构成，对象封装了结构和行为。这种思考方式和人类的认知相当贴近，更有利于人脑去把握问题的复杂性。分类是人类认知的一种基本技能，分类哲学的讨论可以追溯到柏拉图的《政治家》和亚里士多德的《范畴》。

结构化分析设计和面向对象编程之间不能很好地过渡，到1980年代后期，不同的方法学家开始提出自己的面向对象分析设计方法学。这些方法学主要有：Booch、Shlaer/Mellor、Wirfs-Brock责任驱动设计、Coad/Yourdon、Rumbaugh OMT、Jacobson OOSE。

UML

这种百花齐放的局面带来了一个问题：各方法学有自己的一套概念、定义、标记符号和术语，但总的来说大同小异。这些细微的差异通常会造成混乱，使开发人员无从选择，也妨碍了面向对象分析设计的推广。
1994年，在Rational工作的Rumbaugh和Booch开始合并OMT和Booch方法。随后，Jacobson带着他的OOSE方法学也加入了Rational公司，一同参与这项工作。他们三个人被称为“三友”（three amigo）。这项工作造成了很大的冲击，因为在此之前，各种方法学的拥护者觉得没有必要放弃自己已经采用的表示法，而接受统一的表示法。

1996年，三友开始与James Odell、Peter Coad、David Harel等来自其他公司的方法学家合作，吸纳了他们的成果精华。1997年9月，所有建议被合并成一套建议书提交给OMG。1997年11月，UML被 OMG全体成员一致通过，并采纳为标准。UML诞生时，Martin Fowler就作了如下预测：

你应该使用UML吗？一个字：是！旧的面向对象符号正在快速地消逝。它们还会残留在UML稳固前出版的书上面，但新的书、文章等等将会全部以UML 作为符号。如果你正在使用旧的符号，你就应该在1998年间转换到UML。如果你正要开始使用建模符号，你就该直接学习UML。

时间过去10年了，事实正是如此。以UML为契机，掀起了一股普及软件工程的热潮，比起UML出现之前，软件工程的书籍出现了爆炸性的增长。制定 UML标准的角色（OMG）、根据标准开发工具的角色（UML工具厂商）、使用UML工具开发软件的角色（开发人员）这三种角色的剥离，也导致建模工具数量和种类出现了爆炸性的增长。

现在，UML已经被ISO吸纳为标准，UML1.4.2即ISO/IEC 19501，UML2.1.2即ISO/IEC 19505。

模式运动

1979年，Christopher Alexander开始使用“模式”来描述建筑的构造方法。1987年，Kent Beck和Ward Cunningham尝试把这种思路应用到软件开发中，并在OOPSLA大会上发表了自己的看法。一直到1994年10月，被称为四人帮（GoF）的 Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides所写的《设计模式》上市（此书是1995年的版权，看来国内外出版业差不多，我们可以在2007年12月买到2008年1月第1版的书），模式的概念才流行起来。此书到2007年为止共重印36次，被翻译成13种其他语言，而且有不计其数的兄弟书籍诞生出来，“言必称模式”成为一种时髦，可谓影响深远。

现在，除了最常提到的GoF的23种设计模式之外，不断有各种各样的模式提出来，包括分析模式、架构模式、过程模式、组织模式、实现模式、反模式……

工具

很长一段时间内，软件开发工具指的就是代码工具，而且编辑、调试、编译是分离的。后来慢慢出现了IDE（集成开发环境），各大工具厂商更是在IDE市场激战。这方面的故事，大家可以看李维的《Borland传奇》。

在软件工程工具如分析设计、过程管理等工具方面，却是一片空白。一直到1982年，Nastec公司开发出了DesignAid，该工具提供绘制系统设计图和建立数据字典的功能。到了1990年代，随着方法学繁荣和图形界面的普及，才出现了大量的设计工具，典型的代表是Rational Rose和Popkin System Architect。

最初的设计工具以独立的产品存在，而且只是提供了画图的功能，然后慢慢有了代码正向逆向工程。开发人员在设计工具里建好模型，再通过一个转换器在代码环境生成代码。设计工具的一个变种是成为代码环境的插件（Rational XDE，Together for VS.net等），直接在代码环境中创建设计模型，和代码高效同步。

接下来的趋势是设计工具和生命周期其他工具集成。2002年10月，Borland收购了当时UML工具厂商中的老二Togethersoft，这成为了导火索。之后，IBM、Telelogic、Borland等大厂商通过并购和放弃，打造出了新的品类——应用生命周期管理（ALM）工具。微软的工具Visual Studio Team System也在朝ALM工具方向进化。图12列出了三家ALM厂商一些产品的对比。

现在，Rational和Telelogic都已经被IBM收入旗下，但Sparx Systems、NoMagic、Gentleware等中小厂商纷纷加入到这个市场中，竞争依然激烈。我们来看看代表性厂商Rational的历史，也可以从一个侧面了解工具的发展。

结语

1999年，我创建了UMLChina，从那时开始关注软件工程各方面的进展。到现在为止，我已经上门为超过100个软件开发团队提供需求和设计技能（根据我们上面的分类，这属于“方法”层面）服务。我发现一个有趣的现象，在开始服务之前的商议过程中，很多开发团队（不是每个团队）或多或少都会有人（不是每个人）或明或暗地表达出这样的观点：自己团队的难处与众不同，奇特的困难降临在他们身上，偏偏别人得以幸免。

尽管UMLChina一直强调自己的服务是“聚焦最后一公里”，坚信每一个开发团队都会在细节上和其他团队有所不同，而且也应该有所不同。但很多时候，我还是感觉到，开发团队还是高估了自己的“个性”，低估了“共性”。

最核心的共性问题，仍然是质量——能最大化获取利润的质量。它无非是两条路：增加收入——如何把东西更好地“卖”出去（给客户，给领导……）；减少成本——如何用可复用的要素（组件、过程……）降低制造的成本。这些正是软件工程的不同分支（需求工程、架构设计、过程改进……）要研究的。四十年来的研究成果，肯定会有一些适合您的团队。这些成果是先行者们从自己或别人的血泪中提炼出来的，我们没有必要再重复挥洒血泪了。

潘加宇，UMLChina首席专家,潜心研究和实践UML/UP相关技术的应用。

本文摘自2008年第9期《程序员》。欢迎订阅《程序员》