教材：《软件工程导论（第六版）》 张海藩 牟永敏 著

一、 软件工程学概述

1. 软件危机及其概念

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

典型表现：

• 1） 估计不准：对软件开发成本和进度的估计常常很不准确。
• 2） 不满意：用户对“已完成的”软件系统不满意。
• 3） 质量不可靠：软件产品的质量往往不可靠。
• 4） 不可维护：软件常常不可维护。
• 5） 文档不适当：软件通常没有适当的文档资料。
• 6） 成本上升：软件成本所占比例逐年上升。
• 7） 供不应求：软件开发生产效率提高的速度，远远跟不上计算机应用普及深入的趋势。

原因：

• 1） 与软件自身特点有关
• 2） 软件开发维护方法不正确

2. 软件工程方法学（传统方法学、面向对象方法学）

传统方法学：采用结构和技术来完成软件开发的各项任务，并使用适当的软件工具或软件工程环节来支持结构化技术的运用。传统方法学仍然是软件开发过程中广泛使用的软件工程方法学。

面向对象方法学：把数据和行为看成同等重要，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。

特点：

• 1）把对象作为融合了数据及在数据上的操作行为的统一的软件构件。
• 2）把所有的对象都划分成类
• 3）按照父类与子类的关系，把若干个相关类组成一个层次结构的系统
• 4）对象彼此间仅能通过发送消息互相联系

3. 软件工程本质特性

• 1） 软件工程关注于大型程序的构造
• 2） 软件工程的中心课题是控制复杂性
• 3） 软件经常变化
• 4） 开发软件的效率非常重要
• 5） 和谐地合作是开发软件的关键
• 6） 软件必须有效地支持他的用户
• 7） 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品

4. 软件工程三要素（方法、工具、过程）

方法：完成软件开发的各项任务的技术方法，回答“怎样做”的问题

工具：为运用方法二提供的自动或半自动的软件工程支撑环境

过程：为了获得高质量的软件所需完成的一系列任务的框架，规定了完成各项任务的工作步骤

5. 软件过程模型

1） 瀑布模型

特点：

• 1* 阶段间具有顺序性和依赖性
• 2* 推迟实现的观点
• 3* 质量保证的观点

优点：

• 1* 可强迫开发人员采用规范的方法
• 2* 严格地规定了每个阶段必须提交的文档
• 3*要求每个阶段交出的产品都必须经过质量保证小组的仔细验证

缺点：瀑布模型是文档驱动的是它的主要缺点

2） 快速原型模型
优点：不带反馈环，基本上是线性顺序进行开发

3） 增量模型
优点：短时间内可交付完成部分工作的产品、逐步增加产品功能可使用户逐步适应新产品。

缺点：增量构件不能破坏已有产品、软件体系架构必须开放。

4） 螺旋模型
螺旋模型的优势在于它是风险驱动的，但是这也是弱点，除非软件开发人员具有丰富的风险评估经验，否则将出现正真的风险：当项目实际上正在走向灾难时，开发热暖可能还认为一切正常。
螺旋模型主要适用于复杂的、大规模的软件项目。

5） 喷泉模型
优点：

• 1* 各个阶段没有明显的界限，开发人员可以同 步进行开发
• 2* 提高软件项目开发效率，节省开发时间

6. 软件维护的目的

7. 软件工程基本原理

• 1） 用分阶段的生命周期计划严格管理
• 2） 坚持进行阶段评审
• 3） 实行严格的产品控制
• 4） 采用现代化程序设计技术
• 5） 结果应能清楚地审查
• 6） 开发小组人员应少而精
• 7） 承认不断改进软件工程实践地重要性

二、 可行性研究

1. 可行性研究的目的、关注的方面

目的：用最小的代价在尽可能短的时间内确定问题是否能够解决。

关注的方面：

• 技术可行性
• 经济可行性
• 操作可行性

2. 可行性研究中的图的作用及绘制

系统流程图：
系统流程图是概括地描述物理系统的工具。
系统流程图表达的是数据在系统各部件之间流动的情况。
系统流程图是物理数据流图，而不是程序流程图。

数据流图：
数据流图是系统逻辑功能的图形表示，它描绘信息流和数据从输入移动到输出的过程所经受的变换。
设计数据流图时只需考虑系统必须完成的基本逻辑功能，不需要考虑具体实现。

数据字典：
数据字典是关于数据信息的集合，也就是对数据流图中包含的所有元素的定义的集合。

数据流图和数据字典共同构成系统的逻辑模型。

3. 常用成本估计的方法

• 1） 代码行技术
  在估计出源代码行数后，用每行代码的平均成本乘以行数就可以确定软件的成本，每行代码的平均成本主要取决于软件的复杂程度和工资水平。

  2） 任务分解技术
  将软件开发工程分解为若干个独立的任务，分别估计每个独立任务的成本，累加起来即为开发任务的成本。
  估计每个任务的成本时，通常线估计完成该任务需要用的人力（以每人/月为单位），再乘以每人每月的平均工资而得出每个任务的成本。

  3） 自动估计成本技术
  采用自动估计成本的软件，但这种技术必须要有长期搜集的大量历史数据为基础，且需有良好的数据库系统支持。

成本/效益分析方法：
第一步是估计开发成本、运行费用和新系统将带来的收益。
运行费用取决于系统的操作费用（人数、工作时间、小 的物资等）和维护费用。
系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的费用。
应合理估计软件的寿命。
应考虑货币的时间价值。

4. 货币的时间价值

假设年利率为i，如果现在存入P元，则n年后可以得到的钱数为：
F=P(1+i)n
那么这些钱的现在价值是：
P=F/(i+1)n

三、 需求分析

1. 获取需求的主要方式

1） 访谈

• 1* 正式访谈（提出事先准备好的问题）
• 2* 非正式访谈（提出开放性问题，鼓励客户表达想法）
• 3* 发放调查表
• 4* 使用情景分析技术

2） 面向数据流自顶向下求精

3） 简易的应用规格说明书
先通过初步访谈初步确定待解决的问题，开发者与用户分别写出产品需求，再与会讨论，添加、删除对象、约束条件等，与会人员一致确定完整的列表后，将与会者分成更小的组，每个小组分到列表中的一个项目，针对这个项目指定小型规格说明。最后每个小组展示自己的小型规格说明，与会者加以讨论、修改，最终确定一套确认标准。

4） 快速建立模型

• 1* 主要在展示系统主要功能的可运行程序
• 2* 应实现用户看得见的功能，省略隐含功能
• 3* 应快速、易修改
• 4* 迭代过程：修改——试用——反馈

2. 需求分析的综合要求

1） 功能需求
指定系统必须提供的服务。需求分析应该划分出系统必须完成的所有功能。

2） 非功能需求

• 1* 性能需求

• 指定系统必须满足的定时约束或容量约束。（速度、安全等）

  2* 可靠性和可用性需求

  3* 出错处理需求
  说明系统对环境错误应怎样响应

  4* 接口需求
  应描述应用系统与他的环境通信的格式

  5* 约束

  6* 逆向需求
  说明系统不应该做什么

  7* 将来可能提出的需求
  应明确列出那些虽然不属于当前系统的开发范畴，但是据分析将来很可能会提出的要求

3. 数据的规范化

第一范式数据冗余最大，第五范式数据冗余最小。
范式高带来的影响：

• 1） 需求变化时数据的稳定性较差。
• 2） 需要访问的表增多，速度下降
• 3） 存储同样的数据会需要分解成更多的表

大多数长河选用第三范式比较恰当。

4. E-R图

是一种面向问题的数据模型，需包含3种相互关联的信息：
1） 数据对象

• 1* 是对软件必须理解的复合信息的抽象
• 2* 可以由一组（大于一个）属性来定义的实体都可以被认为是数据对象
• 3*
  数据对象只封装了数据而没有对施加于数据上的操作的引用

2） 数据对象的属性
3） 数据对象彼此间相互联系的关系

四、 总体设计

1. 模块的独立性

1）为什么模块独立性很重要

• 1* 有效的模块化（即独立的模块）比较易于软件的开发
• 2* 独立的模块容易进行测试和维护

2）模块独立程度的两个重要标准度量：内聚 耦合
内聚与耦合时密切相关的，模块内的高内聚往往意味着模块间的松耦合。实践表明内聚更重要。

内聚：衡量一个模块内部各个元素彼此结合的紧密程度。
设计时应力求做到高内聚或中等程度内聚，不适用低内聚。

低内聚：偶然内聚、逻辑内聚、时间内聚

中内聚：

• 过程内聚：一个模块内的处理元素是相关的，而且必须以特定次序执行。
• 通信内聚：模块内所有的元素都是用同一个输入数据和（或）产生同一个输出数据。

高内聚：

• 顺序内聚：一个模块内的处理元素和同一功能密切相关，而且这些处理必须顺序执行（通常一个处理元素的输出数据作为下一个元素的输出数据）。
• 功能内聚：模块内所有处理元素属于一个整体，完成一个单一的功能。功能内聚是最高程度的内聚。

耦合：衡量不同模块彼此之间相互依赖的紧密程度。
软件设计过程中尽可能做到松散耦合。

• 数据耦合： 如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据，则为数据耦合。 数据耦合是低耦合。

• 控制耦合：如果传递的信息有控制信息（尽管有时这种控制信息以数据形式出现），则为控制耦合。 控制耦合是中等程度耦合，增加了系统的复杂度。

• 特征耦合：当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时，就出现特征耦合。

• 公共环境耦合：当两个或多个通过一个公共数据环境相互作用时，他们之间的耦合成为公共环境耦合。
  1* 一个模块仅向公共环境中发送数据，另一个模块只从公共环境中取数据，这种时比较松散的耦合。
  2* 两个模块都既向公共环境中送数据又取数据，这种耦合比较紧密，介于数据耦合和控制耦合之间。

• 内容耦合：这是最高程度的耦合。
  表现：
  1）一个模块访问另一个模块的内部数据
  2）一个模块不通过正常入口而转到另一个模块的内部
  3）两个模块有一部分程序代码重叠（只可能出现在汇编程序中）
  4）一个模块有多个入口

控制耦合的设计原则：

• 1） 尽量使用数据耦合
• 2） 少用控制耦合和特征耦合
• 3） 限制公共环境耦合的范围
• 4） 完全不用内容耦合

2. 启发规则

1） 改进软件结构提高模块独立性

2） 模块规则应该适中

3） 深度、宽度、扇入和扇出都应适当

• 深度：软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。
• 宽度：软件结构内同一层次上的模块总数的最大值。一般说来，宽度越大系统越复杂，对宽度影响最大的因素是模块的扇出。
• 扇出：一个模块直接控制（调用）的模块数目。 扇出不宜过大或过小，一个设计的好典型系统平均扇出应该在3或4（上限为5-9）.
  扇出太大一般因为缺乏中间层次，应适当增加中间层次的控制模块。 扇出太小可以把下级模块进一步分解为若干个子功能模块，或合并到它的上级模块中。
• 扇入：一个模块有多少个上级模块直接调用它，扇入越大则共享该模块的上级模块数目越多，这是好处，但不能违背模块独立性去单纯追求高扇入。
  设计好的软件通常顶层扇入比较高，中层扇入比较少，底层扇入到公共的实用模块中去（底层高扇入）。

4） 模块的作用域应该在控制域之内

5） 力争降低模块接口的复杂度

6） 设计单入口单出口的模块

7） 模块功能应该可以预测

3. 模块的作用域、控制域

作用域：受该模块内一个判定影响的所有模块的集合。

控制域：是这个模块本身以及所有直接或间接从属于它的模块的集合。

在一个设计很好的系统中，所有受判定影响的模块应该都从属于做出判定的那个模块，最好局限于做出判定的那个模块本身以及它的直属下级模块。

4. 面向数据流的设计方法

目标：给出设计软件结构的一个系统化的途径。
可以利用一些映射方法把信息流映射成软件结构。
信息流的类型：

• 变换流：
  信息沿输入通路进入系统，同时由外部形式变为内部形式，进入系统的信息通过变换中心，经过加工处理以后再沿着输出变换成外部形式离开软件系统。

• 事务流： 数据沿着输入通路到达一个处理T，这个处理根据输入数据的类型在若干个动作序列中选出来一个来执行。
  处理T称为事务中心，主要任务为：
  1* 接收输入数据（事务）
  2* 分析每个任务以确定它的类型
  3* 根据事务类型选取一条活动通路

5.变换分析、事务分析

• 变换分析： 变换分析是一系列设计步骤的总称，经过这些步骤把具有变换流特点的数据流按预先确定的模式映射成软件结构。
• 事务分析：
  由事务流映射成的软件结构包括一个接收分支和一个发送分支。映射出接收分支的方法是从事务中心的边界开始，把沿着接收通路的处理映射成模块。
  发送分支的结构包含一个调度模块，它控制下层的所有活动模块。 然后把数据流图中的每个活动流通路映射成与它的特征流相对应的结构。

五、 详细设计

1.过程设计的工具

1） 程序流程图

缺点：

• 1* 诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构
• 2*程序流程图中箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序的精神，随意转移控制。
• 3* 程序流程图不易于表示数据结构

2） 盒图（N-S图）

特点：

• 1* 功能域（即一个特定控制结构的作用域）明确，可以从盒图上一眼就看出来
• 2* 不可能任意转移控制
• 3* 很容易确定局部和全局数据的作用域
• 4* 很容易表现嵌套关系，也可以表示模块的层次结构

3） PAD图

优点：

• 1* 使用表示结构化控制结构的PAD符 所设计出来的程序必然是结构化程序
• 2* PAD图所描绘的程序结构十分清晰，自上而下，自左而右
• 3* 容易将PAD图转为高级语言源程序，可以用软件工具自动完成
• 4* 即可用于表示程序逻辑，又可用于表示数据结构
• 5* PAD图的符 支持自顶向下、逐步求精的方法的使用

4） 判定表
当算法包含多重嵌套的条件选择时，判定表能够清晰地表示复杂地条件组合与应做地动作之间地对应关系。

一张判定表由4部分组成：

• 1* 左上部列出所有条件
• 2* 左下部是所有可能做的动作
• 3* 右上部是表示各种条件组合的一个矩阵
• 4* 右下部是和每种条件组合相对应的动作

5） 判定树
判定表的变种，它能清晰地表示负责的条件组合与应做的动作之间的对应关系。

6） 过程设计语言（PDL）
过程设计语言也成为伪码。

特点：

• 1* 关键字的固定语法，它提供了结构化控制结构、数据说明和模块化的特点。
• 2* 自然语言的自由语法，它描述处理特点
• 3* 数据说明的手段。应该既包括简单的数据结构（变量、数组等），又包括复杂的数据结构（链表或层次数据结构等）。
• 4* 模块定义和调用的技术，应该提供各种接口描述模式。

优点：

• 1* 可以作为注释插在源程序中间
• 3* 已有的自动处理程序存在，而且可以自动由PDL生成程序代码。

缺点：

• 不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时不如判定表简单。

2.Jackson图的特点

优点：

• 1） 便于表示层次结构，而且是对结构进行自顶向下分解的有力工具
• 2） 形象直观可读性好
• 3） 技能表示数据结构也能表示程序结构

缺点：

• 1） 用这种图形工具表示选择或重重复结构时，选择条件或循环结束条件不能直接在图上表示出来，影响了图的表达能力，也不易直接把图翻译成程序
• 2） 框间连线为斜线，不易在行式打印机上输出。

3. 流图

流图实质上是“退化了的”程序流程图，描绘程序的控制流程，不表现对数据的具体操作以及分支或循环的具体条件。
计算环形复杂度：

• 1） 流图中线性无关的区域数等于环形复杂度
• 2） V(G)=E-N+2 ，E是边的条数，N是节点数
• 3） V(G)=P+1，P是流图中判定节点的个数

六、 实现

1.实现阶段的主要任务

通常把编码和测试统称为实现。

语言选择的标准：

• 1） 系统用户的要求
• 2） 程序员的知识
• 3） 可以使用的编程程序
• 4） 软件可移植性要求
• 5） 可以得到的软件工具
• 6） 软件的应用领域
• 7） 工程规模

2.软件测试的类型及基本步骤、顺序

黑盒测试：已知产品的功能，检验每个功能是否能正常使用。把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程。只检查程序功能是否能按照规格说明书的规定正常使用，程序能否适当地接收输入数据并产生正确的输出信息。黑盒测试又称功能测试。

白盒测试：已知产品的内部工作过程，测试产品内部动作是否按规格说明书的规定正常进行的。把程序看成装在透明的白盒子里，测试者完全知道程序的结构和处理算法，按照程序的内部逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求城阙工作。白盒测试又称为结构测试。

测试步骤（顺序：自上而下）：

• 1） 模块测试（单元测试）
  需要编写驱动程序（即模拟的上层程序）和存根程序（即模拟的下层程序）

• 2） 子系统测试
  目前普遍采用的是渐增式方法。
  分为自顶向下和自底向上两种方式。

  自顶向下集成步骤：
  1* 测试主控制模块
  2* 每次用一个实际模块代换一个存根程序
  3* 在结合进一个模块的同时进行测试
  4* 回归测试 自顶向下不用编写驱动程序。

  自底向上集成的步骤：
  1* 把底层模块组合成实现某个特定软件子功能的族
  2* 写一个驱动程序，协调测试数据的输入和输出
  3* 对由模块组成的子功能进行测试
  4* 去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族

• 3） 系统测试

• 4） 验收测试（确认测试） α测试、β测试

• 5） 平行运行

3.平行运行的目的

平行运行即同时运行新开发出来的系统和将被他取代的系统。

目的：

• 1） 降低风险
• 2） 用户可逐步熟悉新系统
• 3） 验证用户指南与使用手册
• 4） 进行全负荷测试

4.α测试、β测试的区别

α测试：
在受控环境中进行。由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。

β测试：
由软件最终的用户们在一个或多个客户场所进行，开发者通常不在β测试的现场，用户记录测试过程中遇到的问题，并定期将问题 告给开发者进行必要的修改。

七、 面向对象方法学引论

1.对象、类、实例、封装、多态

1） 对象
在应用领域中有意义的、与所要解决的问题有关系的任何事物都可以作为对象。它既可以是具体的物理实体的抽象、人为的概念，或任何有明确边界和意义的东西。

特点：

• 1* 以数据为中心
• 2* 对象是主动的
• 3* 实现了数据封装
• 4* 本质上具有并行性
• 5* 模块独立性好

2） 类
类是对具有相同属性和行为的一个或多个对象的描述。

3） 实例
实例是由某个特定的类所描述的一个具体的对象。

4） 封装
在面向对象的程序中，把数据和实现操作的代码集中起来放在对象内部。

对象具有封装性的条件

• 1* 有一个清晰的边界
• 2* 有确定的接口（协议）
• 3* 受保护的内部实现

5） 多态
多态性是指子类对象可以像父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象。

2.统一建模语言（UML）中的图

静态结构图：
类图、对象图、用况图

交互图：
顺序图、协作图、状态图、活动图

实现图：
构件图、部署图