软件设计与体系结构 课件 第1-5章 软件工程与软件设计-设计模式

软件设计，是实现软件价值的核心1交流提要■

从工程视角看IT■

新入职者—编码，是实现的工具■

提升创新能力—学会分析与设计■

对未来入职者的要求—思考&创新能力

2

□软件系统与建筑结构的异同

□软件的开发过程与建筑的开发过程

□软件开发与房屋建造是一样的思路✍软件开发，与房屋建造的不同之处：

更加抽象，所以就更需要进行分析和设计

建筑设计图软件设计图（业务分析）■从工程视角看IT3交流提要■

从工程视角看IT■

新入职者—编码，是实现的工具■

提升创新能力—学会分析与设计■

对未来入职者的要求—思考&创新能力

4新入职者—定位与能力计算机专业的毕业生会编码，但不清楚软件的需求与设计方法学校培养的计算机专业的学生，是程序员、还是工程师？✍程序员与工程师随着时间的推移，1年、3年、5年、7年，纯粹编码的热情就低了，面临转行，原因何在？你是把编码当做实现你脑中的创新构想的工具，还是将编码看成是你的终身职业？5■新入职者—定位与能力二、非计算机专业毕业生

□信息管理、自动化专业，有很多到软件企业从事需求分析、企业信息中心等

□从事软件的需求咨询、分析，需要有一定的实战知识和能力

□有信息管理的知识，但缺乏将知识与实际工作进行关联的方法和工具✍需求分析师的来源

□企业的专业人员、非计算机专业毕业生、程序员

□共同的目的

□各自的长处、共同的弱点6交流提要■

从工程视角看IT■

新入职者—定位与能力■

提升创新能力—学会分析与设计■

对未来入职者的要求—思考&创新能力

7一、为什么必须要掌握分析与设计的能力直接用编码实现，只能做小事，因为小事可以只凭大脑的想象就可以搞定，但是大型、复杂的对象必须要通过分析、设计才能够搞定

✍半天可以搞定！

一个晚上就可以搞定、三天开发出一个软件…

小应用，没有太多的逻辑是可以的

✍业务与管理的区分

管理信息与信息系统毕业的学生从事企业管理类系统的需求调研和分析，

但是分不清楚企业活动中哪些行为是业务、哪些是管理完成的系统，业

务与管理高度耦合，难以快速相应企业的需求变化。■提升创新能力—学会分析与设计81.需求分析与软件设计为什么那么重要呢？2.在编码之前，分析与设计做了哪些工作呢？3.分析与设计的能力是一体的（在其他行业，通常不会讲需求分析单独设为一个分支）✍调研完成的软件价值不高主要是谁的责任：

需求岗（分析与设计）or开发岗（编码）架构③功能数据⑤编码①客户原始需求②目标需求业务需求功能需求组件机制④需求调研&分析业务&应用设计技术设计开发实现需求规格说明书业务&应用设计规格书技术设计规格书■提升创新能力—学会分析与设计9需求分析与软件设计的过程分析与设计的对象：架构、功能、数据进行需求分析和软件设计之后，再进行编码，会是什么感觉呢？（有一种“掌控”的感觉）分析与设计成果→思考逻辑的过程；小程序代码→思考结果的表达工程分解工作分解

…4.详细设计3.概要设计5.应用设计架构规划功能规划需求工程架构详细架构机制数据规划数据详细数据机制①架构层②功能层③数据层2.需求分析1.需求调研需求访谈业务需求功能需求即存表单目标需求现状构成设计工程业务设计部分应用设计部分技术设计部分

…功能详细功能机制编码测试实现工程大家要理解：1.需求分析与软件设计，是完成系统的重要组成部分，是一名合规的软件工程师必备的知识和技能。2.完成一栋建筑，“建筑设计师”和“施工工程师”同样重要”■提升创新能力—学会分析与设计101)架构层是对业务优化后的成果表达，业务优化成果直接为客户带来成本下降、效率提升、效益的收获等。

□

因此架构层的成果是客户投资的直接目的之一。2)数据层数据是企业资产，数据的积累和有效利用（统计、分析、挖掘）会为客户提供解决问题、找到商机的启示。

□因此数据层的成果是客户投资的直接目的之一。3)功能层组成架构的要素，功能可以形成架构，记录、查询数据，功能是客户间接投资的目的。

□最终的客户价值是体现在架构和数据上的，功能是产生上述价值的工具（没有这个工具无法产生价值）。活动1活动2数据库①架构层②功能层③数据层业务流程活动X操作界面a.三分层的关系1.架构3.数据2.功能架构图功能图数据图DBb.三分层的价值关系直接价值间接价值■提升创新能力—学会分析与设计的对象11帮助学生建立“系统”的概念

□不但要理解“点”

□还要知道“线”、“面”、“体”

□具有空间的概念

□现实中的系统的构成越来越复杂，只能进行简单的点、线思维的学生难以应对■提升创新能力—学会分析与设计的对象：系统12交流提要1.从工程视角看IT2.新入职者—定位与能力3.提升创新能力—学会分析与设计4.对未来入职者的要求—思考&创新能力

134.对未来入职者的要求—思考&创新能力1）

我是程序员，为什么要学习需求分析和软件设计呢？□只会编码，知其然不知其所以然，

□如果掌握需求分析和软件设计的前提下进行编码，则可以做到“知其然，也知其所以然”✍

掌握分析与设计能力，入职工资提升30%

2）3年必须要上一个台阶

□进入企业之后，要确保每3年有一个质的变化和提升（经过了两个3年后没有变化，说明已到了天花板）

□确保你可以走入高端，否则你就会长期处于将编码作为唯一的存在价值

□架构师（=设计师），是每一个程序员追求的最高目标

144.对未来入职者的要求—思考&创新能力2）

非计算机专业

□未来在软件公司、企业信息中心，从事咨询、需求分析、设计等职业

□掌握了需求分析和软件设计的基本理论和方法，在进入企业后就获得了一定的实战能力

✍进入到企业信息中心，如何从辅助部门走到企业的“C位”

必须要能够理解、分析、构建企业的核心业务151.软件的设计包括了业务设计、应用设计和技术设计。2.好的软件首先是要有好的设计，客户价值是设计出来的3.设计的优劣，决定了软件的最高价值；

编码的优劣，实现决定了软件的最低价值。工程分解工作分解

…4.详细设计3.概要设计5.应用设计架构规划功能规划需求工程架构详细架构机制数据规划数据详细数据机制①架构层②功能层③数据层2.需求分析1.需求调研需求访谈业务需求功能需求即存表单目标需求现状构成设计工程业务设计部分应用设计部分技术设计部分

…功能详细功能机制编码测试实现工程决定了软件的最大客户价值建造设计师——建筑的最高价值汽车设计师——汽车的最高价值服装设计师——服装的最高价值…设计师——…的最高价值软件设计师——软件的最高价值■对未来入职者的要求—思考&创新能力16

企业，希望未来新入职者，能够在学校期间就接受过一些思考方法、表达方法（非编码）的教育，这样的学生理解能力强、接受新鲜事物快、相对短的时间内就可以独立工作、担当重要的岗位、开发复杂的系统。

而没有接受这样训练的学生，则比较难以改变思维方式，二者在比较短的时间内就会发生职业发展方向的不同，能力水平的差异会越来越大。在学校就培养学生的分析和设计意识、以及一定的实战能力，将会对学生未来的职业生涯走向带来非常积极的影响！

这也是避免学生日后成为“码农”的重要措施。■思考能力

□学会思考，分析手法

□学会表达，设计方法■创新能力

□可以面对任何新的研究对象

□不会依赖于别人，自己可以给出答案■目标达成

□达到目的后的成就感4.对未来入职者的要求—思考&创新能力观看：挖掘真正的学习价值所在17课程目标及考核18课程目标：

假定1：

毕业后从事软件开发和相关行业

不仅仅满足编码、希望获得职业生涯提升

5-10年以后，成为项目经理、架构师、需求分析师、更高…

假定2：

希望在编码的基础上提升素质能力

希望学习软件架构设计技术

愿意动手、不怕吃苦19课程考核：

考试：笔试70%+平时成绩10%+实验成绩20%

①笔试部分：

基本概念

基本方法

实践体会

②平时成绩：

平时作业

上课提问

点名、签到

③实验报告20感谢聆听21前言22当你的工作属于下述某个岗位时，你最关心的是什么呢？需求岗位：如何与客户沟通？如何向开发工程师提供完美的需求资料？设计岗位：何为架构？何为设计？如何设计出有高价值的软件产品？开发岗位：如何缩短从“程序员”走向“架构师”的距离？产品经理：什么是好产品？好产品的标准？如何实现好的产品设计？项目经理：如何能像工业生产一样：按时、按质、按量完成项目？…要解决什么问题？23一、从软件用户的视角看1.系统的客户价值低

系统仅解决了执行层的“手工替代”问题，未能做到“支持企业计划、组织、领导、监控、分析，提供实时、准确、完整的数据，为企业的经营管理者提供决策管理依据”的预期目标。2.随需应变能力差

系统上线后，通常用户使用的频率越高，发生需求变化的频率也越高，但是系统的开发者难以快速地响应需求的变化；3.信息孤岛问题严重

不同时期构筑的系统之间数据不能共享，而且非常难以解决，企业守着积累的大量数据但却难以进行二次、三次的应用，作为企业数据资产的价值发掘不出来等。只能解决客户操作层的需求关系到系统的生命周期企业的数据资产价值难以体现1.背景&目的：软件行业存在的问题（客户视角）24二、从系统开发者视角看1.产品价值低

□产品的客户价值低，造成软件商收益少，收益少又影响了对新产品研发的投入。

□这种非良性循环带来了行业内的同质竞争、低价竞争的问题。2.产品质量低（不考虑bug部分的影响）

□产品的质量低，分析与设计成果多以文字说明为主、附以简单的图形。

□无法与客户有效确认、向开发精确地表达设计意图。□沟通效率低、常发生严重的需求失真、遗漏、设计偏差，是造成系统质量问题的主要原因之一。3.产品复用（率）低

□

产品的复用率低，初级的重复劳动，高成本、低效率，造成对客户需求变化响应速度慢的问题。

□复用问题不解决，即影响客户的满意度、也阻碍软件开发企业降低成本的能力。低端、简单，与客户需求差距大缺乏工业化的软件生产方式设计&开发的理念、方法落后产品3低1.背景&目的：软件存在的问题（软件商视角）缺乏工业化的软件生产方式设计&开发的理念、方法落后25①需求工程重点是获取功能需求，以收集、分析及确定客户对系统功能的需求为主；②设计工程-软件设计部分重点是如何实现功能，以系统结构、数据接口、数据库、界面等内容的设计为主。这些工作都是偏软件实现方面的内容。③设计工程-业务设计/应用设计部分□业务设计：为优化客户业务的设计方法。

□应用设计：为实现优化业务的系统功能设计方法。

③的目的：为客户带来最大价值（效率、效益）。缺失部分建筑行业建筑设计师汽车行业汽车设计师服装行业服装设计师软件行业软件设计师？建筑设计汽车设计服装设计软件设计行业步骤角色图2

□业务设计

(优化,完善,价值)□应用设计(机制,复用,共享)1.需求工程3.开发工程□系统结构

□接口设计□数据库设计□界面2□需求调研

□需求分析□功能识别

□功能确认31

2.设计工程业务设计/应用设计部分软件设计部分图14.测试工程？1.背景&目的：问题发生的背景26造成客户和软件开发者存在问题的主要原因有三个（不限于此）1.软件工程：缺乏从“业务”视角的分析和设计方法体系□传统观点：重点在“功能需求”的获取和设计。

□本观点：先建立优化的业务体系，将“功能”作为支持业务运行的服务手段。2.软件企业：缺乏以“设计”为驱动的理念□传统观点：软件企业通常用“架构”的概念代替“设计”。

□本观点：“架构≠设计”，它是“设计”概念的一部分，是“粗粒度的设计”。3.软件工程师：缺乏以客户“价值”为导向的设计思想□传统观点：重“功能”轻“业务”的现象比较多，忽视客户信息化价值的设计。

□本观点：以“客户价值”为导向，客户买的是“价值”，功能为实现价值而存在。1.需求2.业务3.功能图1架构功能数据设计的对象粗细图2图3业务优化IT功能客户价值IT功能客户价值2.观点&目的：271.需求工程3.开发工程①业务设计2.设计工程②应用设计③技术设计本课程涉及的内容（软件设计）软件设计涉及的内容…

新的软件工程结构，将设计工程（软件设计）改为由三个部分构成1.业务设计：从架构、功能、数据三个层面讲述业务优化、设计方法。2.应用设计：针对优化成果，给出系统功能的设计方法。3.技术设计：给出实现业务设计、应用设计的技术方案，指导编程。

业务设计应用设计用户项目经理需求岗位设计岗位客户产品经理开发岗位实施岗位测试岗位技术设计2.观点&目的：软件工程的新定义28目标一：明确“设计”在软件工程中的定位明确“设计”（特别是业务设计/应用设计部分）在软件工程中的定位。

目标二：构建“业务设计/应用设计”的方法体系构建“业务设计/应用设计”的方法体系，它是需求工程与技术设计之间的桥梁，管理信息系统干系人之间进行沟通、决策的“共同语言”。

目标三：确定“业务设计/应用设计”方法体系的应用模式符合“工程化设计”的原则、标准、流程，使得从需求调研～设计完成之间的所有成果都是标准的、规范的，并且都是可传递、可继承的，让这些成果与后续的技术设计形成精确的无缝衔接。

目标四：提升软件企业和软件工程师的设计能力助力“业务岗位”成为“设计师”、“程序员”成为开发“工程师”。1.需求

工程2.设计

工程3.开发

工程软件工程4.…图1业务设计业务价值应用设计应用价值客户价值的主体图23.4个目标291.图形化采用图形表达为主的方式可以大幅度地减少需求与设计的失真，图形化的表达方式可以明显地提升工作效率和产品质量。2.标准化从图形表达到文字描述，标准方式可实现资料的无缝传递、继承需求调研→需求分析→概要设计→详细设计→应用设计→技术设计3.工程化有了图形化、标准化作基础，将软件实现的各个环节程按照工程化模式串联起来。4.逻辑线以逻辑为主线（业务逻辑、数据逻辑），包括图形、文字。易掌握易传播易管理易理解解决3低的钥匙3.三化一线30谢谢观看31知识体系概述32构成名称说明13个体系1.业务知识体系客户从事业务所需的知识，如：企业管理、市场销售、成本控制、生产流程等2.设计知识体系信息化设计所需的知识，如：需求分析、概要设计、功能设计、数据设计等3.开发知识体系软件开发所需要的知识，如：技术框架、编码开发、系统测试、硬件、环境设置等23个原理1.分离原理研究拆分对象的理论和方法，如：业务、管理、组织、物品等2.组合原理研究架构模型的理论&方法，如：组合三元素（要素、逻辑、模型）3.基干原理研究实现功能复用、数据复用的理论和方法（组件+机制）33.1软件工程-需求工程1.需求调研研究需求调研方法和记录方法：现状构成图、访谈记录、即存表单2.需求分析研究需求分析的方法：目标需求、业务需求、功能需求3.2软件工程-设计工程工程分解(3个阶段)1.概要设计研究业务的概要设计，如：架构规划、功能规划、数据规划2.详细设计研究详细设计的方法，如：流程分歧、业务原型、数据算式等3.

应用设计研究将业务设计成果转换为系统设计内容工作分解(3个层次)1.架构层设计对架构进行三个阶段的设计，包括：架构规划、流程分歧、流程机制等2.功能层设计对功能进行三个阶段的设计，包括：功能规划、业务功能、应用功能等3.数据层设计对数据进行三个阶段的设计，包括：数据规划、数据算式、数据复用等知识体系33设计知识体系体系2体系3开发知识体系业务知识体系体系11.需求工程-调研分析2.设计工程-业务设计&应用设计3.设计工程-技术设计需求分析&软件设计管理咨询1.需求工程2.设计工程3.开发工程4.测试工程5.运维工程需求调研需求分析业务设计应用设计技术设计业务人员技术人员软件开发重点、难点业务验证系统测试使用维护上线培训软件相关的3个知识体系34②设计知识分离原理

、组合原理、基干原理输入输入输出输出①业务知识□行业知识□管理知识□其它知识…□企业构成□标准规范□功能需求…□标准、规范

□框架、流程…③开发知识□业务逻辑

□设计资料□开发语言□技术框架□数据库…□知识经验□结构要求□标准要求…1.需求工程2.设计工程1.目标需求技术2.业务需求3.功能需求1.界面层2.逻辑层3.数据层业务&应用1.架构层2.功能层3.数据层需求分析与软件设计3个知识体系的关系35工程分解工作分解

…4.详细设计3.概要设计5.应用设计架构规划功能规划需求工程架构详细架构机制数据规划数据详细数据机制概要规格书详细规格书应用规格书①架构层②功能层③数据层需求规格书2.需求分析1.需求调研需求汇总规格书需求访谈业务需求功能需求即存表单目标需求现状构成设计工程业务设计部分应用设计部分技术设计部分

…功能详细功能机制业务用例验证用例应用用例建筑结构软件工程的构成36三、知识

内容一、工程分解需求工程设计工程（非技术部分）业务设计部分应用设计部分Ⅰ.需求调研Ⅱ.需求分析Ⅲ.概要设计Ⅳ.详细设计Ⅴ.应用设计二、工作分解

1.架构■现状记录（图）

□记录客户业务构成状况

□框架图,分解图,流程图■架构梳理

□补完业务的框架、结构

□去除虚实体、通顺流程逻辑

□框架图,分解图,流程图

■架构-规划

□架构概要规格书整体

（拓扑,分层,框架,分解,流程）

■设计思路确定

□确定系统的设计理念、主线■架构-细节

□流程详细规格书(流程5件套)

□业务流程：线性,泳道,混合

□审批流程■架构-转换

□架构应用规格书

□架构图→应用架构

■架构机制

□流程推送（事找人）

□导航菜单（人找事）

2.功能■访谈记录（文）

□目标需求（客户）

□业务需求（用户）

□功能需求（系统）■记录分析

□转换：目标→业务→功能

□功能需求规格书（需求4件套)

□功能需求一览表（需求版）

■功能-规划

□功能概要规格书

分类(活动,字典,看板,表单）

□功能视图

□业务功能一览表（规划版）■功能-细节

□功能详细规格书

□业务功能规格书（业务4件套)

□业务功能一览表（最终版）■功能-机制

□功能应用规格书

□业务组件规格书(组件4件套）

□业务组件一览表（组件版）

■系统功能（时限、权限）3.数据■表单收集（表）

□既存表单

□表单间关系图■既存表单分析

□既存表单分析结果

□功能需求规格书(需求4件套)■数据-规划

□数据概要规格书

□数据分类、规划(系统,领域)

□主数据规划

□数据标准、业务编号■数据-细节

□数据详细规格书

□数据表关系图

□数据算式图

(关联、勾稽、数据线）■数据-机制

□数据应用规格书

（数据的共享,复用,增值)综合设计4.管理

■管理要求■概要设计

□理念、主线、规划、架构图■管控模型

□业务标准、管理规则、决策判断■管理-机制5.价值

■业务价值的设计

□架构层□功能层□数据层■应用价值的设计

□架构层□功能层□数据层6.模板

&用例■需求调研资料汇总

□现状记录资料■需求规格说明书

□需求4件套■概要设计规格书

□业务架构图□业务规划图

□数据规划图等■详细设计规格书】

□流程5件套□业务4件套

□数据算式图□业务用例等■应用设计规格书

□流程机制□组件4件套

□数据复用/共享□应用用例等基础概念①分离原理②组合原理③基干原理简述软件工程的构成（表格形式）37数据设计功能设计架构设计需求工程需求调研需求分析目标需求、业务需求、功能需求架构需求设计工程概要设计架构规划架构层功能层数据层详细设计架构层功能层数据层应用设计架构层功能层数据层架构机制功能规划功能机制数据规划数据机制数据需求功能需求概要设计规格书详细设计规格书应用设计规格书需求规格说明书需求调研资料汇总业务用例应用用例工程分解工作分解资料详细交付物功能详细架构详细数据详细软件工程开发工程技术设计现状构成、访谈记录、即存表单简述软件工程的构成（分解图形式）38“收敛”

用②的作用来说明■①存在的不确定问题尽可能都在②中解决，■而不要将①的问题放到②下面的③或是④中解决。■在②中解决的问题越多，则②的倒梯形坡度越大，也就是对①的收敛的贡献越大。

它的实际意义就在于如果把①中的部分业务问题放到③的技术设计中解决，就会造成系统耦合度高、开发成本增加，且不易于系统的复用和应变性。建筑行业制造行业纺织行业农业行业教育行业医疗行业…行业④开发工程②设计工程(业务、应用)③设计工程(技术)多行业、多企业、多领域→业务有无限多的形态软件的编码开发→实现复用通过技术设计→收敛为构件、规则、接口通过分析&设计→收敛为架构、功能、数据一、设计知识体系的作用1/239结论：②对①的收敛越大

→系统整体设计越优秀；③对①的变化越少

→则系统可以复用部分多；④对①的变化越少

→开发效率高、开发成本低

图a是最佳比例。建筑行业制造行业纺织行业农业行业教育行业医疗行业…行业④开发工程②设计工程(业务、应用)③设计工程(技术)MN（a）①需求工程建筑行业制造行业纺织行业农业行业教育行业医疗行业…行业④开发工程②设计工程(业务、应用)③设计工程(技术)MN（b）①需求工程一、设计知识体系的作用2/240参考1：面向过程的方法（业务逻辑）

面对企业管理类的项目，通常对于一个业务设计师来说是很难开始就从功能或是数据层面进行分析的，对他而言，初期与客户讨论时，讨论对象的粒度是“经营、销售、采购、合同、投标、销售等”，这样的一个词本身可能就代表一个系统，对这个词需要进行拆分若干层后才会出现数据，因此不能开始就从最细的数据粒度开始做数据流图，因为□第一搞不清楚数据（缺乏定义、来源、关系等信息）；□第二容易从开始就陷入到细节中去（数据是要素的最小粒度）；

正确的方法是：要以“经营、销售等”粗粒度的对象为节点，先绘制业务逻辑图（业务架构图），这样的从粗到细易于与客户的高层进行交流、确认。

面对企业管理类型的信息系统，采用以业务逻辑关系表达为主的方法首先理清楚现状、业务逻辑、变化规律、范围、边界之后，再采用面向对象的方法进行细节的建模、分析、设计，不但可以降低初期研究的难度，而且可以有效地避免发生研究偏离目标的问题。1.架构层（过程、流程)（通过架构、理解逻辑）2.功能层（界面）（获取数据）3.数据层（分析数据关系）二、关于面向过程与面向对象1/241参考2：面向对象的方法（数据、机制）通过对业务过程的分析充分地理解了业务构成、业务逻辑以及变化规律，这样就可以设计出稳定的面向对象的模型。间接地将面向过程/对象的思想和理念融入到了设计说明中，如：组合原理（黑/白盒、高内聚/低耦合等）、功能的业务设计和应用设计（模块化、组件化、构件等）。采用了业务分析人员和设计人员容易理解的非技术表达形式进行设计，采用自然表达方式绘制各类图形，它们不但容易为客户所理解、同时还容易为技术设计师所接受和继承（不论他是否采用面向对象的设计方法）。作为从事需求分析和业务设计的工程师，需要同时掌握这两个方法，它们的结合使用才能完美地完成企业管理类信息系统的需求分析与业务/应用设计，两者之间不存在谁取代谁、或是哪一个更加优秀问题，特别面对大型的、复杂的企业管理类信息系统更是如此。XX通过面向过程的研究、理解和获取了业务逻辑针对“X”进行面向对象的分析和设计，获取数据和机制2.功能3.数据1.架构（流程）DB二、关于面向过程与面向对象2/242谢谢观看4344软件工程与软件设计第一章45少数聪明人干的事导致的危机在60年代计算机发展初期，程序设计是少数聪明人干的事。他们的智力与技能超群，编写的程序既能控制弱智的计算机，又能让别人看不懂、不会用。那个时期编程就跟捏泥巴一样随心所欲，于是他们很过分地把程序的集合称为软件，以便自己开心或伤心时再把程序捏个面目全非。人们就在这种美滋滋的感觉下热情地编程，结果产生了一堆问题：程序质量低下、错误频出、进度延误、费用剧增......。这些问题导致了“软件危机”。

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

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

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

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

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

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

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

//汇编语言

软件体系结构84（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再写一次，而且指令完全不同。

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

Whensystemsareconstructedfrommanycomponents,theorganizationoftheoverallsystem-thesoftwarearchitecture-presentsanewsetofdesignproblems.随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。软件体系结构89总结：软件开发进化的历史信息90软件体系结构软件架构的出现有其历史必然性。20世纪60年代第一次软件危机引出了“结构化编程”，创造了“模块”概念；20世纪80年代第二次软件危机引出了“面向对象编程”，创造了“对象”概念；到了20世纪90年代“软件架构”开始流行，创造了“组件”概念。我们可以看到，“模块”“对象”“组件”本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的层次越来越高。91体系结构是软件系统中最本质的东西（1）体系结构是对复杂事物的一种抽象。良好的体系结构是普遍适用的，它可以高效地处理多种多样的个体需求。一提起“房子”，我们的脑中马上就会出现房子的印象（而不是地洞的印象）。“房子”是人们对住宿或办公环境的一种抽象。（2）体系结构在一定的时间内保持稳定。只有在稳定的环境下，人们才能干点事情，社会才能发展。科学告诉我们，宇宙间万物无时无刻不在运动、飞行。由于我们的生活环境在地球上保持相对稳定，以致于我们可以无忧无虑地吃饭和睡觉，压根就意识不到自己是活生生的导弹。软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。人们希望在需求发生变化时，最好只对软件做些皮皮毛毛的修改，可千万别改动软件的体系结构。92搬砖的架构设计搬砖A：“头，我们要造什么？”；（做什么系统？）包工头：“梦商城”；（XXX系统，比如微博系统）搬砖A：“图纸画出来了嘛？”；（架构是怎么设计的？）包工头：“一楼主要以女性消费为主体、二楼以大众娱乐为主体、三楼以美食为主体”；（相当于微博系统中的各个子系统，比如评论子系统、动态子系统、消息子系统）搬砖A：“头，说人话”；包工头：“一楼有卖衣服、化妆品的，二楼有唱歌、看电影的，三楼有吃的”；（【模块】按照逻辑区分，比如存储数据模块、搜索模块、文章模块）搬砖A：“有没有很知名的店啊？”；93搬砖的架构设计包工头：“有的，一楼有耐克、优衣库...、二楼有红歌会、万达影院....、三楼有海底捞、星巴克.....”；（【组件】按照物理区分，存储数据模块对应MySQL、搜索模块对应ElasticSearch）搬砖A：“对了，头，商城大门有啥施工规范不？有没有啥新套路用得上？”；（有框架的可以用吗？）包工头猛吸了一口烟，把烟头扔在地上，用皮鞋左右撵了两下，缓缓从嘴里崩出四个字：“老样子吧”。（Spring全家桶甩起来）94软件架构的重要性（1）项目关系人之间交流的平台架构提供了一个共同语言（公共的参考点），项目关系人以此作为彼此理解、协商、达成共识或相互沟通的基础。（2）早期设计决策1）架构影响着系统的质量属性。2）架构可以用来预测系统的质量。3）架构为维护的决策提供根据。4）架构有助于原型开发。（3）在较高层面上实现软件复用软件架构作为系统的抽象模型，可以在多个系统间进行传递（复用），特别是比较容易的应用到具有相似质量属性和功能需求的系统中。产品线通常可以共享一个脚骨。（4）架构对开发的指导与规范意义不容忽略架构使基于模板的开发成为可能，有利于开发的规范化和一致性，减少开发与维护成本。

95请阅读“软件架构的重要性.pdf”谢谢观看962-软件设计基础目录壹软件设计的基本概念贰软件设计的范畴与内容叁软件设计的质量肆软件架构的概念与范畴伍高可用设计软件设计是一系列创造活动，是借助编程语言以简单和优雅的方式表达并解决现实需求的一门科学和艺术。什么是设计？设计是你身处两个世界---技术世界和人类的目标世界---而你尝试将这两个世界结合在一起。---MitchKapor，Lotus1-2-3发明者，《软件设计宣言》概述软件设计这一行为的目的是把软件的功能需求转化为软件的系统设计。设计师要产出系统的整体结构、功能模块划分、每个模块的数据库设计和实现方法，最后形成概要设计文档和详细设计文档。软件设计文档是架构师交付的文档，需求文档是产品经理交付的文档。互联网公司有三类核心的岗位，分别是：产品、技术、运营。概述产品经理是通过用户调研、功能设计让产品有用。技术是把产品实现出来，实现产品经理的构想，让产品可用。运营是为了更好地连接产品和用户而做的一切行为和实践。产品和用户不能产生关系的，产品就没有价值了。运营这件事做到极致，可以让你的用户成为产品的一部分。软件开发周期系统设计系统设计是把需求转化为软件系统的最重要的环节。系统设计的优劣在根本上决定了软件系统的质量。就象“心里充满的，口里就说出来”那样可以断定“差的系统设计必定产生差的软件系统。”所以我们要努力保证系统设计“根正苗红”，把一切不良的设计思潮消灭在萌芽状态。Coad和Yourdon把“设计”定义为：为问题域的外部可见行为的规约增添实际的计算机系统实现所需的细节，包括关于人机交互、任务管理和数据管理的细节。系统设计曾经的WindowsNT的一位系统设计师拥有8辆法拉利跑车，让Microsoft公司的一些程序员十分眼红。但你只能羡慕、嫉妒而不能愤恨，因为并不是每个程序员都有本事成为复杂软件系统的设计师。系统设计要比纯粹的编程困难得多。即便你清楚客户的需求，却未必知道应该设计什么样的软件系统——既能挣最多的钱又能让客户满意。“天下西湖三十六，最美是杭州”，千年前苏东坡大学士对西湖精采绝伦的系统设计，使杭州荣升为“天堂”一些建议（1）让业务骨干来参与到软件的需求调研和业务设计，与供应商软件架构师们一起设计；而不是让一些“闲人”来凑热闹。（2）主动帮助供应商了解业务，因为即使再老练的供应商也不会懂多少你企业的水深水浅。（3）软件前期多听听阶段汇报，将上线时的一次性验收拆解成很多个小验收。将压力提前分解，让软件质量更健康。包括四方面内容从功用上来讲，软件设计包括四方面内容：体系结构设计、模块设计、数据结构与算法设计、用户界面设计。如果将软件系统比喻为人体，那么：（1）体系结构就如同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容，这家伙始终都是猴子，不会成为人。（2）模块就如同人的器官，具有特定的功能。人体中最出色的模块设计之一是手，手只有几种动作，却能做很多的事情。包括四方面内容（3）数据结构与算法就如同人的血脉和神经，它让器官具有生命并能发挥功能。数据结构与算法分布在体系结构和模块中，它将协调系统的各个功能。人的耳朵和嘴巴虽然是相对独立的器官，但如果耳朵失聪了，嘴巴就只能发出“啊”“呜”的声音，等于丧失了说话的功能（所以聋子天生就是哑巴），可人们却又能用手势代替说话。人体的数据结构与算法设计真是十分奇妙。包括四方面内容（4）用户界面就如同人的外表，最容易让人一见钟情或一见恶心。象人类追求心灵美和外表美那样，软件系统也追求（内在的）功能强大和（外表的）界面友好。但随着生活节奏的加快，人们已少有兴趣去品味深藏不露的内在美。如果把Unix系统比作是健壮的汉子和妇人，那么Windows系统就象妩媚的小白脸和狐狸精。想不到Windows系统竟然能兴风作浪，占去大半市场。深情地关注软件的质量因素正确性与精确性、性能与效率、易用性、可理解性与简洁性、可复用性与可扩展性等。即使把软件设计做好了，也并不意味着就能产生好的软件系统。在程