需求内容
· 系统的所有输入都定义了吗？包括它们的来源、精度、取值范围和频率？
· 系统所有的输出都定义了吗？包括它们的目标、精度、取值范围、频率和格式？
· 所有的报告格式都定义了吗？
· 所有的硬件与软件接口都定义了吗？
· 所有的通信交界面都定义了吗？包括握手、错误检查以及通信约定？
· 是否从用户的观点出发，定义了所有必要操作的反应时间？
· 是否定义了时间问题，如处理时间、数据传输率以及系统吞吐能力？
· 是否对用户所要求完成的任务部作出了规定？
· 每项任务所需用到和产生的数据都规定了吗？
· 规定保密级别了吗？
· 规定可靠性了吗？包括软件出错的后果、在出错时要保护的至关重要的信息、以及错误
测试和恢复策略。
· 规定所需最大内存了吗？
· 所需最大存储容量规定了吗？
· 对系统的维护性是否作出了规定？包括系统对运行环境、精度、性能以其与其它软件的
接口等方面变化的适应能力规定了吗？
· 是否规定了相互冲突的设计之间的折衷原则，例如，在坚固性与准确性之间如何进行折
衷？
· 是否制定了系统成败的标准？
关于需求的完善性
· 在开发开始前暂时得不到的信息是什么？是否规定了不够完善的区域？
· 需求定义是否已经完善到了可以成为软件标准的地步？
· 需求中是否有哪一部分令你感到不安？有没有根本不可能实现，而仅仅为了取悦老板和
用户才加进来的内容？
关于需求的质量
· 需求是否是用用户的语言制定的？用户也这样认为吗？
· 需求中是否每一条之间都尽量避免冲突？
· 需求中是否注意了避免规定设计工作？
· 需求在详细程度方面是否保持了一致性；有没有应该更详细些的要求？有没有应该更
简略些的？
· 需求是否明确得可以分为一些独立的可执行部分，而每一部分又都很明了？
· 是否每一条都与问题和答案相关？是否每一条都可以追溯到产生它的环境中？
· 是否每一条需求都可以作为测试依据？是否可以针对每一条进行独立测试以确定是否满
足需求？
· 是否对可能的改动作出了规定？包括每一改动的可能性？
关于需求定义的进一步阅读
以下是一些给出了如何进行需求定义的书：
DeMarco, Tom 《Structured Analysis and Systems Specification：Tools and Techniques 》

Englewood Cliffs，N.J：Prentice Hall，1979，这是关于需求定义的经典著作。
Yourdon，Edward 《Modern Structured Analysis》New York：Yourdon Press，1989，这本
新书论述了许多进行需求定义的文字和图表工具。
Hatley，Derek J和Imtiz A． Pirbhai 《Strategies for Real－Time system Specification》Newyork :
Dorset house，1988。这是一本替代DeMarco或Yourdon书的最佳选择。它重点论述了实时系统，
并把DeDarco 和Yourdon提出的图表法扩展到了实时系统中。
Shlaer，sally和Stephen Mellor《Object Oritented System Analysis－Modeling the World in
Data》Englen wood Cliffs，N.J： Prentice Hall，1988。本书讨论了面向对象设计中的需求分析。
IEEE Std 830－1984（Guide for Software Requirements Specifications） in IEEE 1991。这份
文献是IEEE 为编制软件开发需求定义制订的指导性论述。它描述了需求定义中应该包括的内
容并给出了几个例子。
Gibson，Elizabeth《objects－Born and Bred》Byte，1990 10:245－54。这篇文章是关于面向
对象需求分析的入门书。
                3.4  结构设计先决条件
软件结构设计是较高级意义上的软件设计，它是支持详细设计的框架。结构也被称为“系
统结构”、“设计”、“高水平设计”或者“顶层设计”。一般说来，结构体系往往在一个被称为“结
构定义”或者“顶层设计”的单一文件中进行描述。
由于本书是关干创建活动的，因此这部分也没有讲述如何开发软件结构。本部分的中心是
如何确定一个现存结构质量。因为结构设计比求定义更接近于创建活动，因此对于结构设计的
描述要比要求定义详尽得多。
为什么要把结构设计当成先决条件呢？因为结构设计的质量决定了系统概念上的完整性，
而这又会决定系统的最终质量。好的结构设计可能使创建工作变得很容易，而坏的结构设计则
使创建活动几乎无法进行。
在创建活动中，对结构设计进行变动也是很昂贵的。一般来说，在创建阶段修复结构设计
错误要比修复要求错误耗时少，但比修正编码错误耗时多得多。从这个意义上来说，结构变动
与变动要求差不多，所以，无论是出干修正错误还是提高性能的动机，如果要进行结构变动的
话，那么越早越好。
3.4.1 典型的结构要素
有许多要素是一个好的系统结构所共有的。如果你是一个人在独自开发一个系统，那么你
的结构设计工作，或者说顶层设计工作，将与你的详细设计工作重叠。在这种倩况下，至少你
应该考虑每一个结构要素。如果你正在从事一项由别人进行结构设计的系统工作，你应该不费
什么劲儿就能找到其中的重要部分。下面是一些在两种情况下都需要考虑的要素。
程序的组织形式
一个系统结构首先需要一个总体上的概括性描述。如果没有的话，从成千个细节与几十个
独立模块中勾画出一幅完整的图画将是一件十分困难的事情。如果这个程序仅仅是一个由十二

块积木组成的小房子，那么或许连你那两岁的儿子也会认为这很容易。然而，对于一个由十二
个模块组成的软件系统，事情恐怕就困难得多了。因为你很难把它们组合到一起，而如果不能
把它们组合到一起，你就不会理解自己所开发的这一个模块对系统有什么贡献。
在结构设计中，你应该能找出最终组织形式的几种方案，并且应该知道为什么选中了现在
这种组织形式。如果开发模块在系统中不被重视，会使人产生挫折感。通过描述这些组织形式
的替代方案，我们就可以从结构设计中找出选择目前方案的原因，并已知道每一个模块的功能
都仔细考虑过了。回顾设计实践发现，设计理由对于维护性来说，与设计本身是同样重要的
（Rombach 1990）
在结构设计中，应该在程序中定义主要模块。在这里，“模块”并不是指子程序。在结构
设计中通常不考虑建立模块一级的子程序。一个模块是一个能完成某一高级功能的子程序的组
合，例如，对输出结果进行格式化，解释命令，从文件中读取数据等。在要求定义中列出的每
一项功能，都应该有至少一个模块覆盖这项功能。如果一项功能由两个或更多的模块覆盖，那
么它们之间应该是互补的而不是相互冲突。
每一个模块作什么应该明确定义。一个模块应该只完成一项任务而且圆满完成。对于与它
相作用的其它模块情况，你知道得越少越好。通过尽可能地降低模块之间的了解程度，就可能
把设计信息都集中在一个模块中。
每个模块之间的交界面也应该明确定义。结构设计应该规定可以直接调用哪些模块，哪些
模块它不能调用。同时，结构设计也应该定义模块传送和从其它模块接收的数据。
变动策略
创建一个软件系统，对于程序员和用户来说，都是一个逐渐学习的过程，因此在这个过程
中作出变动是不可避免的。变动产生的原因可能是由于反复无常的数据结构，也可能是由于文
件格式和系统功能改变，新的性能等而引起的。这些变动有时是为了增加新的能力以便强化功
能，也有时是版本增加而引起的。所以结构设计所面临的主要挑战便是增强系统的灵活性，以
便容纳这类变动。
结构设计应该清晰地描述系统应付变动的策略。结构设计应该表明：设计中已经考虑到了
可能的功能增强变动，而且，应该使最可能的变动同时世是最容易实现的变动。比如，假设最
可能的变动是输入或者输出格式、用户界面的方式或者处理要求，那么结构设计就应表明已经
预先考虑到了这些变动，而且，其中每一个单一的变动，只会涉及到数量有限的几个模块。在
结构设计中应付变动的手段可能是非常简单的，比如在数据文件中加入版本号，保留一部分区
域以备将来使用，或是设计一些可以添加内容的文件。
结构设计中应该说明用于延缓变动的策略。比如，结构设计中可能规定应使用表驱动技术
而不是手工编码技术。它还可能规定表所使用的文件应该保存在一个外部文件中，而不是编码
在程序中，这样，可以不必重新编译就可以对程序作出调整。
购买而不是建造的决定
创建一个软件的最彻底的办法并不是创建——而是去购买一个软件，你可以购买数据库管
理系统、屏幕生成程序、报告生成程序和图形环境。在苹果公司Macintosh或者微软公司
Windows环境下编程的一个主要优点是你可以自动获得许多功能；图形程序，对话框管理程序，

键盘与处理程序，可以自动与任何打印机或者监视器工作的代码，等等。
如果计划中要求使用已有的程序，那它就该指出如何使这些重新被使用的软件适应新的要
求，而且它应该证明这个软件可以通过改动来满足新的要求。
Barry Boehm在1984 年指出：从长远观点来看，重新使用旧软件是提高生产率的首要因素。
购买代码可以降低计划、详细设计、测试和调试的工作量。Caper Jones在1986 年报告如果购
买的代码从0 上升到50％，那么生产率可以提高一倍。
主要的数据结构
结构设计应该给出使用的主要文件、表和数据结构。同时，还应给出考虑的替代方案并评
审作出的选择。在《Software Maintenance Guidebook》一书中，Glass和Noiseux 认为数据结构
对系统维护有举足轻重的影响，因而，它应该在经过全盘考虑之后，才能选定（1981 年）。如
果某一应用需要维护一个用户识别表，而结构设计又选中了顺序存取表来实现，那它就该解释
为什么顺序存取表要好于随机存取表、推栈和杂凑表。在创建阶段，这些信息可以使你对结构
设计有一个比较深刻的理解。在维护阶段，这些信息也是非常宝贵的。如果没有它们，你就会
有一种看一部不带字幕的外国电影的感觉。
不应该允许一个以上的模块访问数据结构，除非是通过访问子程序，以使得这种访问是抽
象的而且是可控的。这将在6.2 “信息隐蔽”部分中详细论述。
如果一个程序使用了数据库，那么结构中应该规定这个数据库的组织形式和内容。
最后，应该遵循数据守恒定律：每一个进入的数据都应该出去，或者与其它数据一道出去，
如果它不出去，那他就没有必要进来。
关键算法
如果结构设计依赖于某一特定算法，那它应该描述或指出这一算法。同主要数据结构一样，
结构设计中也应该指出考虑过的算法方案，并指出选中最终方案的原因。比如，如果系统的主
要部分是排序，而结构设计中又指定了排序方式是堆排序，那它就要说明为什么采用堆排序的
方法，以及未采用快速排序或插入排序的理由。如果是在对数据作出某种假定的基础上才选中
堆排序的，那就该给出这个假定。
主要对象
在面向对象的系统中，结构中应指出要实现的主要对象，它应该规定每一个对象的责任并
指出每个对象之间是如何相互作用的。其中应包括对于排序层次、状态转换和对象一致性的描
述。
结构中还应该指出考虑的其它对象，以及选择这种组织形式的原因。
通用功能
除了特定程序的特定功能，绝大多数程序中都需要几种在软件结构中占有一席之地的通用
功能。
用户界面。有时用户界面在要求定义阶段便已经规定了。如果没有的话，那就应该在结构
设计中作出规定。结构中应该定义命令结构，输入格式和菜单。用户界面的精心结构设计，往

往是一个深受欢迎的软件与被人弃之不用的软件间的主要不同之处。
这部分结构应该是模块化的，这样，当用新的界面代替旧的时，就不致影响到处理和输出
部分。比如，这部分结构应该使得用批处理接口替代交互式界面的工作非常容易。这种能力是
很有用的，特别是在单元测试和子系统测试阶段。
用户界面设计本身就值得写一部专著，但本书并未涉及这一内容。
输入／输出。输入／输出是结构中另一个应引起重视的部分。结构中应规定采用向前看、
向后看还是当前规则的查询方式。同时，还应该指出在哪个层次上检查输入／输出错误，是在
区域层次、记录层次还是在文件层次上。
内存管理。内存管理是结构设计中应该处理的另一个重要部分，结构中应该对正常和极端
情况下所需要的内存作出估计。例如，如果你正在写数据表，那么结构就应估计其中每一个单
元所需的内存。它还应估计正常表格和最大表格所需要的内存。在简单情形下，这种估计应表
明内存在某项功能的实现环境中是正常的。在复杂情况下，可能不得不建立自己的内存管理系
统，如果是这样，那么内存管理程序的设计应和系统其它部分一样，需要认真对待。
字符串存储。在交互式系统中，字符串存储也应在结构设计阶段予以重视。在这种系统中，
往往包含了大量的提示、帮助信息和状态显示。应该估计被字符串所占用的内存。如果程序是
商用的，那么，结构中应该考虑到典型的字符串问题，包括字符串的压缩，不必修改代码即可
保持字符串，以及保证在译成外文时对代码的影响将是最小的。结构设计可以决定字符串的使
用方法，是编码在程序中，还是把它保存在数据结构中。是需要时通过存取子程序调用，还是
把它存在一个源文件中，结构设计应该指明采用哪种方法及其原因。
错误处理
错误处理已成为当代计算机科学中最棘手的问题，没有谁能担负起频繁应付它的负担。有
人估计，程序中有90％的代码是为了应付例外的错误处理或者内务处理而编写的，就是说仅有
10％的代码才是处理正常情况的。既然有如此多的代码是用于错误处理，那么在结构中阐明处
理错误的策略就是十分必要的了。以下是些需要考虑的问题：
· 错误处理是纠正还是仅仅测试错误？如果是纠正错误，程序可以尝试从错误状态下恢
复。如果仅仅是测试，那么程序可以继续运行，就像什么也没有发生一样，或者直接
退出运行。但无论在哪种情况下，都应该提醒用户发现了错误。
· 错误测试是主动的还是被动的？系统可以积极地预防错误，如通过检验用户的输入是
否合法，当然也可以消极地在无法回避它们时才做出反应。例如，用户的一系列输入
产生了溢出，你可以清除，也可以滤除信息。同样，无论哪种方案，都要提醒用户。
· 程序是怎样对付错误的？一旦测试出错误，程序可以立刻抛弃产生错误的数据，也可
以把它当作错误而进入错误处理状态，还可以等到全部处理完毕后再通知用户数据有
误。
· 处理错误信息的约定是什么呢？如果结构设计中没有规定某种策略。那么用户界面在
程序的不同部分就会像迷宫中的通道一样忽东忽西，让人摸不着头脑。为避免出现这
类问题，结构设计中应建立一套处理错误信息的约定。
· 在程序中，应该在哪一个层次上处理错误呢？你可以在发现的地方立即处理，也可以
把它交给一个错误处理子程序去处理，或者交给更高层次的子程序处理。

· 每一个模块检验输入数据合法性的责任级别有多高？是每一模块仅检验它自己的数据，
还是由一级模块来检验整个系统的数据？是否每个层次上的模块都可以假定输入其中
的数据是合法的？
坚固性（Robustness）
坚固性是指在发现错误后，一个系统继续运行的能力。在结构设计中需要从几个方面表述
坚固性。
裕度设计（ over r－engineering g）。在结构设计中应该明确表述所要求的系统裕度有多大。
结构设计中规定的裕度往往比需求定义中规定的要大。一个原因是由于系统是由许多部分组成
的，这会降低其总体坚固性。在软件链条中，其强度不是由最薄弱的一环决定的，而是由所有
薄弱环节的乘积决定的。
清楚地表述所要求的裕度级是非常重要的，这是因为程序员出于职业素养，会不自觉地在
程序中留出裕度。通过清楚地规定裕度级，可以避免某一部分裕度过大，而另一部分又过小的
现象发生。
断言（ assertion s）。结构中还应该规定断言的使用程度。断言是指一段放在代码中，当代
码运行时可以使其自检的可执行语句。如果断言显示出正确信息，那么表明一切都正常运行。
如果显示出错误信息，那么表明它在程序中发现了错误。比如，系统假定用户信息文件永远不
会超过5000 记录行，那么程序中可能会包含一段说明这个假定的断言。只要这个文件不超过
5000，那么断言就保持沉默，而一旦断言发现此文件超过了5000个记录行，那它就会声称已发
现了一个错误。
为了在程序中加入断言，你必须知道在设计系统时所做的假设，这也是在结构设计中应阐
明采用假设的原因之一。
容错性（ fault  tolerance e）。结构设计应指明所期望的容错性类型，容错性是指通过测试
错误、修正错误或在不能修复时容错等一系列方法，来提高系统可靠性的技术。
例如，一个可以采用如下办法来容忍求算术平方根时的错误。
· 系统可以返回并重新开始。如果发现结构有误，系统可以返回到正常的部分并重新开
始。
· 当发现错误时，系统可以用辅助代码来代替基本代码。如果第一个结果看起来是错的，
系统将使用另一个备用求平方根子程序重新计算一遍。
· 系统可以采取投票算法。可以用三种不同的方法算平方根，每一个子程序求一个平方
根，由系统作出比较。根据系统所采用的容错种类，最终结果可能是三者的平均，其
中的中间值就是占优势的那一个值。
· 系统可以用一个假想值来代替错误的结果，以避免对程序其余部分的不良影响。
其它的容错方式包括：在测试出错误后，只让系统部分运行或者系统功能降级，关闭自己
或者自动重新开始等，这些例子是非常简单的。容错性是一个非常诱人而又复杂的学科，但它
也不在本书讨论之列。
性能
如果考虑到性能，那么在性能要求中应该考虑性能目标。性能目标包括速度和内存使用。

结构设计要对这些目标作出估计，并解释为什么这些目标是可以达到的。如果某个域可能
有达不到目标的危险，或者，如果某个域要求使用特定的算法或者数据结构来达到某一目标，
在结构设计中也应指出这点。结构设计还应该规定每一个模块或目标的时间和存储空间预算。
通用的结构设计质量准则
一个好的结构设计特征包括；对于系统中模块的讨论，每个模块中隐含的信息，选用和不
选用某方案的原因。
这个结构应该是一个近乎完美的整体概念。关于软件工程的最权威的著作<<The Mythical
Man－Month>>，其中心思想便是认为概念完整性是最重要的（Brooks，1975）。一个好的结构
设计应满足这一条，当看到这个结构设计时，应该为其解决方案的自然和简单而折服。而不会
有把问题和答案生拼硬凑到一起的感觉。
你或许知道在开发过程中变动结构设计的途径。每一次变动都应与总体和设计概念相符。
不能使最终完成的结构设计看起来像是一个穿着由各种碎布拼凑起来的百家衣的乞丐。
结构的目标应该清楚地说明。一个以可变性为首要目标的结构设计可能与一个以性能为首
要目标的结构设计差之千里，虽然二者的功能可能是完全一样的。
结构中作出每一个决定的动机都要阐明清楚。要当心“我们过去一直是这么干的”的理由。
有这样一个故事，会给我们启迪。Beth 想按照她丈夫的家传方法做一道红烧牛肉。她的丈夫
Abdul 告诉她，要先把牛肉放在盐和调料中胞一下，再剁掉肉的两边，把中间部分放进锅里，
盖上盖儿焖一下就可以了。Beth 问：“为什么要剁掉肉的两边？”Abdul 说：“我不知道，我总
是这样做的，我们问一下妈妈吧”。便打电话问妈妈、Abdul的妈妈则说是他的外祖母告诉她的。
于是电话打到了Abdul的外祖母那儿，她的外祖母奇怪地说：“我也不知道你们为什么那样做，
我那样做不过是因为肉块太大，放不进锅里”。
好的软件结构往往是机器和语言相互独立。当然，我们不能忽略系统的实现环境。然而，
通过尽量减少对实现环境的依赖性，你可以避免过分地结构化系统，并且使你可以在创建阶段
把工作做得更好。但如果程序专门是为某一机型或语言设计的，那么本条不适合。
结构设计应该恰好在过分定义和定义不足的分界线上。结构中不应该有任何部分受到了它
不应受的重视。设计者不能以牺牲某一部分为代价来重视另一部分。
最后，结构中不应该有任何部分让你感到不舒服。它不应该含有任何仅仅为取悦老板而加
上去的部分。你是最终实现它的人，如果你根本读不懂它，又谈何实现呢？
3.4.2 检查表
结构设计
一个好的结构设计应该阐明所有问题。这个表并不是用于指导结构设计的，而只是想提供
一种方法，通过它，你可以估计处于软件食物链顶层的程序员可以从食物中获得多少营养。它
可以作为建立自己的检查表的起点。同要求定义检查表的使用一样，如果你正在从事一个非正
式的项目，那么其中有些条款是不必考虑的。但如果你正在开发一个较大的系统，那绝大部分
内容都是非常有用的。
· 软件的总体组织形式是否清晰明了？包括对于结构设计的总体评论与描述。
· 模块定义是否清楚？包括它们的功能及其与其它模块的接口。

· 要求定义中所提出的所有功能，是否有恰当数量的模块覆盖？
· 结构设计是否考虑了可能的更改？
· 是否包括了必要的购买？
· 是否阐明了如何改进重新启用的代码来满足现在的结构设计要求？
· 是否描述并验证了所有主要的数据结构？
· 主要数据结构是否隐含在存取子程序中？
· 规定数据库组织形式和其它内容了吗？
· 是否说明并验证所有关键算法？
· 是否说明验证所有主要目标？
· 说明处理用户输入的策略了吗？
· 说明并验证处理输入／输出的策略了吗？
· 是否定义了用户界面的关键方面？
· 用户界面是否进行了模块化，以使对它所作的改动不会影响程序其它部分
· 是否描述并验证了内存使用估算和内存管理？
· 是否对每一模块给出了存储空间和速度限制？
· 是否说明了字符串处理策略？是否提供了对字符串占用空间的估计？
· 所提供的错误处理策略是不是一致的？
· 是否对错误信息进行了成套化管理以提供一个整洁的用户界面？
· 是否指定了坚固性级别？
· 有没有哪一部分结构设计被过分定义或缺少定义了？它是否明确说明了；
· 是否明确提出了系统目标？
· 整个结构在概念上是否是一致的？
· 机器和使用实现的语言是否顶层设计依赖？
· 给出做出每个重要决定的动机了吗？
· 你作为系统实现者的程序员，对结构设计满意吗？
3.5  选择编程语言先决条件
实现系统的语言对你来说是有重大意义的，因为从创建工作开始到结束你都要沉浸其中。
研究表明，程序语言选择可以通过几方面影响生产率和编码质量。
当程序员使用自己所熟悉的语言时，其工作效率要比使用陌生的语言高得多。TRW 公司的
数据表明，两个水平和经验相当的程序员如果一个用一种他已用了三年的语言编程，而另一个
则用一种他所陌生的语言编程，那么前者的效率要比后者高30％。IBM的调查表明，一个在某
种语言上经验丰富的程序员，其效率要比在这种语言上没什么经验的程序员高三倍（Walston
和Felix 1977）。
使用高级语言编程，其效率和质量要比使用低级语言高得多。Pascal 和Ada 语言的效率、
可靠性、简单性和可懂性是低级语言，如汇编和机器语言的5 倍（Brooks 1987）。由于不必每
次都为机器正确地执行了指令而欢呼，你当然可以节省许多时间。同时，高级语言的表达能力

比低级语言要高，这样，它的每一行代码就可以表达更多的内容。表3－2给出了在代码量相同
的信况下，高级语言所表达的原指令与低级语言的比值（以汇编语言为代表）。
表3-2  高级语言指令与低级语言指令比
语言比值
                  汇编语言                                  1：l
                      Ada                                      l：4.5
                      Quick／Turbo Basic                        l：5
                      C                                        1：2.5
Fotran                                    1：3               
Pascal                                    l：3.5
IBM公司的数据从另一个方面指出了语言特性是如何影响效率的，用解释语言工作的程序
员往往比用编译语言工作的程序员的效率更高（Jones 1986）。许多种语言都有解释和编译两种
形式（如多种版本的c语言），你可以用高效率的解释形式，然后再把它们转换成更容易执行的
编译形式。
一些语言比其它语言更擅长解释编程思想。你可以把自然语言（如英语）和程序语言（如
Pascal和汇编语言）进行对比。在自然语言中，语言学家Sapir和Whorf提出的假想指出，在一
种语言的表达能力和其所能思考的问题之间存在着联系，你思考某一问题的能力取决于你所懂
得的关于这一问题的词汇。如果你不懂那些词汇，那你也就不能表达那些思想，你甚至根本无
法形成那些思想。
程序员也可能同样受到他所懂得的程序语言限制。在某种程序语言方面你所懂得的词汇，
当然会决定你如何表达你的编程想法，还很可能决定你将表达什么样的思想。
程序语言影响程序员的思想方法。一个典型的故事是这样说的：“我们正用Pascal语言开发
一个新的系统，而我们的程序员们却并不熟悉Pascal语言，他们都是搞Fortran语言出身的。结
果他们写出的是用Pascal 编译的代码，但是他们真正使用的却是变形的Fotran 语言。他们用
Fortran 的不好的特性（goto语句和全局数据）歪曲了Pascal语言，而同时又把Pascal丰富的控
制和数据结构弃之不用”。这种现象在整个软件业都有报道（Hanson 1984，Yourdon 1986）。
3.5.1 语言描述
某些语言的发展史同其通用功能一样令人感兴趣。以下是关于一些在本书中所举的例程
中所出现的语言的描述。
Ad a 语言
是一种在Pascal 语言基础上发展的通用高级语言，它是在国防部的要求和资助下发展起来
的，特别适用于实时和嵌入式系统。Ada强调数据抽象和信息隐蔽，迫使你区分模块的
公共和局部部分。
把这种语言命名为“Ada”是为了纪念数学家Ada lovelace，他被公认为世界上的第一个程
序员，从1986 年起，北约组织和国防部的所有关键任务嵌入式系统都采用Ada语言。

汇编语言
汇编语言，是一种低级语言，每一条语句都与一条机器指令相对应。由于语句使用特定的
机器指令，所以汇编语言是针对特定处理器的，比如Intel 80x86 或者Motorala 680x0。汇编是
第二代计算机语言，除非是执行速度或代码空间的需要，绝大多数程序员都避免使用它。
Basic 语言
Basic 是由Dartmouth 学院的John Kemeny和Thormas Kurtz 开发的一种高级语言。由字首
组成的BASIC 的意思是初学者的全功能符号指令代码（Beginner’ s All-Purpos Symbolic
Instruction Code），Basic主要用于教学生们编程。由于IBM－PC 机包含了它而使其在微机中风
行一时，Basic原来是一种解释性语言，现在则解释性和编译性两种形式都有。
C 语言
C 是一种中级通用语言，本来是和UNIX 操作系统相关的。C 有某些高级语言的特点，例
如，结构化数据、结构化控制流、对于机器的独立性、丰富的操作指令等。它也被称作“可移
植的汇编语言”，因为它广泛地使用了指针和地址，具有某些低级组成部分，如位操作，而且是
弱类型的。
C 是在七十年代由贝尔实验室Dennis Ritchie 开发的。C本来是为DEC PDP－11 设计的，
它的操作系统、C编译器和UNIX 应用程序都是用C 编写的。1988 年，ANSI公布了C的编码
标准，这成了微机和工作站编程的通用标准。
C++语言
C＋＋，是一种面向对象的语言，与C 相似，由贝尔实验室的Bjarne stroustruP 于1980 年
开发，除了与C 兼容之外，C＋十提供了多形性和函数名称过载功能，同时，它还提供了比C
更坚固的类型检查功能。
Fortran 语言
Fortran 是一种高级语言，引入变量和高级循环的概念。Fortran 代表Formula Translation，
即公式翻译的意思。Fortran 最初是在五十年代由Jim Bckus开发，并且做过几次重大修订．包
括1977 所发表的Fotran－77，其中增加了块结构化的IF－THEN－ELSE 语句和字符串操作。
Fortran－90 增加由用户定义的数据类型、指针、模块和丰富的数组操作。在写本书的时候（1992
年末）。Fortran 标准是如此引发争议，以致绝大多数语言商都没能最终完成它。本书中所引用
的是Fortran－77 标准。Fortran 语言主要在科学和工程计算中使用。
Pascal 语言
Pascal 是为了教学目的而开发的高级语言。其主要特征是严格的类型、结构化控制创建和
结构化数据类型。它是在六十年代末由Niklaus Wirth 开发，到了1984 年，由于Borland 国际
公司引入了微机使用的低成本编译程序，Pascal就流行起来了。