第一章 软件工程的范畴

软件工程

软件工程是一门学科 目的是生产出没有错误的软件 以工程学的思维去进行软件设计、软件开发、软件软件运维的一种方法论，按时并且在预算范围内交付，满足用户的需求。

软件危机

软件危机指软件产品的质量低得通常不能接受，并且不能够满足交付和预算限制。

传统的生命周期模型的六个阶段

需求阶段

对概念进行细化，提取客户的需求

分析阶段

分析客户的需求并以规格说明文档的形式给出

设计阶段

结构设计：将整体分成各个模块详细设计：设计每一个具体的模块

实现阶段

对各个部分独立进行代码编写和测试

交付后维护

纠错型性维护增强性维护 完善性维护适应性维护

退役

交付后维护的重要性

维护成本远大于开发成本

三个为什么

为什么没有计划阶段

为什么没有测试阶段

为什么没有文档阶段

上述三个阶段在软件开发的过程中是贯穿始终的，因此不能单独拿出来作为一个独立的阶段而存在

面向对象的范型

面向对象的生命周期模型

需求工作流面向对象分析工作流面向对象设计工作流面向对象实现工作流交付后维护退役

和传统范型的主要区别

在面向对象分析工作流中 面向对象的设计方法需要确定产品要做什么的前提之下还需要进行类的提取

第二章 软件生命周期模型

核心工作流

需求工作流分析工作流设计工作流实现工作流测试工作流

核心概念

迭代-递增、米勒法则

各种生命周期模型的比较

第三章 软件过程

软件过程的定义

软件过程是我们生产软件的方式。它包括方法学和隐含的生命周期模型，技术、所使用的工具，以及建造这些软件的人。

核心工作流

需求流分析流设计流实现流测试流

需求流

目标是让开发组织确定客户的需求

分析流

分析和提取需求，让需求以一种更为精确的方式进行描述，解决语言中的可能的歧义性问题。

设计流

细化分析流的制品，直至材料处于程序员可实现的形式。

实现流

用选择的语言实现目标软件产品

测试流

每个开发者和维护者都要负责确保自己的工作是正确的。一旦软件人员确信要给制品是正确的，就将它交个软件质量保证小组进行独立测试。对所有制品都至关重要的一个特性是可追踪性

统一过程的各个阶段

开始阶段

第一次递增 目标是决定是否值得开发目标软件产品 明确提出软件产品是否经济上可行

细化阶段

第二次递增 细化最初需求 细化体系结构，监控风险和细化它们的属性，细化商业案例，以及生成软件项目管理计划

构建阶段

第三次递增 生产软件产品的第一个可行工作版本

转换阶段

第四次递增 确保客户的需求切实得到满足

一维与二维生命周期模型

能力成熟度模型

级别1：初始级

有效的软件过程管理方法本质上没有获得使用世界上大多数的软件组织的软件开发能力成熟度级别仍处于1级

级别2：可重复级

使用了基本的软件项目管理措施，有软件生产文档，但是不够充分

级别3：定义级

过程有充分的软件生产文档，软件开发过程在所有的管理和技术方面都有明确的意义，并在任何可能的地方不断努力改进软件开发过程，用评审方式来保证软件质量

级别4：管理级

组织为每个项目设计了质量目标和生产目标，在软件开发过程中对这两个指标不断测量，当与目标有不可接受的偏移时，采取适当的措施对其进行纠正。

级别5：最优级

目标时持续改进软件的生产过程，用统计质量和过程控制技术对软件组织进行指引。在每个项目中获取到的知识在以后的项目中可以得到不断的利用。开发过程是一个良性循环，从而使软件的质量不断得到提高。

第四章 软件小组

布鲁克斯法则

向一个以及延期的软件项目小组增加人员会使得该项目完成的更晚。

民主小组方法

无我编程

优点：对查找代码错误的积极态度有利于代码质量的提高缺点：经理们可能难以接受无我编程 有着多年编程经验的老手可能不愿意将代码交给新人评判

传统的主程序员小组

特性

专业化等级性

存在的问题

主程序员是一个搞水平的程序员同时也是一个高水平的管理者的结合，这样的人才稀缺备用程序员和编程秘书都很难寻找，因此主程序员小组很难付诸实践

现代化的小组结构

各个小组组织方法总结

第五章 软件开发工具

逐步求精法

尽可能的将细节的定义推延到最后，以便集中精力在重要的事项上

成本-效益分析法

通过对比估计的未来收入和预测的未来成本来确定一个行为过程是否有利可图的方法，确定客户是否应当进行业务计算机化的基本技术，如果确定使用计算机化，应用何种方法来比较各个可选方案的成本和收益。

分治

把不好解决的大问题拆分成一个一个的小问题这样有望更容易解决

软件度量

CASE

数据字典

软件版本

配置控制

建造工具

第六章 测试

质量问题

软件质量保证

SQA小组（质量保证小组）

非执行测试

包括 评审和使用数学方法分析，其中评审包括：

走查管理走查审查

优点：

是检测错误的一个有效途径能够在软件开发早期就发现错误，也就是在修复变得昂贵之前发现错误

缺点：

大型软件相当难于评审设计评审小组经常需要查看设计文档，这就得保证设计文档时刻处于最新、在线状态，否则会严重妨碍评审小组发挥作用

执行测试

测试方面

实用性：在规格说明书允许的条件下使用正确的产品时，满足用户需求的程度可靠性：对产品故障的出现频率和严重性进行测量健壮性：有效输入带来不可接受的结果的可能性以及产品的输入无效时结果的可接受性性能正确性

第七章 从模块到对象

模块的定义

一个或多个邻接的程序语句集合，它有一个名称以便系统的其他部分调用它，并且最好具有自己专用的变量名集，即一个模块单独的代码块组成，它可以像过程、函数或方法一样被调用。

内聚

内聚级别从上往下，一次降低，最好的内聚是信息性内聚，最差的内聚是偶然性内聚

耦合

耦合的级别从上往下依次降低，最好的是数据耦合，最差的是内容耦合，一个好的设计是高内聚，低耦合

数据封装

抽象数据类型

将对同一个数据结构的操作封装成一个类，这个类就是一种抽象数据类型

信息隐藏

对象

多态、继承、动态绑定

第十一章 需求

需求流概述

需求流的整体目标是让开发组织确定客户的需要（而非想要）。达到这个目标的第一步是理解应用域，也就是目标产品应用的特定环境。

业务模型

业务模型是对公司的商业过程进行的描述。建立业务模型的方式有以下几种方式：

访谈

程式化访谈：受限的回答非程式化访谈：自由回答

调查问卷

用例

用例图示例

用例描述示例

快速原型开发

概念

仓促建立的软件，展示目标软件产品的主要功能

第十二章 传统的分析

规格说明文档

规格说明文档是客户和开发者之间的一种合同。它明确规定了产品必须做什么，以及对产品的约束

非形式化规格说明

使用自然语言对规格进行说明会存在歧义性的问题

结构化系统分析

数据流图

数据流图说明

数据流箭头上为名词，表示某个具体的数据数据处理过程必须是动词，表示数据处理的动作

示例

构建实体-关系模型

示例

有穷状态机

转换规则

当前状态与事件→下一个状态当前状态\quad与\quad事件\quad\rightarrow\quad下一个状态 当前状态与事件→下一个状态

Petri网

传统分析阶段面临的挑战

规格说明文档既要是非形式化的，又要是形式化的，非形式化的内容给客户看，形式化的内容给开发人员看。分析和设计之间的界限不够明显，容易跨越

第十三章 面向对象分析

分析流

目标

分析需求流，得到对需求流更深的理解按设计和实现易于维护的的思路描述需求

三种类

实体类：为长期存在的信息建模边界类：为软件产品和它的参与者之间的交互行为进行建模控制类：为复杂的计算和算法建模

抽取实体类

功能建模

提取所有的场景（场景是用例的一个实例）

场景示例

实体类建模

确定实体类和它们的属性，然后确定实体类之间的交互关系和交互行为，以类图的形式提供这些信息

动态建模

确定每个实体类或子类执行的操作或对它们的操作（状态图）

状态图示例

顺序图示例

注意点：1.顺序图最上方是类 不是某个方法 2.顺序图要标好序号 3.顺序图表示消息的传递顺序 应当是有进有出的

通信图示例

第十四章 设计

面向操作的设计

数据流分析

输入最高抽象点

输入失去作为输入的性质并且简单地变为由产品的操作作为内部数据的点

输出最高抽象点

输出与输入相反 是最低点

依据输入最高抽象点和输出最高抽象点 可以简单的讲系统划分为以下三个模块：

输入模块

转换模块

输出模块

结构图示例

说明

结构图的左部为输入部分

结构图右部为输出部分

中间为转换部分

PDL语言—伪代码

面向对象设计

完成类图设计

确定属性的格式分配方法

进行详细设计

PDL描述

第十五章 实现

编程语言的选择

使用成本-效益法进行深入分析

良好的编程实践

使用一致和有意义的变量名

嵌套if语句不超过三层

制定编码标准

集成

自顶向下集成

设计错误能够被较早发现支持错误隔离潜在的可重用部分可能会测试不充分

自底向上集成

操作制品能够被充分测试错误隔离

三明治集成

综合了自顶向下和自底向上集成

三种集成的比较

实现流

用所选的语言实现目标软件产品，大型的软件被分成小一些的子系统，然后由编码小组并行的实现，这些子系统由组件或代码制品组成。

黑盒单元测试技术

等价测试和边界值分析

对于不同的输入，如果能够依据产品规格说明书得到相同的输出，那么这一类输入的测试数据被称为等价类边界值：位于两个等价类之间的输入值

功能测试

根据模块的功能来选择测试数据

玻璃盒单元测试技术

结构测试

语句覆盖

让代码中的每一个语句都能够被测试到不能够保证对分支的所有输出都充分的测试

判定覆盖（分支覆盖）–路径

每个判定True或False都执行一次

示例

条件覆盖–条件

针对判断语句里面的每一个表达式True 和 False各取一次

示例

路径覆盖

测试所有的路径路径数量非常大 几乎不可能实现

完全定义-使用路径覆盖

在每个变量的定义和使用之间的代码路径建立一个测试用例

秩复杂度

二进制判定数+1，本质上是代码制品中的分支数

单元测试技术比较

黑盒测试 白盒测试 代码阅读 三者在发现错误方面同样有效代码走查比其他技术成本要低很多

第十六章 交付后维护

为什么交付后维护是必要的

需要纠正的错误：分析错误、设计缺陷、编码错误、文档错误→\rightarrow→纠错性维护完善性维护适应性维护

第十七章 UML的进一步讨论

类图

:类名/某一具体对象名称‾\underline{:类名/某一具体对象名称}:类名/某一具体对象名称​表示一个实例

前缀+ 表示public属性/方法

前缀- 表示private属性/方法

示例

聚合

局部-整体关系–空心菱形表示（整体丢失 但是局部可以独立存在）

示例

组合

部分-整体关系–实心菱形表示（整体丢失 部分无法单独存在）

示例–棋盘和棋格

关联

它表示类与类之间的连接，它使得一个类知道另一个类的属性和方法。

示例

泛化

继承是泛化的特例（用空心三角形表示）

示例