软件设计与体系结构 1-4-软件工程与软件设计

1软件工程与软件设计第一章2少数聪明人干的事导致的危机在60年代计算机发展初期，程序设计是少数聪明人干的事。他们的智力与技能超群，编写的程序既能控制弱智的计算机，又能让别人看不懂、不会用。那个时期编程就跟捏泥巴一样随心所欲，于是他们很过分地把程序的集合称为软件，以便自己开心或伤心时再把程序捏个面目全非。人们就在这种美滋滋的感觉下热情地编程，结果产生了一堆问题：程序质量低下、错误频出、进度延误、费用剧增......。这些问题导致了“软件危机”。

1968年10月，一群程序员、计算机科学家与工业界人士（“大牛”）聚集一起喝咖啡和啤酒，一边共商对策，他们在德国的南部小城加尔米施（Garmisch）举行了一次在软件历史非常有名的会议，会议由北大西洋公约组织（NATO）的科技委员会出资，会议的名字就叫“软件工程”大会。3会议的主席是德国人鲍尔（Bauer），在“栈”没有被称为栈这个名字前，他给栈取了个很有诗意的名字——酒窖，就是下图中（当年部分参会人员）第一排第二位的这位老头。鲍尔（Bauer）450多年后再阅读这样的会议报告，仍可以学习到很多东西，其中有很多至今毫不过时的至理名言，比如以发明B5000闻名于世的Barton先生的下面这段话是多么的有道理啊！Indesignyouhavetostartattheleveloforganizationofprogramsandmachines,withthedesignofhardwareandsoftwaretogether.软件硬件co-design，永恒的“真理”。Thismustbeinthehandsofoneorafewindividualsandwillrequireakindofgeneralpurposeperson.全能型人才是必须的，但不需要多，只要一个或者几个。Whatdothesepersonsknow?什么是全能型人才呢?Asfarasprogrammingisconcernedtheycanonlyknowwhatthestateoftheartis,whatcanbelearnedfromexistingsystems,theextrapolationsthatpeoplehavemadeonthese,andwhathappensinlanguages,inoperatingsystems,incontrolprograms.知道的要广，要穿透各个层次。Theyarenotexpertprogrammersorexpertsinthingslikesyntaxdirectedcompilers.他们不是呆板的编程语言能手。Theymustbepeoplewhoareinterestedinsynthesizing,extractingessentialsoutofwhathasbeenlearned.他们必须有很强的综合和提炼能力。Onthehardwaresidetheyarenothardwaredesignerseither,buttheyareconcernedaboutputtingtogetherthegrosslogicofmachines.Thesearetheonlypartsofthedesignthatcanbedonebyjustafewpeople.软件危机5目录肆软件设计伍软件体系结构壹软件工程的目标贰软件工程模型叁软件开发的基本策略6软件工程的目标软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。质量是软件需求方最关心的问题，用户即使不图物美价廉，也要求个货真价实。生产率是软件供应方最关心的问题，老板和员工都想用更少的时间挣更多的钱。质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提。如果质量不合格，对供需双方都是坏事情。软件供需双方的代表能在餐桌上谈笑风生，归功于第一线开发人员的辛勤工作。质量与生产率的提高就指望程序员与程序经理。对开发人员而言，如果非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二。7软件工程的主要活动8目录肆软件设计伍软件体系结构壹软件工程的目标贰软件工程模型叁软件开发的基本策略9软件工程模型建议用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，如同工厂的生产线。常见的软件工程模型有：线性模型（图1），渐增式模型（图2），螺旋模型，快速原型模型，形式化描述模型等等。软件工程开发模型10目录肆软件设计伍软件体系结构壹软件工程的目标贰软件工程模型叁软件开发的基本策略11套用固定的模型不是程序员的聪明之举。比如“程序设计”与“测试”之间的关系，习惯上总以为程序设计在先，测试在后，如图1所示。而对于一些复杂的程序，将测试分为同步测试与系统测试更有效，如图2所示。12开发的基本策略1-复用复用就是指“利用现成的东西”，文人称之为“拿来主义”。被复用的对象可以是有形的物体，也可以是无形的成果。将具有一定集成度并可以重复使用的软件组成单元称为构件（SoftwareComponent）。软件复用可以表述为：构造新的软件系统可以不必每次从零做起，直接使用已有的软构件，即可组装（或加以合理修改）成新的系统。软件复用不仅要使自己拿来方便，还要让别人拿去方便，是“拿来拿去主义”。13分而治之是指把一个复杂的问题分解成若干个简单的问题，然后逐个解决。这种朴素的思想来源于人们生活与工作的经验，完全适合于技术领域。开发的基本策略2-分而治之14基于构件的开发15优化——折衷软件的优化是指优化软件的各个质量因素，如提高运行速度，提高对内存资源的利用率，使用户界面更加友好，使三维图形的真实感更强等等。想做好优化工作，首先要让开发人员都有正确的认识:优化工作不是可有可无的事情，而是必须要做的事情。假设我们经过思想教育后，精神抖擞，随时准备为优化工作干上六天七夜。但愿意做并不意味着就能把事情做好。优化工作的复杂之处是很多目标存在千丝万缕的关系，可谓数不清理还乱。当不能够使所有的目标都得到优化时，就需要“折衷”策略。软件中的折衷策略是指通过协调各个质量因素，实现整体质量的最优。软件折衷的重要原则是不能使某一方损失关键的职能，更不可以象“舍鱼而取熊掌”那样抛弃一方。例如3D动画软件的瓶颈通常是速度，但如果为了提高速度而在程序中取消光照明计算，那么场景就会丧失真实感，3D动画也就不再有意义了。16优化——折衷下面让我们用“优化——折衷”的策略解决“鱼和熊掌不可得兼”的难题。问题提出:假设鱼每千克10元，熊掌每千克一万元。有个倔脾气的人只有20元钱，非得要吃上一公斤美妙的“熊掌烧鱼”，怎么办?解决方案：化9元9角9分钱买999克鱼肉，化10元钱买1克熊掌肉，可做一道“熊掌戏鱼”菜。剩下的那一分钱还可建立奖励基金。17目录肆软件设计伍软件体系结构壹软件工程的目标贰软件工程模型叁软件开发的基本策略18什么是软件设计JackW.

Reeves于30年前（1992年），《WhatisSoftwareDesign》中给出了其个人观点——“源代码就是设计”。这一思想将软件工程活动与传统的工程活动区分开来，传统的工程活动中设计过程中产生的仅仅只是设计文档，构建过程完全依赖于设计文档；而软件的设计活动将源代码的编写也包含了进来，其不仅仅只是生产文档。建筑设计行业中，建筑设计图的最终完成标识了设计过程的终结，但是软件设计过程能够用软件设计文档的完成作为其结束标识吗？显然这是一个不可能的答案。需求分析阶段中我们不可能全部得到客户心里真正想要的是什么东西。即使知道客户想要的是什么，同时也得随时准备应付客户不断变化的新的要求。将编码这一阶段包含在软件设计过程中，同时又强调了顶层设计的重要性。软件设计是一个反复的迭代的过程，就目前来讲还看不到“银弹”的希望。软件设计者的难题在于在如此众多的目标之间找到这个平衡点，并且明确知道如何设计能实现这个平衡，既可以让投资者觉得在预算之内，又能让用户相对满意。19什么是软件设计更多的情况是没有经验的设计者不知道是否存在这些平衡点，更不知道如何利用合理的设计及有效的工具来达到平衡。一个优秀的设计者似乎能在听完需求后就立即构想出目标系统的框架，这并不是因为他聪明或者比不知所措的设计者新手多一个脑袋，而是因为他在平时已经了解大量的系统，对各种设计的优缺点、局限性也了然于胸，能够把以前的设计根据需要再次使用。要成为优秀的设计者，了解、掌握、消化、总结前人和自己以前的设计成果是最好的方法，这似乎也是唯一的方法。系统设计也并非没有规律可以遵循，如同幸福的家庭都很相似，不幸的家庭各有各的不幸，人们在实践中发现优秀的系统设计一般在以下几个方面都很出色。组件的独立性。审视自己设计的系统，是否做到了高内聚、低耦合。例外的识别和处理。谁能保证系统使用者都精确按照使用说明书使用？防错和容错。当网络中断、数据库崩溃这样的灾难性事件发生时，系统也跟着崩溃吗？

20软件设计包括“模型”和“规范”两部分模型，是一个软件的骨架，是一个软件之所以是这个软件的核心。模型的粒度可大可小。我们所说的“高内聚、低耦合”指的就是对模型的要求，一个好的模型可以有效地隐藏细节，让开发者易于理解。模型是分层的，可以不断地叠加，基于一个基础的模型去构建上一层的模型，计算机世界就是这样一点点构建出来的。规范，就是限定了什么样的需求应该以怎样的方式去完成。它对于维系软件长期演化至关重要。关于规范，常见的两种问题是：一个项目缺乏显式的、统一的规范；规范不符合软件设计原则。21模型与规范，二者相辅相成，一个项目最初建立起的模型，往往是要符合一定规范的，而规范的制定也有赖于模型。模型与规范22软件设计至关重要的第一步:分离关注点要实现一个真实的系统，就不仅仅要考虑功能性的需求，还要考虑非功能性的需求。也就是说，我们在分解问题的时候，会有很多维度，每一个维度都代表着一个关注点，这就是设计中一个常见的说法，“分离关注点（Separationofconcerns）”最常见的一类问题就是把业务处理和技术实现两个关注点混在了一起。在真实项目中，程序员最常犯的错误就是认为所有问题都是技术问题，总是试图用技术解决所有问题。任何试图用技术去解决其他关注点的问题，只能是陷入“焦油坑”之中，越挣扎，陷得越深。另外一个常见的容易产生混淆的关注点是不同的数据变动方向。不同的数据变动方向还有很多，比如：动静分离，就是把变和不变的内容分开；读写分离，就是把读和写分开；23软件设计至关重要的第一步:分离关注点通过一个Java代码示例来说明“关注点分离”（SeparationofConcerns）的概念，并展示如何将业务逻辑、技术实现以及数据读写等不同关注点分离开来。请阅读“分离关注点.pdf”24分离关注点很重要，一方面，不同的关注点混在一起会带来许多问题；另一方面，分离关注点有助于我们发现不同模块的共性，更好地进行设计。分离关注点，是我们在做设计的时候，需要时时绷起的一根弦。软件设计至关重要的第一步:分离关注点25一个影响软件设计的重要因素:可测试性另一个经常被很多人忽视的因素：可测试性。软件设计要考虑“可测试性”。软件开发要解决的问题是从需求而来。需求包括两大类，第一类是功能性需求，也就是要完成怎样的业务功能；第二类是非功能性需求，是业务功能之外的一些需求。非功能性需求也被分为两大类，一类称为执行质量（Executionqualities），吞吐、延迟、安全就属于这一类，它们都是可以在运行时通过运维手段被观察到的；而另一类称为演化质量（Evolutionqualities），它们内含于一个软件的结构之中，包括可测试性、可维护性、可扩展性等。做设计，其实就是把一个软件拆分成一个一个的小模块。如果不尽可能地保证每个小模块的正确性，而只是从最外围的系统角度去验证系统的正确性，这将会是一个非常困难的过程。26要保证每个小模块的正确性，就要保证每个模块在开发阶段能够测试，而想要每个模块能够测试，在设计过程中，就要保证每个模块是可以测试的，而这就是可测试性。有了可测试性的视角，我们可以把它当作一个衡量标准去看待其他的设计或实践，也可以用它帮助我们理解软件的发展趋势。一个影响软件设计的重要因素:可测试性27请阅读“可测试性.pdf”设计三步走之所以要把模型、接口和实现区分开来，是因为这三者的关注点是不同的，而很多人在讨论所谓的“设计”时，经常会把它们混在一起。如果在讨论的时候连“讨论的内容到底是什么”都没弄清楚，就很难得出一个清晰的结果，就有一种很混乱的感觉，问题就在于他们把不同层面的内容混在了一起。在讨论设计时应该遵循一个顺序，先模型，再接口，最后是实现，了解设计也应如此。在了解设计时，要按层次去了解，因为设计常常是分层的。每当打开一个层次，需要了解它的内部时，还要按照模型、接口和实现的顺序解读这个层次。实际上，当能够一层一层地去理解设计，就像一棵知识树逐渐展开一样，每一个知识节点在展开的时候，都会有下面一级更具体的内容。当头脑中有了这样一棵设计树，也就掌握了整个系统的地图，再有新需求到来时，就不会再盲目地去改代码了。28设计三步走29软件设计如何落地二十年左右的时间，敏捷（agile）软件开发走完了从一小撮人的游戏到软件业内的某种“政治正确”的慢慢征途。真实世界中的软件设计水平，就目前情况而言，并没有发生什么质的提升。大部分实际工作中的代码还是毫无设计，如一盘纠缠在一起的意大利面。SOLID原则也好，设计模式也好，DDD也好，甚至做到cleancode，做好依赖关系管理，抽象都是第一步。但需要承认，抽象和设计，这本身是很困难的。有可能大部分人就不具各抽象思考问题的能力。能不能在工作中教会大家抽象思考呢?很难，少数人可以学会，大部分不行。想在项目中落地，几乎不可能。即便某些有设计的代码合入具体项目，如果没有非常明确的边界和维护的手段，也会很快的腐败，这样的例子太多了。30请阅读“如何进行抽象.pdf”软件设计如何落地当大型软件腐化到大部分人都觉得它应该改造一下了，它的改动成本已经太大了，或者性能恶化的太严重了的时候。这个时候肯定已经不是改造代码，改动架构的好时机了。改动引入故障的巨大风险，几百上千人的编程习惯，捉襟见肘的人力，和不确定的结果都会让这种努力变得艰难而危险。打个比方，肝癌感到疼的时候，已经是晚期了。人应该专注于一个点，专业分工才是效率的源泉。业务团队就应该全心全意的关心业务。可运行、可监控的架构设计就是来支撑这个目标的。架构不应该落在文档和PPT中，编程规范，xxx规范，培训这都不够。架构应该可以约束分析和编码过程，提供合适的目录结构、依赖关系、拆分方式、实现模板、非业务优化方法和某些业务/代码分析工具。这样，才可能从根本上落地软件设计、以及减缓代码的腐化（和性能的持续恶化）。我们没办法期望所有开发人员都是经验，但架构师，或者架构团队需要承担这个责任。31软件设计的基本流程Theonlywaytodogreatworkistolovewhatyoudo.Ifyouhaven'tfoundityet,keeplooking.Don'tsettle.32软件设计的基本流程（1）软件设计的静态视角-软件设计先“从人入手”第一步：梳理业务的相关角色，包括角色的基本信息、角色的代表人员的简要信息、角色的诉求。第二步：梳理角色的工作，用一句话（10个字以内）描述每个工作。然后描述每个工作的流程，流程中的节点具有几个特性：a、有外界的信息输入；b、向其角色、系统输出信息、文件；c、与其他角色、系统有交互。第三步：基于IT技术的能力重新设计流程。这个环节即使选做，也是必做。选做是因为变革需要契机，有时只能把一步拆成两步，先把线下搬到线上，之后再逐渐优化。必做是这是一次难得机会，有可能让既有的工作有质的飞跃。

33软件设计的基本流程（1）软件设计的静态视角-软件设计先“从人入手”第一步：梳理业务的相关角色，包括角色的基本信息、角色的代表人员的简要信息、角色的诉求。第二步：梳理角色的工作，用一句话（10个字以内）描述每个工作。然后描述每个工作的流程，流程中的节点具有几个特性：a、有外界的信息输入；b、向其角色、系统输出信息、文件；c、与其他角色、系统有交互。第三步：基于IT技术的能力重新设计流程。这个环节即使选做，也是必做。选做是因为变革需要契机，有时只能把一步拆成两步，先把线下搬到线上，之后再逐渐优化。必做是这是一次难得机会，有可能让既有的工作有质的飞跃。

34（1）软件设计的静态视角-软件设计先从人入手第四步：整理功能列表并分类组合形成系统逻辑架构图：此时的功能需求相对清晰，将耦合性强的功能组合到一起，将独立性强的功能隔离开。整体思路与企业组织设计的思路相似。低耦合高内聚是一种追求和目标。第五步：将逻辑架构落实为真正的软件模块架构：这时要考虑软件工程的技术问题，属于纯软件的技术领域。包括微服务、队列、数据库、缓存、容器等等软件成型组件都会被考虑进来，一起为系统添砖加瓦。第六步：设计出部署架构、物理架构：将软件与实物部署相结合，包括网络规划、服务器规划、数据库规划、容灾备份等等。至此，软件的静态视角设计完成，我们就拥有了软件的宏伟蓝图，就可以撸起袖子开发了。产品、UI、前端、后端、硬件、质控、质保等等一群人不亦乐乎的忙乎起来。

软件设计的基本流程35（2）为软件降生而设计在获得了软件蓝图之后，还需要为软件降生而设计。也就是要为软件交付、部署、上线等进行设计。包括但不限于要解决的问题如下：如何将软件分发到需要它的地方？如何让实施人员更高效的完成安装调试？如何将初始数据导入到系统中，包括用户账号、组织架构、业务流程、基础业务数据、老系统中的数据？如何提供培训让用户真正能把软件用起来？……只有这些问题得到提前设计与做好应对设计和开发，才不至于让软件姗姗来迟，甚至错过了降生的机会。软件设计的基本流程36（3）为软件生存发展而设计软件所处的环境是持续变化的。所以行业内一般认为一套业务系统用几年被淘汰掉是正常的。为什么？因为之前交付的软件是静态的！为了让软件发展，需要让它能像孩子一样，不断了解世界，不断学习，不断改造升级自己，才能跟上企业的发展。需要做的设计包括但不限于：对既有功能测量、跟踪的能力适应访问压力增长的能力适应数据量不断增加而不被拖累的能力适应新业务变化发展的适配、扩展能力将数字化的思想引入到软件设计中好的软件设计刚开始会感觉有些慢。因为一开始并没有噼里啪啦的敲代码。好的软件设计在开始阶段会不断深入谈论业务。因为失之毫厘谬以千里。软件后期修改的成本极高，包括人力成本、工期延期的风险、质量下滑的成本等。软件设计的基本流程37一些建议（1）让业务骨干来参与到软件的需求调研和业务设计，与供应商软件架构师们一起设计；而不是让一些“闲人”来凑热闹。（2）主动帮助供应商了解业务，因为即使再老练的供应商也不会懂多少你企业的水深水浅。（3）软件前期多听听阶段汇报，将上线时的一次性验收拆解成很多个小验收。将压力提前分解，让软件质量更健康。38目录肆软件设计伍软件体系结构壹软件工程的目标贰软件工程模型叁软件开发的基本策略39如果想要深入理解一个事物的本质，最好的方式就是去追寻这个事物出现的历史背景和推动因素。（1）机器语言（1940年之前）例如，在8086机器上完成“s=768+12288-1280”的数学运算，机器码如下：110110000000000000000001120000010100000000001100003001011010000000000000101如果不小心哪个地方敲错了，将1敲成了0，例如：110110000000000000000001120000010100000000001100003001011000000000000000101机器语言的主要问题是三难：太难写、太难读、太难改！

软件体系结构40（2）汇编语言（20世纪40年代）为了解决机器语言编写、阅读、修改复杂的问题，汇编语言应运而生。汇编语言又叫“符号语言”，用助记符代替机器指令的操作码，用地址符号（Symbol）或标号（Label）代替指令或操作数的地址。例如，为了完成“将寄存器BX的内容送到AX中”的简单操作，汇编语言和机器语言分别如下。汇编语言虽然解决了机器语言读写复杂的问题，但本质上还是面向机器的，因为写汇编语言需要我们精确了解计算机底层的知识。例如，CPU指令、寄存器、段地址等底层的细节。这对于程序员来说同样很复杂，因为程序员需要将现实世界中的问题和需求按照机器的逻辑进行翻译。例如，对于程序员来说，在现实世界中面对的问题是4+6=？。而要用汇编语言实现一个简单的加法运算，代码如下：11000100111011000//机器语言2movax,bx

//汇编语言

软件体系结构41（2）汇编语言（20世纪40年代）1.section.data2a:.int103b:.int204format:.asciz"%d\n"5.section.text6.global_start7_start:8movla,%edx9addlb,%edx10pushl%edx11pushl$format12callprintf13movl$0,(%esp)14callexit除了编写本身复杂，还有另外一个复杂的地方在于：不同CPU的汇编指令和结构是不同的。例如，Intel的CPU和Motorola的CPU指令不同，同样一个程序，为Intel的CPU写一次，还要为Motorola的CPU再写一次，而且指令完全不同。

软件体系结构42（3）高级语言（20世纪50年代）计算机前辈们从20世纪50年代开始又设计了多个高级语言，最初的高级语言有下面几个，并且这些语言至今还在特定的领域继续使用。Fortran、LISP、Cobol等。这些语言让程序员不需要关注机器底层的低级结构和逻辑，而只要关注具体的问题和业务即可。还是以4+6=？这个加法为例，如果用LISP语言实现，只需要简单一行代码即可：程序员只要写一次程序，就可以在多个不同的机器上编译运行，无须根据不同的机器指令重写整个程序。(+46)软件体系结构43软件体系结构（4）第一次软件危机与结构化程序设计（20世纪60年代~20世纪70年代）随着软件的规模和复杂度的大大增加，20世纪60年代中期开始爆发了第一次软件危机，典型表现有软件质量低下、项目无法如期完成、项目严重超支等，因为软件而导致的重大事故时有发生。例如，1963年美国的水手一号火箭发射失败事故，就是因为一行FORTRAN代码错误导致的。软件危机最典型的例子莫过于IBM的System/360的操作系统开发。FrederickP.Brooks作为项目主管，率领2000多个程序员夜以继日地工作，共计花费了5000人一年的工作量，写出将近100万行的源码，总共投入5亿美元，是美国的“曼哈顿”原子弹计划投入的1/4。尽管投入如此巨大，但项目进度却一再延迟，软件质量也得不到保障。Brooks后来基于这个项目经验而总结的《人月神话》一书，成了畅销的软件工程书籍。44软件体系结构（5）第二次软件危机与面向对象（20世纪80年代）结构化编程的风靡在一定程度上缓解了软件危机，然而随着硬件的快速发展，业务需求越来越复杂，以及编程应用领域越来越广泛，第二次软件危机很快就到来了。第二次软件危机的根本原因还是在于软件生产力远远跟不上硬件和业务的发展。第一次软件危机的根源在于软件的“逻辑”变得非常复杂，而第二次软件危机主要体现在软件的“扩展”变得非常复杂。结构化程序设计虽然能够解决（也许用“缓解”更合适）软件逻辑的复杂性，但是对于业务变化带来的软件扩展却无能为力，软件领域迫切希望找到新的银弹来解决软件危机，在这种背景下，面向对象的思想开始流行起来。虽然面向对象开始也被当作解决软件危机的银弹，但事实证明，和软件工程一样，面向对象也不是银弹，而只是一种新的软件方法而已。45（6）软件架构的历史背景软件架构真正流行却是从20世纪90年代开始的，由于在Rational和Microsoft内部的相关活动，软件架构的概念开始越来越流行了。卡内基·梅隆大学的MaryShaw和DavidGarlan对软件架构做了很多研究，他们在1994年的一篇文章《软件架构介绍》（AnIntroductiontoSoftwareArchitecture）中写到：这段话很好地解释了“软件架构”为何先在Rational或者Microsoft这样的大公司开始逐步流行起来。因为只有大公司开发的软件系统才具备较大规模，而只有规模较大的软件系统才会面临软件架构相关的问题，例如：系统规模庞大，内部耦合严重，开发效率低；系统耦合严重，牵一发动全身，后续修改和扩展困难；系统逻辑复杂，容易出问题，出问题后很难排查和修复。

Whensystemsareconstructedfrommanycomponents,theorganizationoftheoverallsystem-thesoftwarearchitecture-presentsanewsetofdesignproblems.随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。软件体系结构46总结：软件开发进化的历史信息47软件体系结构软件架构的出现有其历史必然性。20世纪60年代第一次软件危机引出了“结构化编程”，创造了“模块”概念；20世纪80年代第二次软件危机引出了“面向对象编程”，创造了“对象”概念；到了20世纪90年代“软件架构”开始流行，创