欢迎光临
专注android技术,聚焦行业精粹,我们一直在努力

架构学习2——架构设计演化史

1、前言

通过前面一篇《架构学习之——架构的概念和定义》我们理解了架构的有关概念和定义。接下来为了更好的了解架构的本质,以及洞察它未来可能的发展趋势,最好的方法是去了解它出现的历史背景和推动因素。

本篇文章会从软件开发的进化史,去探索架构设计出现的原因,它所解决的问题,以及未来可能的方向。

以下是本篇文章的关键内容:

 

2、概览图

1940之前

机器语言:直接使用二进制码0和1来表示机器可识别的指令和数据。(输出一个”hello world”,要面对几十上百行0/1串)
问题:太难写、太难读、太难改

1940s

汇编语言的主体是汇编指令。汇编指令和机器指令的差别在于指令的表示方法上,汇编指令是机器指令便于记忆的书写格式

比如下面将寄存器 BX 的内容发送到 AX 上:

我们能很明显的从上面两条指令看出区别,汇编指令相对于机器指令是很容易记住的。

问题:

  1. 汇编语言指令是机器指令的一种符号表示,而不同类型的CPU 有不同的机器指令系统,也就有不同的汇编语言,所以,汇编语言程序与机器有着密切的关系。所以,除了同系列、不同型号CPU 之间的汇编语言程序有一定程度的可移植性之外,其它不同类型(如:小型机和微机等)CPU 之间的汇编语言程序是无法移植的
  2. 本质上还是面向机器编程,依赖于硬件体系,且助记符量大难记。(需要精确了解计算机底层知识,例如,CPU指令、寄存器、段地址等底层的细节)。

1950s

高级语言:高级语言并不是特指的某一种具体的语言,是相对于汇编语言而言的,它是较接近自然语言和数学公式的编程。高级语言与计算机的硬件结构及指令系统无关,有更强的表达能力,可方便地表示数据的运算和程序的控制结构,能更好的描述各种算法。
最初的高级语言有Fortran[2]LISP[3]Cobol[4],并且这些语言至今还在特定的领域继续使用。

特点:

  1. 基本脱离了机器的硬件系统,不需要关注底层结构和逻辑,只许关注具体的问题和业务。
  2. 通过编译程序高级语言可以被编译为适合不同CPU指令的机器语言。

1960s~1970s

20世纪60年代中期爆发了第一次软件危机[5]
根源:软件“逻辑”复杂
表现:软件质量低下、项目无法如期完成、项目严重超支,因软件而导致的重大事故时有发生。
典型案例:

  1. 1963年美国水手一号火箭发射失败事故(因为一行Fortran代码错误导致)。
  2. IBM System/360操作系统开发——佛瑞德·布鲁克斯[6](Frederick P. Brooks, Jr.)作为项目主管,率领 2000 多个程序员夜以继日地工作,共计花费了 5000 人一年的工作量,写出将近 100 万行的源码,总共投入 5 亿美元,是美国的“曼哈顿”原子弹计划投入的 1/4。尽管投入如此巨大,但项目进度却一再延迟,软件质量也得不到保障。

软件设计阶段出现在1956年~1970年。此阶段的特点是:硬件环境相对稳定,出现了“软件作坊”的开发组织形式。开始广泛使用产品软件(可购买),从而建立了软件的概念。随着计算机技术的发展和计算机应用的日益普及,软件系统的规模越来越庞大,高级编程语言层出不穷,应用领域不断拓宽,开发者和用户有了明确的分工,社会对软件的需求量剧增。但软件开发技术没有重大突破,软件产品的质量不高,生产效率低下,从而导致了“软件危机”的产生。

为了解决这个问题,在1968、1969年连续召开两次著名的NATO会议,会议正式创造了“软件危机”一词,并提出了针对性的解决方法“软件工程”。

1970s

自1970年起,软件开发进入了软件工程阶段。由于“软件危机”的产生,迫使人们不得不研究、改变软件开发的技术手段和管理方法。从此软件产生进入了软件工程时代。差不多同一时间,“结构化程序设计”作为另外一种解决软件危机的方案被提出来。艾兹赫尔.戴克斯特拉(Edsger Dijkstra)于1968年发表了著名的《GOTO有害论》论文,引起了长达数年的论战,并由此产生了结构化程序设计方法。同时,第一个结构化的程序语言Pascal也在此时产生,并迅速流行起来。

特点:抛弃goto语句,采取“自顶向下、逐步细化、模块化”的指导思想,将软件复杂度控制在一定范围内,从整体上降低软件开发的复杂度。

1980s

第二次软件危机爆发,促进了面向对象的发展[8]

根源:软件“扩展”复杂

表现:业务需求越发复杂,编程应用领域越发广泛,软件生产力远远跟不上硬件和业务的发展

结构化编程的风靡在一定程度上缓解了软件危机,然而随着硬件的快速发展,业务需要越来越复杂,以及编程应用领域越来越广泛,第二次软件危机很快就到来了。

第二次软件危机的根本原因还是在于软件生产力远远跟不上硬件和业务的发展。第一次软件危机的根源在于软件的“逻辑”变得非常复杂,而第二次软件危机主要体现在软件的“扩展”变得非常复杂。结构化程序设计虽然能够缓解软件逻辑的复杂性,但是对于业务变化带来的软件扩展却无能为力,在这种背景下,面向对象的思想开始流行起来。

面向对象的分析根据抽象关键的问题域来分解系统。面向对象的设计是一种提供符号设计系统的面向对象的实现过程,它用非常接近实际领域术语的方法把系统构造成“现实世界”的对象。面向对象程序设计可以看作一种在程序中包含各种独立而又互相调用的对象的思想,这与传统的思想刚好相反:传统的程序设计主张将程序看作一系列函数的集合,或者直接就是一系列对电脑下达的指令。面向对象程序设计中的每一个对象都应该能够接受数据、处理数据并将数据传达给其它对象,因此它们都可以被看作一个小型的“机器”,即对象。

1990s

软件架构开始真正流行[9]
与之前的各种新方法或者新理念不同的是,“软件架构”出现的背景并不是整个行业都面临类似相同的问题,“软件架构”也不是为了解决新的软件危机而产生的,这是怎么回事呢?

卡内基·梅隆大学的玛丽·肖(Mary Shaw)和戴维·加兰(David Garlan)对软件架构做了很多研究,他们在 1994 年的一篇文章《软件架构介绍》(An Introduction to Software Architecture)中写到:

When systems are constructed from many components, the organization of the overall system-the software architecture-presents a new set of design problems.

简单翻译一下:随着软件系统规模的增加,计算相关的算法和数据结构不再构成主要的设计问题;当系统由许多部分组成时,整个系统的组织,也就是所说的“软件架构”,导致了一系列新的设计问题。

这段话很好地解释了“软件架构”为何先在 Rational 或者 Microsoft 这样的大公司开始逐步流行起来。因为只有大公司开发的软件系统才具备较大规模,而只有规模较大的软件系统才会面临软件架构相关的问题,例如:

  1. 系统规模庞大,内部耦合严重,开发效率低;
  2. 系统耦合严重,牵一发动全身,后续修改和扩展困难;
  3. 系统逻辑复杂,容易出问题,出问题后很难排查和修复。

3、总结

纵观软件开发的进化史,软件架构的出现有其历史必然性。从20世纪60年代第一次软件危机引出的“结构化编程”,创造了模块的概念;到20世纪80年代第二次软件危机引出了“面向对象编程”,创造了对象的概念;再到20世纪90年代“软件架构”开始流行,创造了“组件”的概念。可以看得出来随着软件涉及到的领域越来越广,软件规模越来越大,在软件设计时拆分的粒度也越来越大,拆分的层次也越来越高。也就是说软件架构是为了解决系统复杂度而生的,随着系统复杂度不断的增加,我们的软件架构设计拆分的层次也越来越高。

引用一张图可以形象的描述这个过程:

4、“架构设计”已经是银弹了?

没有银弹:软件工程的本质性与附属性工作》(英语:No Silver Bullet—Essence and Accidents of Software Engineering)是IBM大型机之父佛瑞德·布鲁克斯所发表一篇关于软件工程的经典论文,他们用了几张《伦敦狼人》之类的电影剧照来当作说明,还加上了一段〈终结狼人〉的附注,用来引出非银弹则不能成功的(现代)传说。该论述中强调由于软件的复杂性本质,而使真正的银弹并不存在;所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。

赞(0) 打赏
未经允许不得转载:花花鞋 » 架构学习2——架构设计演化史
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

国内精品Android技术社区

联系我们

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏