《基于模型的软件开发》——1.1 历史

1.1 历史

20世纪50年代基本上不存在系统化的开发,那是编程的“黑暗时代”。现在的开发人员几乎很难想象当时的软件开发环境。当时大型主机的内存只有几KB(kilobyte,千字节),纸带就是高科技输入系统。西联曾经有效垄断了电传输入设备,该设备每按下一个键都需要做几英尺-磅的功,这些设备导致程序员患上腕管综合征,该症状甚至成了医学界的一个专有名词。没有浏览器、调试器或者CRT终端。基本汇编语言(Basic Assembly Language,BAL)是解决软件危机的银弹。
20世纪50年代末60年代初,更好的工具以更高级别计算机语言的形式出现,将0和1抽象为符号名、更高层次的操作、块结构,并且将结构抽象为记录和数组。这时的开发工作更加轻松,开发人员的生产力更高,但是关于如何正确使用这些技术没有指导。因此这种复兴催生了“黑客时代”,一个个人生产力占统治地位的时代。
黑客时代从20世纪60年代初直至70年代中。这一时期的特点就是由非常聪明的人生产大量的代码,每年10万行的FORTRAN代码产量并非不常见。开发人员必须非常聪明,因为他们花费大量的时间来调试程序,他们要精于此道才能使代码快速交付。对于问题,他们常有天才的解决方案。在20世纪60年代,黑客一词是很有赞赏意味的。它用于描述那些可以生产大量代码完成出色工作,并使其能够保持运行的人。
然而,在20世纪70年代末期,蜜月结束了。黑客变成了一个具有贬义的称谓。因为黑客们开始进行新的项目开发,将之前他们所编写的代码交由其他人维护。随着时间的推移,当更多特定应用出现时,这些代码往往不能正常工作。世界发生了改变,程序也需要随之提高。通常重写这些黑客代码比修复它还要简单一些。此时,人们才发现这些代码在“某些”方面错了。在行业的说明中,“可维护性”这一名词出现了,那些不可维护的代码此时被称为“黑客代码”。
20世纪60年代末的解决方案是一种更加系统化的方法,将之前获得的那些多种多样的宝贵教训组合成方法用于构建软件。同时,随着程序变得越来越大,需要为之设计结构的想法出现了。“软件设计”作为一项活动从软件编程中独立了出来。在黑客时代末期出现的方法将所获得的各类教训组合在一起产生协同效益,使整体大于部分的总和。这些方法都在结构化开发的涵盖之下。
从20世纪80年代开始,软件产业的各个方面都有了巨大的进步。OO范式是一种特别规范的分析与设计方法,带来了层出不穷的革新。

时间: 2024-11-15 00:44:27

《基于模型的软件开发》——1.1 历史的相关文章

《基于模型的软件开发》——第1章 历史的视角

第1章 历史的视角 问题是进步的代价.--Charles F.?Kettering和物理科学.工业革命相比,软件开发在人类发展史上相对较新.成为现代生活中无处不在的角色,物理科学花了一千多年.工业革命花了一个多世纪,而计算机和软件只花了30年不到的时间.当然,这中间走过的路是很艰辛的.本章提供了OO范式产生的历史背景.为了全面理解并评价这种范式,首先要了解它要解决的问题.因此我们从历史讲起,然后回顾一下在OO范式出现之前主流的软件开发方法存在的一些弱点,最后考察一些被OO范式采纳的重要技术进步,

《基于模型的软件开发》——导读

前言 软件开发是一项极其复杂的智力活动,它是一门朝气蓬勃并且仍在迅速发展的学科.软件开发还不够完善,因此迄今人们仍然在试图找出开发软件的好方法. 尽管如此,多年来软件开发方法仍然获得了大幅提升.许多设计方法学不断发展以促进软件设计的各个方面.其中之一是结构化设计方法,该方法提供了一种非常直观的方式,用以很好地匹配图灵和冯·诺依曼的硬件计算模型. 尽管结构化设计明显优于它之前的特定方法,但它存在着一个致命的弱点:当用户需求随着时间的推移改变时,软件往往很难随之修改,大型的应用尤其如此.与此同时,应

《基于模型的软件开发》——1.4 技术革新

1.4 技术革新 在OO范式之前,即使是编程的"黑暗时代",也并非一片混沌.学术界一直致力于调整数学运算使其能够应用于计算环境下的实践.经过认真思考,学术界提供了一种数学通用语言作为软件开发的基础.这是一个特别适用于计算环境的理论和模型集合.今天这些数学运算仍然是软件开发时一切工作的基础. 本书的重点为软件开发的工程方法,因此不会涉及很多理论.然而,主要的相关数学元素以及它们对软件开发的影响很值得用几个小节高屋建瓴地描述.因为这些理论现在仍然存在于OO范式背后,尽管是以一种非常隐秘的方

《基于模型的软件开发》——2.1 基本理念

2.1 基本理念 OO范式较之以前的软件开发方法更加复杂精密.从硬件计算的角度我们并没有直观感受,因此需要一种独特的思想.该范式也是由很多不同的.独立的概念整合而成.在这里我们将明确这些与第二部分和第三部分密切相关的基本概念.2.1.1 可维护性 在20世纪70年代,关于软件开发的实证研究很多,从中可以归纳出以下两个惊人的结论: 大部分软件公司70%的工作量用于维护. 用于修正现有特性的工作量是最初开发工作量用的5-10倍. 这中间显然存在问题.20世纪70年代后期这一现象演变成了软件危机,软件

《基于模型的软件开发》——2.2 广度优先处理(又称对等协作)

2.2 广度优先处理(又称对等协作) 第1章讨论了SD的深度优先,分层的功能分解以及与此相关的问题.这次同样是对象的问题.由于抽象.封装和逻辑不可分性,对象具有自包含实现,因此它们允许广度优先通信.这是因为你让对象做什么它就做什么,并能够完成,这完全依赖于它的逻辑不可分性和自包含性. 从客户角度看它是原子的,一个对象就是单个可标识的实体.因此,应用中重要的控制流是按照对象的交互(OO中的协作)进行描述的.这在一定程度上大大提高了控制流的抽象层次.事实上,在本书后面的章节中你将看到,当定义协作时,

《基于模型的软件开发》——第1部分 面向对象开发的根本

第1部分 面向对象开发的根本 基于模型的软件开发方法本质上是一种面向对象的方法.因此,为了充分了解这种方法,有必要大致理解面向对象的开发.由于面向对象的方法不如传统软件开发方法那样直观,因此我们需要理解面向对象方法的工作方式.本书这一部分着眼于面向对象方法诞生的历史背景,使我们能够了解传统方法存在的问题,也即面向对象的方法寻求解决的问题.

《基于模型的软件开发》——1.3 宝贵教训

1.3 宝贵教训 当20世纪70年代末学术界开始对对象思想反思的时候,很多蹩脚的软件已经开发出来了,多到这些蹩脚软件中存在的通用模式已经非常明显了.很多论文和文档由此而来,例如1968年Dijkstra的经典文档:"Go To Statement Considered Harmful".这些模式代表了从软件开发中获得的惨痛教训(其中有一些是刚刚触及).1.3.1 全局数据持久状态变量用于记录系统的状态,当它们为全局可访问的时候经常会在意想不到的时间或者以意想不到的方式被修改,这是一个很

《基于模型的软件开发》——1.2 结构化开发

1.2 结构化开发 结构化开发无疑是20世纪80年代之前最重要的单个技术进步之一.它第一次为软件开发提供了真正意义上的系统化方法.与20世纪60年代的3GL结合,结构化开发能够使生产力取得重大进步.结构化开发具有一种很有趣的边界效益,这在当时未被注意到.应用更加可靠,当时人们没有留意这一点,因为软件应用得越来越广泛,对非软件的用户的可见性越来越高:软件依然存在很多缺陷,用户仍然认为软件是不可靠的.事实上,可靠性从20世纪60年代初的150个缺陷/千行降低到了20世纪80年代的15个缺陷/千行.结

《基于模型的软件开发》——3.4 泛型

3.4 泛型 泛型是我们都在实际使用但却没有意识到自己在使用的一种方法.泛型通过参数化替代不同的行为.从本质上讲,我们所获得的不同结果,取决于单个行为职责的输入参数值--这种想法在"汇编宏"方法使用时就已经存在了,因此我们在此不多做讨论.实际上,它的另外一个名字--参数多态,表明它是多态的一种特例. 任何具有以下特征的方法都可以在技术上视为泛型的实例,在这些方法中,不同的行为依赖于该方法的参数值.因此,任何一个对参数值进行if判断的方法都可以视为泛型的实例.然而,大部分OO人员通常从存