02 - 架构设计的历史背景.docx

上传人:ylj18****70940 文档编号:62492170 上传时间:2022-11-22 格式:DOCX 页数:10 大小:16.36KB
返回 下载 相关 举报
02 - 架构设计的历史背景.docx_第1页
第1页 / 共10页
02 - 架构设计的历史背景.docx_第2页
第2页 / 共10页
点击查看更多>>
资源描述

《02 - 架构设计的历史背景.docx》由会员分享,可在线阅读,更多相关《02 - 架构设计的历史背景.docx(10页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、02 | 架构设计的历史背景 理解了架构的有关概念和定义之后,今日,我会给你讲讲架构设计的历史背景。我认为,假如想要深化理解一个事物的本质,最好的方式就是去追寻这个事物出现的历史背景和推动因素。我们先来简洁梳理一下软件开发进化的历史,探究一下软件架构出现的历史背景。 机器语言(1940 年之前) 最早的软件开发运用的是机器语言,干脆运用二进制码 0 和 1 来表示机器可以识别的指令和数据。例如,在 8086 机器上完成s=768+12288-1280的数学运算,机器码如下: 101100000000000000000011 000001010000000000110000 0010110100

2、00000000000101 复制代码 不用多说,不管是当时的程序员,还是现在的程序员,第一眼看到这样一串东西时,确定是一头雾水,因为这实在是太难看懂了,这还只是一行运算,假如要输出一个hello world,面对几十上百行这样的 0/1 串,眼睛都要花了! 看都没法看,更何况去写这样的程序,假如不当心哪个地方敲错了,将 1 敲成了 0,例如: 101100000000000000000011 000001010000000000110000 001011000000000000000101 复制代码 假如要找出这个程序中的错误,程序员的心里阴影面积有多大? 归纳一下,机器语言的主要问题是三难

3、:太难写、太难读、太难改! 汇编语言(20 世纪 40 年头) 为了解决机器语言编写、阅读、修改困难的问题,汇编语言应运而生。汇编语言又叫符号语言,用助记符代替机器指令的操作码,用地址符号(Symbol)或标号(Label)代替指令或操作数的地址。 例如,为了完成将寄存器 BX 的内容送到 AX 中的简洁操作,汇编语言和机器语言分别如下。 机器语言:1000100111011000 汇编语言:mov ax,bx 复制代码 相比机器语言来说,汇编语言就清楚得多了。mov 是操作,ax 和 bx 是寄存器代号,mov ax,bx 语句基本上就是将寄存器 BX 的内容送到 AX的简化版的翻译,即使不

4、懂汇编,单纯看到这样一串语言,至少也能明白也许意思。 汇编语言虽然解决了机器语言读写困难的问题,但本质上还是面对机器的,因为写汇编语言须要我们精确了解计算机底层的学问。例如,CPU 指令、寄存器、段地址等底层的细微环节。这对于程序员来说同样很困难,因为程序员须要将现实世界中的问题和需求根据机器的逻辑进行翻译。例如,对于程序员来说,在现实世界中面对的问题是 4 + 6 = ?。而要用汇编语言实现一个简洁的加法运算,代码如下: .section .data a: .int 10 b: .int 20 format: .asciz "%dn" .section .text .gl

5、obal _start _start: movl a, %edx addl b, %edx pushl %edx pushl $format call printf movl $0, (%esp) call exit 复制代码 这还只是实现一个简洁的加法运算所须要的汇编程序,可以想象一下,实现一个四则运算的程序会更加困难,更不用说用汇编写一个操作系统了! 除了编写本身困难,还有另外一个困难的地方在于:不同 CPU 的汇编指令和结构是不同的。例如,Intel 的 CPU 和 Motorola 的 CPU 指令不同,同样一个程序,为 Intel 的 CPU 写一次,还要为 Motorola 的 C

6、PU 再写一次,而且指令完全不同。 高级语言(20 世纪 50 年头) 为了解决汇编语言的问题,计算机前辈们从 20 世纪 50 年头起先又设计了多个高级语言,最初的高级语言有下面几个,并且这些语言至今还在特定的领域接着运用。 Fortran:1955 年,名称取自FORmula TRANslator,即公式翻译器,由约翰·巴科斯(John Backus)等人独创。 LISP:1958 年,名称取自LISt Processor,即枚举处理器,由约翰·麦卡锡(John McCarthy)等人独创。 Cobol:1959 年,名称取自Common Business Or

7、iented Language,即通用商业导向语言,由葛丽丝·霍普(Grace Hopper)独创。 为什么称这些语言为高级语言呢?缘由在于这些语言让程序员不须要关注机器底层的低级结构和逻辑,而只要关注详细的问题和业务即可。 还是以 4 + 6=?这个加法为例,假如用 LISP 语言实现,只须要简洁一行代码即可: (+ 4 6) 复制代码 除此以外,通过编译程序的处理,高级语言可以被编译为适合不同 CPU 指令的机器语言。程序员只要写一次程序,就可以在多个不同的机器上编译运行,无须依据不同的机器指令重写整个程序。 第一次软件危机与结构化程序设计(20 世纪 60 年头20 世纪

8、70 年头) 高级语言的出现,解放了程序员,但好景不长,随着软件的规模和困难度的大大增加,20 世纪 60 年头中期起先爆发了第一次软件危机,典型表现有软件质量低下、项目无法如期完成、项目严峻超支等,因为软件而导致的重大事故时有发生。例如,1963 年美国(http:/en.wikipedia.org/wiki/Mariner_1)的水手一号火箭放射失败事故,就是因为一行 FORTRAN 代码错误导致的。 软件危机最典型的例子莫过于 IBM 的 System/360 的操作系统开发。佛瑞德·布鲁克斯(Frederick P. Brooks, Jr.)作为项目主管,率领 2000

9、多个程序员夜以继日地工作,共计花费了 5000 人一年的工作量,写出将近 100 万行的源码,总共投入 5 亿美元,是美国的曼哈顿原子弹安排投入的 1/4。尽管投入如此巨大,但项目进度却一再延迟,软件质量也得不到保障。布鲁克斯后来基于这个项目阅历而总结的人月神话一书,成了畅销的软件工程书籍。 为了解决问题,在 1968、1969 年连续召开两次闻名的 NATO 会议,会议正式创建了软件危机一词,并提出了针对性的解决方法软件工程。虽然软件工程提出之后也曾被视为软件领域的银弹,但后来事实证明,软件工程同样无法根除软件危机,只能在肯定程度上缓解软件危机。 差不多同一时间,结构化程序设计作为另外一种解

10、决软件危机的方案被提了出来。艾兹赫尔·戴克斯特拉(Edsger Dijkstra)于 1968 年发表了闻名的GOTO 有害论论文,引起了长达数年的论战,并由此产生了结构化程序设计方法。同时,第一个结构化的程序语言 Pascal 也在此时诞生,并快速流行起来。 结构化程序设计的主要特点是抛弃 goto 语句,实行自顶向下、逐步细化、模块化的指导思想。结构化程序设计本质上还是一种面对过程的设计思想,但通过自顶向下、逐步细化、模块化的方法,将软件的困难度限制在肯定范围内,从而从整体上降低了软件开发的困难度。结构化程序方法成为了 20 世纪 70 年头软件开发的潮流。 其次次软件危机与

11、面对对象(20 世纪 80 年头) 结构化编程的风靡在肯定程度上缓解了软件危机,然而随着硬件的快速发展,业务需求越来越困难,以及编程应用领域越来越广泛,其次次软件危机很快就到来了。 其次次软件危机的根本缘由还是在于软件生产力远远跟不上硬件和业务的发展。第一次软件危机的根源在于软件的逻辑变得特别困难,而其次次软件危机主要体现在软件的扩展变得特别困难。结构化程序设计虽然能够解决(或许用缓解更合适)软件逻辑的困难性,但是对于业务改变带来的软件扩展却无能为力,软件领域迫切希望找到新的银弹来解决软件危机,在这种背景下,面对对象的思想起先流行起来。 面对对象的思想并不是在其次次软件危机后才出现的,早在 1

12、967 年的 Simula 语言中就起先提出来了,但其次次软件危机促进了面对对象的发展。面对对象真正起先流行是在 20 世纪 80 年头,主要得益于 C+ 的功劳,后来的 Java、C# 把面对对象推向了新的高峰。到现在为止,面对对象已经成为了主流的开发思想。 虽然面对对象起先也被当作解决软件危机的银弹,但事实证明,和软件工程一样,面对对象也不是银弹,而只是一种新的软件方法而已。 软件架构的历史背景 虽然早在 20 世纪 60 年头,戴克斯特拉这位上古大神就已经涉及软件架构这个概念了,但软件架构真正流行却是从 20 世纪 90 年头起先的,由于在 Rational 和 Microsoft 内部

13、的相关活动,软件架构的概念起先越来越流行了。 与之前的各种新方法或者新理念不同的是,软件架构出现的背景并不是整个行业都面临类似相同的问题,软件架构也不是为了解决新的软件危机而产生的,这是怎么回事呢? 卡内基·梅隆高校的玛丽·肖(Mary Shaw)和戴维·加兰(David Garlan)对软件架构做了许多探讨,他们在 1994 年的一篇文章软件架构介绍(An Introduction to Software Architecture)中写到: When systems are constructed from many components, the

14、organization of the overall system-the software architecture-presents a new set of design problems. 简洁翻译一下:随着软件系统规模的增加,计算相关的算法和数据结构不再构成主要的设计问题;当系统由很多部分组成时,整个系统的组织,也就是所说的软件架构,导致了一系列新的设计问题。 这段话很好地说明了软件架构为何先在 Rational 或者 Microsoft 这样的大公司起先逐步流行起来。因为只有大公司开发的软件系统才具备较大规模,而只有规模较大的软件系统才会面临软件架构相关的问题,例如: 系统规模浩

15、大,内部耦合严峻,开发效率低; 系统耦合严峻,牵一发动全身,后续修改和扩展困难; 系统逻辑困难,简单出问题,出问题后很难排查和修复。 软件架构的出现有其历史必定性。20 世纪 60 年头第一次软件危机引出了结构化编程,创建了模块概念;20 世纪 80 年头其次次软件危机引出了面对对象编程,创建了对象概念;到了 20 世纪 90 年头软件架构起先流行,创建了组件概念。我们可以看到,模块对象组件本质上都是对达到肯定规模的软件进行拆分,差别只是在于随着软件的困难度不断增加,拆分的粒度越来越粗,拆分的层次越来越高。 人月神话中提到的 IBM 360 大型系统,开发时间是 1964 年,那个时候结构化编程都还没有提出来,更不用说软件架构了。假如 IBM 360 系统放在 20 世纪 90 年头开发,不管是质量还是效率、成本,都会比 1964 年起先做要好得多,当然,这样的话我们可能就看不到人月神话了。 小结 今日我为你回顾了软件开发进化的历史,以及软件架构出现的历史背景,从历史发展的角度,希望对你深化了解架构设计的本质有所帮助。 这就是今日的全部内容,留一道思索题给你吧。为何结构化编程、面对对象编程、软件工程、架构设计最终都没有成为软件领域的银弹? 欢迎你把答案写到留言区,和我一起探讨。信任经过深度思索的回答,也会让你对学问的理解更加深刻。(编辑乱入:精彩的留言有机会获得丰厚福利哦!)

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 应用文书 > 工作报告

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知淘文阁网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号© 2020-2023 www.taowenge.com 淘文阁