软件工程导论 张海藩编著 考试范围及各章重点

第一章

1、CASE(Computer Aided Software Environment)

2、软件危机的概念P1-2：指在软件开发和维护过程中所遇到的一系列严重问题。（如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件）

3、产生软件危机的原因P3：一方面与软件本身有的特点有关，另一方面也和软件开发与维护的方法不正确有关。

4、消除软件危机的途径P5：既要有技术措施（方法 和工具），又要有必要的组织管理措施 5、软件工程支撑环境P5：如果把各个阶段使用的软件工具有机地集合成一个集体，支持软件开发的全过程。

6、软件工程的定义P5：是指导计算机软件开发和维护的一门工程学科。

具体的定义：①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过

程，也就是把工程应用与软件；②研究①中提到的途径。

7、软件工程方法学P9-10：包含三个要素：方法、工具和过程。最广泛的方法学包括传统方法学和面向对象方法学。

传统方法学：也称为生命周期方法学或结构化范型。主要是把软件生命周期的全过程

一次划分为若干个阶段，然后顺序地完成每个阶段的任务。

面向对象方法学：4个要点（对象、类、继承、封装性） 8、软件生命周期3个时期 P13：软件定义、软件开发、软件维护

软件定义阶段：确定开发过程的总任务；工程的可行性；实现工程目标应采用的策略；系统必须完成的功能；估计资源和成本。

软件开发阶段：总体设计，详细设计（前两个阶段又称系统设计），编码和单元测试，综合测试（后两个阶段又称系统实现）。 9、三个模型的优缺点：

瀑布模型（带反馈环）P15

优点：①可强迫开发人员采用规范的方法；②严格规定了每个阶段必须提交的文档；③要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。 缺点：由于是一种文档驱动的模型，最终开发出的软件产品可能并不是用户真正需要的。 快速原型模型（不带反馈环）P17

可以通过快速构建起一个在计算机上运行的原型系统，让用户试用原型并收集用户反馈意见的办法，获取用户的真实需求。本质是“快速”。

增量模型P17

具有可在软件开发的早期阶段使投资获得明显回报和较易维护的优点，但是，要求软件具有开放的结构是使用这种模型时的固有的困难。 第二章

1、数据流图的定义（DFD）P40：是一种图形化技术，描绘信息流和数据从输入移动到输出过程中所经受的变换。无具体物理部件，只是描绘数据在软件中流动和被处理的逻辑过程。在设计时值考虑系统必须完成的基本逻辑功能，完全不考虑具体怎么样实现。描绘数据流向，而不应该描绘出现啊某个数据流的条件。

2、数据流图的符号P41：

正方形（或立方体）——数据的源点或终点 圆角矩形（或圆形）——交换数据的处理 开口矩形（或两条平行线）——数据存储 → ——数据流，即特定数据的流动方向

3、数据字典的作用P47：在软件分析和设计的过程中给人提供关于数据的描述信息。 4、数据字典由对4类元素的定义组成P47：①数据流；②数据流分量（即数据元素）；③数据存储；④处理

本章注意点：

1、系统流程图P39 2、数据流图P44

3、数据字典P48的符号及P的习题5

第三章

1、需求分析的任务P56：

确定随系统的综合要求（①功能需求；②性能需求；③可靠性和可用性需求；④出错处理需求；⑤接口需求；⑥约束；⑦逆向需求；⑧将来可能提出的需求） 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划

2、实体—联系图中关系的区别P63： 一对一联系（1 ：1） 一对多联系（1 ：N） 多对多联系（M ：N）

3、验证软件需求的正确性的4个方面P70：

一致性 所有需求必须是一致的，任何一条需求不能和其他需求相互矛盾。 完整性 需求必须是完整的，规格说明书应包括用户需求的每个功能。 现实性 用现有的硬件技术或软件技术基本上能实现的。 有效性 需求是正确有效的，确实能解决用户面对的问题。

4、验证软件需求的方法P70：①验证需求的一致性；②验证需求的现实性；三验证需求的

完整性和有效性。

本章注意点：

1、画实体—联系图P 2、画状态图P67

第五章

1、模块程度的度量标准P97：内聚和耦合 （高内聚，低耦合）

2、耦合的概念P97：是对一个软件结构内不同模块之间互连程度的度量。

数据耦合 两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据（低耦合，

系统中至少必须存在数据耦合）

控制耦合 传递的信息中有控制信息（有时控制信息以数据的形式出现）（中等耦合） 特征耦合 把整个数据结构作为参数传递而被调用的模块只需使用其中一部分数据元素 公共环境耦合 两个或者多个模块通过一个公共数据环境相互作用

（设计原则：尽量使用数据耦合，少用控制耦合和特征耦合，公共环境耦合的范围，完全不用内容耦合。）

3、内聚的概念P98：标志着一个模块内各个元素彼此结合的紧密程度，是信息隐藏和局部化概念的自然扩展。 4、启发规则P100：

①改进软件结构提高模块性 ②模块规模适中

③深度、宽度、扇入和扇出都适中

深度：软件结构中控制的层数，标志系统的大小和复杂度。 宽度：软件结构内同一层次上的模块总数的最大值。 扇出：是一个模块直接控制的模块数目。

扇入：表明有多少个上级模块直接调用它。扇入越大，共享该模块的上级模块的数目

越多。

5、模块的作用域应在控制域之内P101：所有受判定影响的模块应都从属于做出判定的那个模块，最好局限于做出判定的那个模块本身及它的直属下级模块。

6、交换流的概念P105 图5.8 ：信息沿输入通路进入系统，同时由外部形式变换成内部形式，进入系统的信息通过变换中心，经过加工处理以后再沿输出通路变换成外部形式离开软件系统。

7、事务流的概念 P105 图5.9 ：数据沿输入通路到达一个处理T，这个处理根据输入数据的类型在若干个动作序列中选出一个执行。

本章注意点：

1、能够举出耦合的例子

2、判断区别交换流和事务流

第六章

1、系统响应时间的概念P120：指从用户完成某个控制动作，到软件给出预期的响应之间的这段时间。有两个重要属性，分别是长度和易变性。 2、McCabe方法（重点！！！ 怎样把程序流程图映射成流图）P137-139 流图中圆代表结点，一个圆代表一条或多条语句。程序流程图中的处理框和菱形判定框，即为流图中的结点，在流图中一条边必须终止于一个结点。 3、计算环形复杂度的方法P139-140： ①流图中的区域数=环形复杂度

②某流图G的复杂度V(G)＝边数 － 结点数 ＋2 ③某流图G的复杂度V(G)＝判定结点的数目＋1 本章注意点：

1、画判定树P128及P142的习题7 2、把程序流程图映射成流图P137-139

第七章

1、测试的定义及目的P150：

①测试是为了发现程序中的错误而执行的过程。

②好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。 ③成功的测试是发现了至今为止尚未发现的错误的测试。 2、测试方法P151：黑盒测试 白盒测试

黑盒测试：把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。

白盒测试：把程序看作一个透明的白盒子，测试者完全知道程序的结构和处理算法。 3、测试步骤P151（要搞清楚）：

①模块测试（概念要写得出来）每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有互相依赖关系。

②子系统测试 ③系统测试 ④验收测试 ⑤平行运行

4、回归测试P160：指重新执行已经做过的测试的某个子集，以保证由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误的测试活动。

5、逻辑覆盖P162：主要掌握语句覆盖、判定覆盖和条件覆盖

语句覆盖：选择足够多的测试数据，使被测程序中的每个语句至少执行一次

判定覆盖：不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该

至少执行一次，也就是每个判定的每个分支都至少执行一次

条件覆盖：不仅每个语句至少执行一次，而且使判定表达式的每个条件都取到各种可能的结果。

6、等价划分P172：是一种黑盒测试，把程序的输入域划分成若干个数据类，据此到处测试用例。

7、边界值分析P175：

8、调试途径：①蛮干法 ②回溯法 ③原因排除法 本章注意点：

1、分别设计测试用例（白盒测试技术中的逻辑覆盖）P162-163

第八章

小结P200：

软件维护包括4类活动：①为了纠正正在使用过程中暴露出来的错误而进行的改正性维

②为了适应外部环境的变化而进行的适应性维护 ③为了改进原有的软件而进行的完善性维护

④为了改进将来的可维护性和可靠性而进行的预防性维护

第九章

1.面向对象的方法学方程P205：

OO=objects+classes+inheritance+communication with messages

对象 类 继承 消息

2、面向对象方法学的优点P205：①与人类习惯的思维方法一致 ②稳定性好 ③可重用性好 ④较易开发大型软件产品 ⑤可维护性好 3、其他概念P211-214：

类；实例；消息；方法；封装；继承；多态性（什么叫封装性等概念）

4、对象模型的概念P216：表示静态的，结构化的系统的“数据”性质。它是对模拟客观世界实体的对象以及对象彼此间的关系的映射，描述了系统的静态结构。 5、表示关系的符号（用例子判断 关联 聚集等）P218-220：

关联P219：表示两个类的对象之间存在某种语义上的联系 图9.5等 聚集P220：表示类与类之间的关系是整体与部分的关系 图9.9等 泛化P221：指通常所说的继承关系，是通用元素和具体元素之间的一种分类关系 图9.11 6、动态模型：表示瞬时的、行为化的系统的“控制”性质。它规定了对象模型中的对象的合法变化序列（要求：会画状态图）。

7、功能模型：表示变化的系统的“功能”性质，它指明了系统应该“做什么”，因此更直接地反映用户对目标系统的需求。（要求：会画用例图，会区分系统，用例，行为者这三者。） 8、三种模型之间的关系：功能模型指明了系统应该“做什么”；动态模型明确规定了什么时候（即在何种状态下接受了什么事件的出发）做；对象模型则定义了做事情的实体。

本章注意点：

1、画图：动态模型 图9.16 图9.17

第十章

1、3个子模型与5个层次P232：静态结构（对象模型）、交互次序（动态模型）和数据变换（功能模型）。复杂问题的对象模型的5个层次：主题层；类与对象层；结构层；属性层；服务层

2、ATM系统 图10.2 图10.8

3、脚本的概念P247：指系统在某一执行期间内出现的一系列事件。脚本描述用户（或其他外部设备）与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。

第十三章

1.软件过程的输出信息可分为三类P329： ①计算机程序（源代码和可执行程序）

②描述计算机程序的文档（供技术人员或用户使用） ③数据（程序内包含的或在程序外的）

2.版本控制的概念P330：联合使用规程和工具，一管理在软件工程过程中所创建的配置对象的不同版本。