软件工程读书笔记
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
13.系统流程图
14.盒图
15.PAD图：
16.判定表：一张判定表由四部分组成，左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。
17.判定树：判定表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系
实现
18.实现=编码+测试
确定线性独立路径的基本集合：独立路径至少包含一条在定义该路径之前不曾用过的边。复杂度是独立路径上界
设计可强制执行基本集合中每条路径的测试用例。
条件测试：
循环测试：简单循环；嵌套循环；串接循环
20.黑盒测试：功能测试
等价划分
有效输入
无效输入
有效输出
无效输出
边界值分析
选取刚好等于、稍小于和稍大于等价类边界值
错误推测
错误推测法在很大程度上靠直觉和经验进行。
维护
21.软件维护：就是在软件已经交付使用之后，为了改正错误或满足新的需求而修改软件的过程。
改正性维护
适应性维护
完善性维护
预防性维护
22.软件的可维护性：维护人员理解、改正、改动或改进这个软件的难易程度。
23.决定软件可维护性的因素：
a)1.可理解性
b)2.可测试性
一图
二图
三图
4.数据字典
关于数据的信息的集合，即对DFD图中包含的元素的定义的集合。
数据字典的用途是供人查阅不了解的条目的解释。提供分析设计过程中关于数据的描述。
需求分析
5.ER模型
ER图中包含实体(即数据对象)、关系和属性三种基本成分。
6.状态转换图
通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。
26.面向对象建模：
描述系统数据结构的对象模型
描述系统控制结构的动态模型
描述系统功能的功能模型
27.用例模型：用用例图建立起来的系统模型称为用例模型。用例模型描述的是外部行为者所理解的系统功能。用例模型的建立是系统开发者和用户反复讨论的结果，他描述了开发者和用户对需求规格所达成的共识。
28.用例图包含的模型元素：
7.IPO图：
总体设计
8.耦合和内聚：松散耦合高内聚
耦合衡量不同模块彼此间互相依赖(连接)紧密程度；
内聚衡量一个模块内部各个元素彼此结合的紧密程度。
9.层次图(H图)
在层次图中一个矩形框代表一个模块，框间的连线表示调用关系(位于上方的矩形框所代表的模块调用位于下方的矩形框所代表的模块)
10.HIPO图=H图+IPO图
19.白盒测试：结构测试
Байду номын сангаас逻辑覆盖
语句覆盖。每个语句
判定覆盖。每个语句+每个分支
条件覆盖。每个语句+每个判定表达式的每个条件
判定/条件覆盖
条件组合覆盖。每个判定表达式的每个条件的组合
点覆盖（语句覆盖）
边覆盖（判定覆盖）
路径覆盖。每条路径
控制结构测试
基本路径测试：
画流图。
计算流图环形复杂度：节点数（出度大于2的点）+1或边-点+2
10.螺旋模型：
在每个阶段之前都增加了风险分析过程的快速原型模型。
优点：对可选方案和约束条件的强调有利于已有软件的重用；减少了过多测试或测试不足带来的风险；维护只是一个周期；风险驱动。
11.瀑布模型：
面向对象
迭代
无缝
可行性分析
1.可行性分析任务
技术可行性
经济可行性
操作可行性
法律可行性
2.可行性分析过程
系统。方框
行为者。线条人
用例。椭圆
用例之间的关系，包括扩展和使用，都是泛化的两种不同形式。5连线
29.用例是一个类，它代表一类功能而不是使用该功能的某个具体实例。
用例的实例是系统的一种实际使用方法，通常把用例的实例称为脚本。
面向对象分析
30. ATM对象模型
8.快速原型模型：
快速建立起可以运行的程序，其功能往往是最终产品功能的子集。
特点：通过原型系统获取客户要求，一旦需求确定，原型将被抛弃。
9.增量模型：
把软件产品作为一系列增量构件来设计、编码、集成和测试。
优点：能在最早的时间把最新的功能提交给客户；减少客户对全新软件的冲击。
缺点：开发困难，设计阶段必需有一个好的体系结构
c)3.可修改性
d)4.可移植性
e)5.可重用性
24.可维护性复审：在软件工程过程的每个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。
面向对象方法学引论
25.面向对象有点：
与人类习惯的思维方法一致
稳定性好
可重用性好
较易开发大型软件产品
可维护性好
可行性分析
需求分析
概要设计
详细设计
编码和单元测试
综合测试
维护
6.软件过程
生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。
7.瀑布模型：
阶段间具有顺序性和依赖性
推迟实现的观点
质量保证的观点，文档驱动
优点：文档驱动的规范坏，每个阶段的仔细验证。
缺点：通过文档与客户沟通，最终产品可能不能真正满足客户需求。
1.软件危机
在计算机软件的开发和维护过程中所遇到的一系列严重问题。
2.软件危机的表现
–软件成本日益增长
–开发进度难以控制
–软件质量差
–软件维护困难
–软件开发速度跟不上计算机发展速度
3.软件危机的原因
–技术原因
•软件规模越来越大
•软件复杂度越来越高
–管理原因
•软件开发缺乏正确的理论指导，过分依靠个人技巧和创造性
11.结构图
a)结构图中带注释的箭头表示模块调用过程中来回传递的信息。
b)尾部是空心圆表示传递的是数据，实心圆表示传递的是控制信息。
判定为真时调用A，为假时调用B模块M循环调用模块A，B，C
详细设计
12.结构化程序设计：
如果一个程序的代码块仅仅通过顺序、选择和循环这三种控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。
•对用户需求没有完整准确的认识，就匆忙着手编写程序
4.软件工程
1)将系统化、规范化、可量化的工程原则和方法，应用于软件的开发、运行和维护。
2)对1)中方法的理论研究。
5.生命周期
软件生命周期由软件定义、软件开发和运行维护三个时期组成，每个时期又可进一步划分成若干个阶段，每个阶段有各自的任务。
问题定义
复查系统规模和目标
研究目前正在使用的系统
导出新系统的高层逻辑模型
进一步定义问题
导出和评价供选择的解法
推荐行动方针
草拟开发计划
书写文档提交审查
3.系统流程图
–概括描绘物理系统的传统工具
–用图形符号，以黑盒子形式描述组成系统的每个部件
–程序、文档、数据库、人工过程
3.数据流图(DFD)
描绘信息流和数据从输入移动到输出的过程中所经受的变换。
14.盒图
15.PAD图：
16.判定表：一张判定表由四部分组成，左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。
17.判定树：判定表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系
实现
18.实现=编码+测试
确定线性独立路径的基本集合：独立路径至少包含一条在定义该路径之前不曾用过的边。复杂度是独立路径上界
设计可强制执行基本集合中每条路径的测试用例。
条件测试：
循环测试：简单循环；嵌套循环；串接循环
20.黑盒测试：功能测试
等价划分
有效输入
无效输入
有效输出
无效输出
边界值分析
选取刚好等于、稍小于和稍大于等价类边界值
错误推测
错误推测法在很大程度上靠直觉和经验进行。
维护
21.软件维护：就是在软件已经交付使用之后，为了改正错误或满足新的需求而修改软件的过程。
改正性维护
适应性维护
完善性维护
预防性维护
22.软件的可维护性：维护人员理解、改正、改动或改进这个软件的难易程度。
23.决定软件可维护性的因素：
a)1.可理解性
b)2.可测试性
一图
二图
三图
4.数据字典
关于数据的信息的集合，即对DFD图中包含的元素的定义的集合。
数据字典的用途是供人查阅不了解的条目的解释。提供分析设计过程中关于数据的描述。
需求分析
5.ER模型
ER图中包含实体(即数据对象)、关系和属性三种基本成分。
6.状态转换图
通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。
26.面向对象建模：
描述系统数据结构的对象模型
描述系统控制结构的动态模型
描述系统功能的功能模型
27.用例模型：用用例图建立起来的系统模型称为用例模型。用例模型描述的是外部行为者所理解的系统功能。用例模型的建立是系统开发者和用户反复讨论的结果，他描述了开发者和用户对需求规格所达成的共识。
28.用例图包含的模型元素：
7.IPO图：
总体设计
8.耦合和内聚：松散耦合高内聚
耦合衡量不同模块彼此间互相依赖(连接)紧密程度；
内聚衡量一个模块内部各个元素彼此结合的紧密程度。
9.层次图(H图)
在层次图中一个矩形框代表一个模块，框间的连线表示调用关系(位于上方的矩形框所代表的模块调用位于下方的矩形框所代表的模块)
10.HIPO图=H图+IPO图
19.白盒测试：结构测试
Байду номын сангаас逻辑覆盖
语句覆盖。每个语句
判定覆盖。每个语句+每个分支
条件覆盖。每个语句+每个判定表达式的每个条件
判定/条件覆盖
条件组合覆盖。每个判定表达式的每个条件的组合
点覆盖（语句覆盖）
边覆盖（判定覆盖）
路径覆盖。每条路径
控制结构测试
基本路径测试：
画流图。
计算流图环形复杂度：节点数（出度大于2的点）+1或边-点+2
10.螺旋模型：
在每个阶段之前都增加了风险分析过程的快速原型模型。
优点：对可选方案和约束条件的强调有利于已有软件的重用；减少了过多测试或测试不足带来的风险；维护只是一个周期；风险驱动。
11.瀑布模型：
面向对象
迭代
无缝
可行性分析
1.可行性分析任务
技术可行性
经济可行性
操作可行性
法律可行性
2.可行性分析过程
系统。方框
行为者。线条人
用例。椭圆
用例之间的关系，包括扩展和使用，都是泛化的两种不同形式。5连线
29.用例是一个类，它代表一类功能而不是使用该功能的某个具体实例。
用例的实例是系统的一种实际使用方法，通常把用例的实例称为脚本。
面向对象分析
30. ATM对象模型
8.快速原型模型：
快速建立起可以运行的程序，其功能往往是最终产品功能的子集。
特点：通过原型系统获取客户要求，一旦需求确定，原型将被抛弃。
9.增量模型：
把软件产品作为一系列增量构件来设计、编码、集成和测试。
优点：能在最早的时间把最新的功能提交给客户；减少客户对全新软件的冲击。
缺点：开发困难，设计阶段必需有一个好的体系结构
c)3.可修改性
d)4.可移植性
e)5.可重用性
24.可维护性复审：在软件工程过程的每个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。
面向对象方法学引论
25.面向对象有点：
与人类习惯的思维方法一致
稳定性好
可重用性好
较易开发大型软件产品
可维护性好
可行性分析
需求分析
概要设计
详细设计
编码和单元测试
综合测试
维护
6.软件过程
生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。
7.瀑布模型：
阶段间具有顺序性和依赖性
推迟实现的观点
质量保证的观点，文档驱动
优点：文档驱动的规范坏，每个阶段的仔细验证。
缺点：通过文档与客户沟通，最终产品可能不能真正满足客户需求。
1.软件危机
在计算机软件的开发和维护过程中所遇到的一系列严重问题。
2.软件危机的表现
–软件成本日益增长
–开发进度难以控制
–软件质量差
–软件维护困难
–软件开发速度跟不上计算机发展速度
3.软件危机的原因
–技术原因
•软件规模越来越大
•软件复杂度越来越高
–管理原因
•软件开发缺乏正确的理论指导，过分依靠个人技巧和创造性
11.结构图
a)结构图中带注释的箭头表示模块调用过程中来回传递的信息。
b)尾部是空心圆表示传递的是数据，实心圆表示传递的是控制信息。
判定为真时调用A，为假时调用B模块M循环调用模块A，B，C
详细设计
12.结构化程序设计：
如果一个程序的代码块仅仅通过顺序、选择和循环这三种控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。
•对用户需求没有完整准确的认识，就匆忙着手编写程序
4.软件工程
1)将系统化、规范化、可量化的工程原则和方法，应用于软件的开发、运行和维护。
2)对1)中方法的理论研究。
5.生命周期
软件生命周期由软件定义、软件开发和运行维护三个时期组成，每个时期又可进一步划分成若干个阶段，每个阶段有各自的任务。
问题定义
复查系统规模和目标
研究目前正在使用的系统
导出新系统的高层逻辑模型
进一步定义问题
导出和评价供选择的解法
推荐行动方针
草拟开发计划
书写文档提交审查
3.系统流程图
–概括描绘物理系统的传统工具
–用图形符号，以黑盒子形式描述组成系统的每个部件
–程序、文档、数据库、人工过程
3.数据流图(DFD)
描绘信息流和数据从输入移动到输出的过程中所经受的变换。