软件工程全书知识点笔记

Chapter 1-概论

计算机软件指计算机系统中的程序及其文档

软件危机

许多软件项目不能满足客户的要求

许多软件项目超出预算和时间安排

软件危机的表现

• 对软件开发成本和进度的估计常常很不正确

• 用户对已完成的软件系统不满意的现象经常发生

• 软件产品的质量往往靠不住

• 软件常常是不可维护的

• 软件通常没有适当的文档资料

• 软件成本在计算机系统总成本中所占的比例逐年上升

• 软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势

软件危机的原因

• 软件是逻辑产品，开发进度、成本难以估计

• 缺乏或不完整、不一致的文档给维护带来困难

• 用户对软件需求的描述往往不够精确，有遗漏，有二义

• 软件开发人员对需求的理解与用户的本来愿望有差异

• 大型软件项目需多人协同完成，缺乏管理经验

• 开发人员不能有效地、独立自主地处理大型软件的全部关系

• 缺乏有力的方法学和工具的支持

• 软件项目的特殊性和人类智力的局限性

克服软件危机的途径

• 消除错误的概念和做法

• 推广使用成功的开发技术和方法

• 使用软件工具和软件工程支持环境

• 加强软件管理

能力成熟度模型CMM

• 1级__初始级

• 2级__可重复级

• 3级__已定义级

• 4级__已管理级

• 5级__优化级

软件过程模型

• 瀑布模型（waterfall model）**

• 演化模型（evolutionary model）

  • 增量模型（incremental model）
  • 原型模型（prototyping model)
  • 螺旋模型（spiral model）

• 喷泉模型（water fountain model）

• 基于构件的开发模型（component-based development model）

• 形式方法模型（formal methods model）

特征

• 接受上一阶段的结果作为本阶段的输入

• 利用这一输入实施本阶段应完成的活动

• 对本阶段的工作进行评审

• 将本阶段的结果作为输出，传递给下一阶段

缺点

• 缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发

• 开发早期存在的问题往往要到交付使用时才发现，维护代价大

增量模型特别适用于：

• 需求经常变化的软件开发

• 市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发

增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术

原型的类型：

探索型 : 其目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性

实验型 : 其目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠

演化型 : 其目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统

原型的使用策略:

废弃策略

追加策略

螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本

Chapter 2-系统工程

基于计算机的系统

• 所谓基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的集合

• 组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程（Procedure）

可行性分析

经济可行性分析：经济可行性主要进行成本效益分析，从经济角度，确定系统是否值得开发

技术可行性分析：技术可行性主要根据系统的功能、性能、约束条件等，分析在现有资源和技术条件下系统能否实现，技术可行性分析通常包括风险分析、资源分析和技术分析

法律可行性分析

Chapter 3-需求工程

软件需求工程细分为： 需求获取 、 需求分析与协商 、 系统建模 、 需求规约 、 需求验证 和 需求管理 六个阶段

需求获取方法与策略

• 建立顺畅的通信途径

• 访谈与调查

• 观察用户操作流程

• 组成联合小组

• 用况（Use Case）

Chapter 4-设计工程

功能独立

• 内聚（cohesion）是一个模块内部各个元素彼此结合的紧密程度的度量

• 耦合 (coupling) 是模块之间的相对独立性（互相连接的紧密程度）的度量

#### 常见的软件体系结构

• 单主机结构

• C/S（Client/Server）结构

• B/S（Browser/Server）结构

五种基本控制结构

• 顺序型
• 选择型
• 循环型
  • 先判定型循环(DO-WHILE)
  • 后判定型循环(DO-UNTIL)
  • 多情况选择型(CASE)

Chapter 5-结构化分析与设计

数据流图

基本元素：

顶层图只有代表整个软件系统的1个加工，描述了软件系统与外界(源或宿)之间的数据流

顶层图中的加工经分解后的图称为0层图(只有1张)

画顶层图

• 确定源和宿
• 顶层图唯一的加工
• 确定数据流：系统输入/输出信息
• 顶层图通常没有文件

画0层图

• 确定加工：确定父图中某加工分解而成的子加工

• 确定数据流

• 确定文件

• 确定源和宿

• 0层图和其它子图中通常不必画出源和宿

  有时为了提高可读性，可以将顶层图中的源和宿画在0层图中

画分层数据流图

• 画系统的输入和输出

• 画系统内部

• 画加工内部

• 重复第 3 步，直至每个尚未分解的加工都足够简单 (即不必再分解)

分层数据流图的审查

• 一致性：分层DFD中不存在矛盾和冲突

• 完整性：分层DFD本身的完整性，即是否有遗漏的数据流、加工等元素

数据字典

数据字典条目包括：数据流、文件、数据项(组成数据流和文件的数据)、加工、源或宿

加工逻辑的描述方法

• 结构化语言：介于自然语言和形式语言之间的一种半形式语言

• 判定表：适用于加工逻辑包含多个条件，而不同的条件组合需做不同的动作

• 判定树：判定表的变种，它本质上与判定表是相同的，只是表示形式不同

数据流图到软件体系结构的映射

数据流图分为变换型数据流图和事务型数据流图

• 变换流型的DFD图可明显地分成输入、变换、输出三部分

• 数据流沿着输入通路到达一个事务中心，事务中心根据输入数据的类型在若干条动作通路（action path）中选出一条来执行，具有这种特征的信息流称为事务流

• 事务中心的任务是：

  • 接收事务（输入数据）

  • 分析每个事务以确定它的类型

  • 根据事务类型选取一条动作通路

Chapter 6-面向数据结构的分析与设计

JSP ：Jackson 结构程序设计方法

JSD：Jackson 系统开发方法

Chapter 7-面向对象方法基础

Chapter 8-面向对象建模

用况建模

创建用况模型的步骤包括：

1．定义系统

2．确定执行者

3．确定用况

4．描述用况

5．定义用况间的关系

6．确认模型

类和对象建模

类和对象模型的基本模型元素有类、对象以及它们之间的关系。系统中的类和对象模型描述了系统的静态结构，在 UML 中用类图和对象图来表示

动态建模

动态建模用来描述系统的动态行为，显示对象在系统运行期间不同时刻的动态交互。UML 中用状态机图、活动图、顺序图、通信图和协作图来建立动态模型

• 状态机图

  状态机图通常是对类描述的补充，它说明该类的对象所有可能的状态，以及哪些事件将导致状态的改变。状态机图描述了对象的动态行为，是一种对象生存周期的模型

• 活动图

  • 活动图可看作一种特殊形式的状态机，用于对计算流程和工作流建模。活动图的状态表示计算过程中所处的各种状态
  • 活动图用来描述完成一个操作所需要的活动，或者是一个用况实例（场景）的活动
  • 活动图使用状态机图的符号表示，活动图中的状态称为动作状态，用圆角矩形表示，动作状态之间的迁移用箭头表示，迁移上可以附加警戒条件、发送子句和动作表达式
  • 与状态机图不同的是，活动图中动作状态之间的迁移不是靠事件触发的，当动作状态中的活动完成时迁移就被触发

• 顺序图

  顺序图用来描述对象间的交互行为，它关注于消息的顺序，即对象间消息的发送和接收的顺序。顺序图还揭示了一个特定场景的交互，即系统执行期间发生在某时间点的对象之间的特定交互。它适合于描述实时系统中的时间特性和时间约束

  顺序图有两个坐标，垂直坐标表示时间（从上到下），水平坐标表示一组对象（用对象框表示）

• 通信图

物理体系结构建模

构件图

构件图显示构件类型的定义、内部结构和依赖。构件是系统设计的模块化部分，它给出一组外部的接口，而隐藏了它的实现。在系统中满足相同接口的构件可以自由地替换

构件的接口有二种：

供应接口（provided interface）: 供应接口声明该构件为其他请求者提供某种服务

请求接口（required interface）: 请求接口声明该构件请求其他供应者为其提供某种服务，以完成其功能需求

部署图

Chapter 9-基于构件的软件开发

长期以来的软件开发状况

• 多数软件都是针对某个具体的应用系统从头进行开发的

• 导致：出现了大量的同类软件重复开发，造成大量人力、财力的浪费，而且软件的质量也不高

构件的要素

• 规格说明：建立在接口概念之上，作为服务提供方与客户方之间的契约

• 一个或多个实现

• 受约束的构件标准

• 包装方法

• 部署方法

3C构件模型

• 概念（concept）：关于“构件做什么”的抽象描述，可以通过概念去理解构件的功能。概念包括接口规约和语义描述两部分，语义描述和每个操作相关联（至少表示为前后置谓词形式）

• 内容（ content）：概念的具体实现，描述构件如何完成概念所刻画的功能

• 周境（ context）：描述构件和外围环境在概念级和内容级的关系，刻画构件的应用环境，为构件的选用和适应性修改提供指导

Chapter 10-敏捷软件开发

敏捷方法的基本观点

• 强调适应性而不是可预测性

  • 经典软件开发方法：通过控制变化实现软件开发的可预测性
  • 敏捷软件开发方法：变化是不可避免的，应该通过改善管理实践和工程实践来更好地适应变化

• 强调人在项目中的关键作用

  • 敏捷软件开发认为人不是可以互相替换的“编程部件”，而是具有创造力的个体，成功的软件开发活动依赖于人的主观能动性

• 强调“刚刚好”（Just enough）

• 在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，即开发中的活动及制品既不要太多也不要太少

Scrum

核心概念：

透明、检验、适应

尽量在早期暴露软件开发中的问题，进行及时的调整，从而使得软件开发团队在充满不确定的研发领域成功地工作

极限编程（XP）方法

XP方法的价值观

交流、简单、反馈、勇气、尊重

Chapter 11-人机界面设计

Chapter 12-程序设计语言和编码

Chapter 13-软件测试

软件测试的目的

Glen Myers 给出的软件测试目的：

• 测试是一个为了发现错误而执行程序的过程

• 一个好的测试用例是指很可能找到迄今为至尚未发现的错误的测试用例

• 一个成功的测试是指揭示了迄今为至尚未发现的错误的测试

软件测试的原则

Davis 提出了一组指导软件测试的基本原则：

• 所有的测试都应可追溯到客户需求

• 应该在测试工作真正开始前的较长时间就进行测试计划

• Pareto原则：测试中发现的 80% 的错误可能来自于 20% 的程序代码

• **测试应从 “小规模” 开始，逐步转向 “大规模” **

• 穷举测试是不可能的

• 为了达到最有效的测试，应由独立的第三方来承担测试

白盒测试与黑盒测试

• 白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作

• 白盒测试主要用于对模块的测试，包括：

  • 程序模块中的所有独立路径至少执行一次

  • 对所有逻辑判定的取值（”真“ 与 ”假“）都至少测试一次

  • 在上下边界及可操作范围内运行所有循环

  • 测试内部数据结构的有效性等

• 黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求

• 黑盒测试可用于各种测试，它试图发现以下类型的错误：

  • 不正确或遗漏的功能

  • 接口错误，如输入/输出参数的个数、类型等

  • 数据结构错误或外部信息(如外部数据库)访问错误

  • 性能错误

  • 初始化和终止错误

• 常见的白盒测试方法

  • 逻辑覆盖测试
  • 基本路径覆盖测试
  • 数据流测试
  • 循环测试

• 主要的黑盒测试方法

  • 等价类划分

  • 边界值分析

  • 比较测试

  • 错误猜测

  • 因果图

测试策略

一种测试策略就是将测试分为单元测试、集成测试、确认测试和系统测试

• 单元测试是针对程序中的模块或构件，主要揭露编码阶段产生的错误

• 集成测试针对集成的软件系统，主要揭露设计阶段产生的错误

• 确认测试是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误

• 对于基于计算机系统中的软件，还需将它集成到基于计算机系统中，并进行系统测试，以揭露不符合系统工程中对软件要求的错误

回归测试

回归测试就是对已经进行过测试的测试用例子集的重新测试，以确保对程序的改变和修改，没有传播非故意的副作用

$\alpha$α 测试和 $\beta$β 测试

• α测试是由一个用户在开发者的场所进行的，软件在开发者对用户的 “指导下” 进行测试。经 α 测试后的软件称为 β 版软件

• β 测试是由软件的最终用户在一个或多个用户场所进行的，与 α测试不同，开发者通常不在测试现场，因此，β 测试是软件在一个开发者不能控制的环境中的 “活的” 应用，用户记录所有在 β 测试中遇到的（真正的或想象的）问题，并定期把这些问题报告给开发者，在接到 β 测试的问题报告后，开发者对软件进行最后的修改，然后着手准备向所有的用户发布最终的软件产品

Chapter 14-Web工程

Web 工程提倡使用合理的、科学的工程和管理原则，用严密的、系统的方法来开发、发布和维护 Web 系统。

Chapter 15-软件维护与再工程

软件演化是指软件在交付以后，对软件进行的一系列活动的总称。

软件演化：软件的维护、软件再工程。

• 软件维护阶段覆盖了从软件交付使用到软件被淘汰为止的整个时期。软件的开发时间可能需要一、二年，甚至更短，但它的使用时间可能要经历几年或几十年。

• 再工程的主要目的是为遗留系统转化为可演化系统提供一条现实可行的途径，是在软件生命周期终止后开始的一个新的阶段。

再工程的概念

• ****（reverse engineering）：指在软件生存周期中，将软件的某种形式描述转换成更抽象形式的活动

• 重构（restructuring）：指在同一抽象级别上转换系统的描述形式。如把 C++ 程序转换成 Java 程序

• 设计恢复（design recovery）：指借助工具从已有程序中抽象出有关数据结构设计、总体结构设计和过程设计的信息。

为什么要进行再工程

• 维护一行源代码的代价可能是最初开发该行源代码代价的14-20倍；同时重新设计软件体系结构时使用了现代设计概念，它对将来的维护会有很大的帮助；现有的程序版本可以作为软件原型使用，开发生产率可以大大高于平均水平；用户具有较多使用该软件的经验，因此，能够很容易地搞清新的变更需求和变更的范围；另外，利用****和再工程的工具，可以使一部分工作自动化；在完成预防性维护的过程中还可以建立起完整的软件配置。

Chapter 16-软件项目管理

项目管理是通过项目经理和项目组织的努力，运用系统理论的方法对项目及其资源进行计划、组织、协调、控制，旨在实现项目的特定目标的管理方法体系

(软件)项目管理的基本内容： 项目定义、项目计划、项目执行、项目控制、项目结束

软件项目管理的关注点(4P)

• 人员(People)

  • 人员是软件工程项目的基本要素和关键因素

  • 在对人员进行组织时，有必要考虑参与软件过程(及每一个软件项目)的人员类型

• 产品(Product)

  • 定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等

• 过程(Process)

  • 通常将项目分解为任务—子任务等，其分解准则是基于软件工程的过程

• 项目(Project)

  • 采用科学的方法及工具对项目基本内容进行管理

软件项目管理中的五类人员

• 项目管理人员

  • 负责软件项目的管理工作，其负责人通常称为项目经理

• 高级管理人员

  • 可以是领域专家，负责提出项目的目标并对业务问题进行定义

• 开发人员

  • 掌握了开发一个产品或应用所需的专门技术，可胜任包括需求分析、设计、编码、测试、发布等各种相关的开发岗位

• 客户

  • 一组可说明待开发软件的需求的人，也包括与项目目标有关的其他风险承担者

• 最终用户

  • 产品或应用提交后与产品/应用进行交互的人

McCall模型