第一章：软件工程概述
软件工程的产生：软件工程是在克服20世纪60年代末国际上出现"软件危机"的过程中逐渐形成的和发展的
软件危机出现的原因：软件规模越来越大，软件的复杂度不断增加，软件的需求量也不断增加
软件危机的主要表现：
- 软件产品质量低劣，甚至在开放的过程中就夭折
- 软件生产效率低，不能满足需要
软件工程发展的4个重要阶段：
- 第一代软件工程（传统的软件工程）
- 第二代软件工程（对象工程）
- 第三代软件工程（过程工程）
- 第四代软件工程（组件工程 或 构件工程）
软件过程模型也称为软件生存周期模型或软件开发模型，是描述软件过程中各种活动如何执行的模型
瀑布模型（适应于需求很明确的软件项目开发）
优点：结构简单、清晰，易于理解与掌握
缺点：不可回溯
螺旋模型（强调风险分析，适用于风险要求较高）
螺旋模型是一种迭代模型，它将瀑布模型与增量模型结合起来，将整个开发过程分为若干个螺旋周期，并加入了风险分析
缺点：成本高
螺旋模型每个螺旋周期包括四个工作步骤：
- 制定计划：确定该周期的目标、方案和限制条件
- 风险分析：评估方案、标识风险和解决风险
- 实施工程：按照确定的方案开发验证产品
- 客户评估：由客户运行原型并进行评估后，计划下一周期任务
喷泉模型（以用户需求为动力，以对象为驱动）
采用面向对象技术的软件开发项目。
它克服了瀑布模型不支持软件重用和多项开发活动集成的局限。喷泉模型是开发过程具有迭代行和无间隙性
喷泉模型的特点：
- 喷泉模型开发过程的4个阶段：分析、系统设计、软件设计、实现。
- 喷泉模型各阶段相互重叠，反映了软件过程并行性的特点
- 以分析为基础，资源消耗成塔形，在分析阶段消耗的资源最多
- 具有迭代行和无间隙性、强调增量开发。从高层返回底层无资源消耗
- 整个过程是迭代的逐步提炼的过程
软件开发方法：结构化开发方法、原型化开发方法、面向对象开发方法
结构化开发方法是一种面向数据流的开发方法，基本原则是功能的分解与抽象，指导思想是自顶向下、逐步求精。特点是快速、自然和方便
结构化开发方法的组成：结构化分析（SA）、结构化设计（SD）、结构化程序设计（SP）。（SA和SD是结构化开发方法的核心）
面向对象开发方法的组成：面向对象分析（OOA）、面向对象设计（OOD）、面向对象程序设计（OOP）。
OOA和OOD是面向对象开发方法的关键、OOD是面向对象方法的核心阶段
面向对象的主要目标：提高生产效率、提高质量和可维护性
面向对象的主要任务：对象设计
第二章：软件需求工程（明确软件"做什么"）
软件分析阶段的主要任务：明确软件做什么
需求工程过程：获取需求、需求分析与建模（常用技术：分解、抽象、多视点）、需求的有效性验证、需求管理
软件需求获取技术：面谈法、问卷调查法、需求专题讨论会、原型法获取需求、面向用例的方法
常用的需求分析方法：
- 功能分析方法（系统功能模块划分图）
- 结构化分析方法（分层数据流图）
- 信息建模法（E-R图）
- 面向对象的分析方法（UML图）
用例模型是一种可视化的图形，描述了系统的静态结构。"用例"表示一个系统的子系统或者是系统的一个独立的功能
数据流图（DFD）：描述系统中数据流程的图形工具，它标识一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换成逻辑输出所需的加工处理
eg：建立图书预定系统顶层的DFD，步骤如下
- 首先确定外部实体（顾客、出版社）及输入、输出数据流（订单、出版社订单）
- 再分解顶层的加工（验证订单、汇总订单）
- 确定所使用的文件（图书目录文件、顾客档案等5个文件）
- 用数据流将各部分连接起来，形成数据封闭
加工逻辑说明：结构化语言、判定表、判定树
第三章：软件设计（解决"如何做"的问题）
目标：构造一个 高内聚、低耦合 的软件模型
耦合性：软件结构中模块之间相互连接的紧密程度（高：内容耦合 低：数据耦合）
内聚性：模块内部各种数据和各种处理之间联系的紧密程度
软件设计阶段的主要任务：将分析阶段获得的需求说明转换为计算机中可实现的系统，完成系统的结构设计
软件设计阶段的任务：确定软件结构、确定系统的数据结构、设计用户界面
软件体系结构不仅指定了系统的组织结构和拓扑结构，显示了系统需求和构成系统的元素之间的对应关系，而且提供了一些设计决策的基本原理
仓库模型是一种集中式模型，用一个中央数据仓库来存储各个子系统共享的数据
特点：所有的计算机都在主机系统中完成（eg：银行系统、ATM机、命令控制系统、CAD系统）
仓库模型集中处理的特点决定了主机的计算能力是系统扩展的瓶颈。
分布式结构中的节点可以是同构的（即具有相同的软/硬件系统），也可以是异构
仓库模型的优点：
- 数据由一个子系统产生，并且被其他一些子系统共享
- 共享数据能得到有效的管理，各子系统之间不需要通过复杂的机制来传递共享数据
- 一个子系统不必关心其他子系统如何使用它产生的数据
- 所有子系统都拥有一致的基于中央数据仓库的数据视图
仓库模型的缺点：
- 各子系统之间为了能共享数据必须走一条折中的路线，会影响整个系统的性能
- 子系统发生改变，数据结构也会发生改变
- 影响子系统效率
- 集中式的控制使数据和子系统的分布变得非常困难
分布式系统模型（C/S 、B/S）
客户/服务器模型（C/S）
通过将任务合理分配到Client端和Server端，降低了系统的通讯开销，可充分利用两端硬件环境优势
工作原理：发请求得结果
组成部分：服务器、客户端
服务端（Server）：多个独立的服务器为系统提供诸如Web、文件共享、打印、存储等（响应请求，将结果回传给客户机）
客户端（Client）：多个并发客户应用访问多个服务器提供的服务，每个客户应用都是独立的。同样客户应用可以同时有多个实例（发送请求，数据、网页、文件传输请求）
C/S结构的应用系统由多个负责不同任务的子系统构成，为了降低这些子系统之间的耦合度，可以根据子系统的逻辑功能把他们规约在3个相对独立的逻辑层中：业务逻辑层、用户界面层、数据访问层
业务逻辑层映射到两端系统上，3种映射方式：
- 映射到客户端（胖客户端结构）
- 映射到服务端（瘦客户端结构）
- 在客户端与服务端均有服务
浏览器/服务器 模型（B/S）
浏览器/服务器（B/S）模式是瘦客户结构：客户端是浏览器，服务器能够传递HTML页面的Web服务器
B/S工作原理：用户通过浏览器向Web服务器发出页面请求，服务器响应请求 ，并将指定的页面文件传送给客户浏览器，浏览器在接收到页面后，解释页面的内容，并将解释的结果显示在浏览器的窗口中
在B/S结构中，由于页面文件是驻留在服务器端的，因此相对于传统的C/S应用，B/S应用的重新部署非常方便：C/S应用在更新客户端时需要用户下载新版本或者更新程序，然后重新安装客户端应用或者打补丁，这可能极大的增加部署的成本，甚至使重新部署不可能；而且B/S应用则不需要这样的过程，因为一旦完成服务端的页面更新，那么用户下载的页面就总是最新的
面向对象设计（OOD）：主要任务：对象设计
面向对象程序设计（OOP）
比较 C/S 模型 与 B/S模式的异同？
相同点：
两者都是通过网络进行通信的架构模式都涉及客户端和服务器的交互。
不同点：
C/S模式中，客户端负责显示逻辑和部分业务逻辑，服务器处理复杂的业务逻辑和数据操作。
B/S模式中，客户端(浏览器)只负责显示，所有业务逻辑都在服务器端完成，通过浏览器与服务器进行交互。
C/S模式需要安装专门的客户端软件，而B/S模式通过浏览器访问，无需安装额外的客户端软件。
B/S模式更加简化了客户端的复杂性，降低了维护成本，因为所有更新和升级都在服务器端进行。
综上所述，C/S模式和B/S模式的主要区别在于客户端和服务器的分工不同。C/S模式中，客户端承担部分逻辑处理，而B/S模式中，所有逻辑处理都在服务器端完成，客户端只需通过浏览器进行交互。B/S模式是C/S模式的延伸通过将显示逻辑移到服务器端，进一步简化了客户端
胖客户模型和瘦客户模型的区别是什么，他们分别被应用到什么样的场合？
在胖客户模型中，客户端应用负责用户界面和应用逻辑部分，因此它的工作比较繁重。一般的数据库应用都是属于这种结构。
与此相反，瘦客户端模型中，服务器负责了更多的工作，而客户端的工作就变得非常单纯。浏览器/web服务器就属于瘦客户端，而且常被称为B/S结构
请举出一种分布式模型的实例，并图示它的结构？
分布式模型是一种将计算任务分散到多个计算机上执行的模型
以MapReduce为例，其结构可以分为以下几个部分：
JobTracker：负责接收用户提交的任务，并将其分解为多个子任务（Map任务和Reduce任务），然后分配给各个TaskTracker去执行。
TaskTracker：负责执行JobTracker分配的子任务，并将结果返回给JobTracker。
Client：用户通过Client提交任务，并获取任务执行的结果。
MapReduce的工作流程如下：
用户通过Client提交任务。
JobTracker将任务分解为多个子任务，并分配给各个TaskTracker。
TaskTracker执行子任务，并将结果返回给JobTracker。
JobTracker收集所有子任务的结果，并将最终结果返回给Client。
分布式结构的优缺点？
优点:
1.资源共享:系统中每个服务节点上的资源都可以被系统中的其他节点访问。
2.经济型:分布式系统的使用成本远低于集中式系统。
3.可伸缩性好:系统可以方便地增删新的服务资源以满足需要。
4.健壮性:分布式系统中的信息冗余可以容忍一定程度的软硬故障。
5.性能高:通过越来越多的设备互连，以及高效的任务分配，分布式系统性能越来越高。
缺点:1.复杂性:分布式系统比集中式系统要复杂的多，并且依赖于网络的带宽，这让情形变得更加复杂。
2.安全性:网络环境随时面临着各种威胁:病毒、恶意代码、非法访问等。
3.可管理性:分布式系统的开放性造成了系统的异构性。管理异构的系统非常困难。
4.不可预知性:网络负载会明显地影响整个系统的响应时间。
第五章：软件构造
软件构造：通过编码、验证、单元测试、集成测试和排错的组合，创建了一个可以工作的有意义的软件。
程序设计语言的分类：低级语言（机器语言和汇编语言）和 高级语言
程序设计语言的选择标准：
- 项目的应用领域
- 算法和计算复杂性
- 软件的执行环境
- 性能因素（应结合工程具体性能来考虑）
- 数据结构的复杂度
- 软件开发人员的知识水平和心理素质
结构化设计的特点：
- 自顶向下、逐步求精：先全局、后局部，先抽象、后具体
- 单入口和单出口的控制结构：顺序、选择、循环3种基本控制结构组成
软件复用：重复使用已有的软件产品用于开发新的软件系统，以达到提高软件系统的开发质量和效率，降低开发成本的目的。在软件复用中重复使用的软件产品不仅仅局限于程序代码，而是包含了在软件生产的各个阶段所得到的各种软件产品，这些软件产品包含领域知识、体系结构、需求分析、设计文档、程序代码、测试用例和测试数据等
可重复的软件成分也称为可复用构件，可以从旧软件中提取，也可以专门为复用而开发
软件复用级别：代码的复用、设计结果的复用、分析结果的复用、测试信息的复用（由低到高）
第六章：软件测试
测试 的根本目的：发现尽可能多的缺陷
软件测试的特点：软件测试开销大、不能进行穷举测试
软件测试的基本原则：
- 应尽早和不断的进行软件测试
- 开发人员应尽量避免进行软件测试
- 注重测试用例的设计和选择
软件测试的方法：静态测试（人工的、非形式的方法对程序进行分析和测试）、动态测试
静态测试：桌前检查、代码会审、步行检查（调用图、数据流分析图(d表示定义、r表示引用、u表示未引用)）
动态测试（选择适当的测试用例上机执行程序进行测试）：
- 白盒测试（逻辑覆盖法）：分析程序的内部逻辑结构、注意选择适当的覆盖标准，设计测试用例，对主要路径进行尽可能多的测试
- 黑盒测试：不考虑程序的内部结构与特性，只根据程序功能或程序的外部特征设计测试用例。又称功能测试或数据驱动测试
- 等价分类法：等价类（有效等价类、无效等价类）、确定测试用例
- 边界值分析法：错误更可能发生在输入的极值附近。（最小值、略高于最小值、正常值、略低于最大值、最大值）
第七章：软件维护
软件维护：软件系统交付使用以后，为了改正软件运行错误，或者为满足新的需求而加入新功能的修改软件的过程
软件维护的类型：完善性维护、适应性维护、纠错性维护、预防性维护
软件维护的特性：
- 时间长、工作量大、成本高：软件维护的工作量占整个软件生存周期的70%以上，而且还在逐年增加
- 维护的副作用：通过维护可延长软件寿命，创造更多的价值，但可能引入新的潜在错误，常见副作用有如下三个
- 修改代码的副作用
- 修改数据的副作用
- 修改文档的副作用
- 软件维护的困难
- 结构化维护（按照软件工程方法进行）和非结构化维护（只有源程序）
- 维护的困难：由于软件需求分析和开发方法的缺陷
软件维护工作量模型：M = P + K * EXP(C - D) ：M表示维护总工作量、P表示生产性活动工作量、K为经验常数、C表述由非结构化维护引起的程序复杂度、D表示对维护软件熟悉程度的度量
软件可维护：软件能够被理解、并能纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度
软件可维护的主要因素：可靠性、可理解性、可测试性、可修改性、可移植性、效率、可使用性
提高可维护性的方法：
- 建立明确的软件质量标准
- 使用先进的软件开发技术和工具
- 建立明确的质量保证工作
- 选择可维护的程序设计语言
- 改进程序的文档
为什么要进行软件维护？
软件维护是指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程。在维护阶段中，人们需要着手解决开发阶段尚未解决的问题，同时，还解决维护工作本身所产生的问题。做好软件的维护工作不仅能够排除软件中存在的错误,使它能够正常工作而且还可以使它扩充功能，提高性能，为用户带来新的效益。因此，应充分认识到维护现有软件的重要意义。
怎样防止维护的副作用？
修改代码所产生的副作用一般可以在退化测试过程中对其造成系统的故障进行查明和纠正;完善设计文档资料可以限制修改数据的副作用，在文档中描述了数据结构，并提供了一种把数据元素、记录、文件以及其他结构与系统模块联系起来的交叉对照表;在软件系统再次交付使用之前，对整个软件配置进行复审，将能大大减少文档资料的副作用。
第八章：软件项目管理
软件项目管理是对软件项目开发全过程的管理，是对整个软件生存周期的所有活动进行的管理
描述较大软件项目的进度计划的工具：一般表格工具、甘特图（Gantt）（不能反映逻辑关系）、时标网状图（也称改进的甘特图）、PERT和CPM
第九章：软件能力成熟度模型CMM
软件能力成熟度模型是由美国 卡内基 . 梅隆大学软件工程研究所（CMU/SEI）推出的评估软件能力与成熟度的一套标准。该标准基于众多软件专家的实践经验，侧重于软件开发过程的管理与工程能力的提高与评估，是国际上流行的软件生产过程标准和软件企业成熟度等级认证标准。
CMM认证：已经称为世界公认的软件产品进入国际市场的通行证
CMMI：软件工程模型、系统工程模型、集成化产品和过程开发模型以及集成供应商管理模型等多个模型集合
软件过程的成熟度等级：
- 初始级：企业一般不具备稳定的软件开发与维护环境。项目成功与否很大程度上取决于是否有杰出的项目经理和经验丰富的开发团队
- 可重复级：组织建立了管理软件项目的方针以及为贯彻这些方针的措施。组织基于在类似项目上的经验对新项目进行策划和管理
- 已定义级：组织形成了管理软件开发和维护活动的组织标准软件过程，包括软件工程过程和软件管理过程
- 已管理级：收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。组织对软件产品和过程都设置定量的质量标准
- 优化级：组织通过预防缺陷、技术创新和更改过程等多种方式，不断提高项目的过程性能以持续改善组织软件过程能力
