软件工程（笔记）

一、绪论

软件的定义

软件是计算机系统中与硬件相互依存的另一部分，它保存程序、数据及其相关文档的完整集合。

软件 = 程序 + 数据 + 文档

程序是按事先设计的功能和性能要求执行的指令序列；

数据是使程序能正常操纵信息的数据结构，具体来说包括使系统初始运行所必须的数据如数据库和表的结构及初始的数据，系统运行中所需要的各种代码表、各种标志等。

文档是与程序开发，维护和使用有关的图文材料（是有关于管理、开发、用户、维护人员使用的文档）

软件技术面临的问题

• 规模、复杂性、生产率

软件危机

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题；概括地说，软件危机包含下述两方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。开发软件所需高成本和产品的低质量之间有着尖锐的矛盾，这种现象称做软件危机

表现

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

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

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

软件常常是不可维护的

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

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

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

内在原因：复杂性

软件开发无计划性，项目没有被很好地理解；计划不周，最终导致进度拖延，经费预算上升。

软件需求不充分，开发的软件不能满足用户的需求。

软件开发过程无规范，没有充分的文档资料。

软件可靠性缺少度量的标准，质量无法保证。

软件难以维护，易升级。

解决方法：

组织管理——工程项目管理方法

技术措施——软件开发技术与方法、软件工具

按工程化的原理和方法组织软件开发是软件开发中的问题的一个主要出路。

软件工程

定义

软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件和有关技术及管理方法

把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件

软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科

三要素

方法、过程、工具

中心思想

把软件当做一种工业产品，要求“采用工程化的原理与方法对软件进行计划、开发和维护”

基本原理

确保软件产品质量和开发效率的原理的最小集合

软件开发方法

个性化方法 – 机构化方法 – 面向对象方法 – 软件复用

三种编程范式

过程式编程范型：程序 = 数据结构 + 算法

面向对象编程范型：程序 = 对象 + 消息

基于构件技术的编程范型：程序 = 构件 + 架构

三代软件工程

传统软件工程

结构化分析 – 结构化设计 – 面向过程的编码 – 软件测试

面向对象软件工程

面向对象基本概念：对象 + 类 + 继承 + 消息通信

OO分析与对象抽取 – 对象详细设计 – 面向对象的编码和测试

基于构件的软件工程

领域分析和测试计划定制->领域设计->建立可复用构件库->查找并集成构件

二、软件生存周期与软件过程

软件生存周期

一个软件项目从开始立项起，到废弃不用止，统称为软件的生存周期。

软件生存周期被分为计划、开发、运行三个时期。

由于软件生存周期被划分为较小的阶段，使得因为软件规模增长而大大增加的软件复杂性变得较易控制和管理。

典型的软件生存周期

计划 – 需求分析 – 软件分析 – 软件设计 – 编码 （测试） – 软件测试 – 运行维护

需求分析：（准确回答，系统必须做什么）

提交：软件需求说明书 / 系统功能说明书 / 初步的系统用户手册

软件设计： （回答怎么做的问题）概要设计、详细设计

提交：设计说明书（软件结构图）

程序编写：（具体实现）

提交：源程序清单

软件测试：（挑错）单元测试、组装测试、有限性测试

提交： 测试报告文档（测试计划、测试用例、测试结果）

运行维护

改正性维护、适应性维护、完善性维护

软件过程

围绕软件开发所进行的一系列活动

软件生存周期中的阶段和软件过程中的活动是基本一致的

传统的软件过程：瀑布模型、快速原型模型

---

瀑布模型

基于软件生存周期的线性开发模型

强调软件文档

每一个阶段必须完成规定的文档

每一个阶段都要复审完成的文档

特点

阶段间的顺序性和依懒性、推迟实现的观点、质量保存的观点

顺序性

前一阶段的工作完成后才能执行下一阶段的任务

依懒性

前一阶段的输出文档是下一阶段的输入文档

存在问题

不适合需求模糊的系统，开发初始阶段很难彻底弄清软件需求

需求定义与分析 – 总体设计 – 详细设计 – 编码 – 测试 – 使用维护

快速原型模型

特点

“逼真”的原型可以使用户迅速做出反馈

循环回溯和迭代：非线性模型

使用快速开发工具

种类

渐进型：对原型补充和修改获得最终系统

抛弃型：原型废弃不用

应防止的倾向

舍不得抛弃，从而影响软件质量

软件演化模型（采用渐增式或迭代式的开发方法）：增量模型、螺旋模型、构件集成模型

增量模型

定义

把软件看做一系列相互联系的增量，每次迭代完成一个增量。

增量

小而可用的软件

第一个增量通常是软件的核心

特点

在前面增量的基础上开发后面的增量

每个增量的开发可用瀑布或快速原型模型

每个增量开发的顺序性和总体的迭代性相结合

有利于控制技术风险

螺旋模型

特点

瀑布模型（顺序性、边开发边复审）+ 快速原型（迭代性）

风险分析 – 发现、控制风险

螺旋式周期

计划：确定目标、选择方案，选定完成目标的策略

风险分析：从风险角度分析该策略

开发：启动一个开发活动

评审：评价前一步的结果，计划下一轮的工作

迭代和瀑布的区别

迭代和瀑布的最大的差别就在于风险的暴露时间上

瀑布模型的特点（文档是主体），很多问题在最后才会暴露出来

迭代模型的特点，根据风险列表选择要在迭代中开发新的增量内容，每次迭代完成时都会生成一个经过测试的可执行文件，可核实是否降低了目标风险

构件集成模型

构件

在某个领域中具有通用性，可以复用的软件部件

将可以复用的构件存储起来，形成构件库

特点

面向对象

基于构件库

融合螺旋模型特征

支持软件开发的迭代方法

软件复用

形式化方法模型（基于程序变换和验证技术的软件开发）：转换模型，净室模型

转换模型

开发过程

确定形式化需求规格说明书

进行自动的程序变换

针对形式化开发记录进行测试

特点

形式化软件开发方法

形式化需求规格说明

变换技术

程序自动生成技术

确保之前

净室模型

净室思想

在分析和设计阶段消除错误

在“洁净”状态下实现软件制作

形式化

盒结构表示分析和设计

正确性验证

增量模型

把软件看成一系列的增量

软件过程模型的特点汇总

瀑布模型

线性模型，每一阶段必须完成规定的文档，适合需求明确的中小型软件开发

快速原型

用户介入早，通过迭代完善用户需求，原型废弃不用，适合需求模糊的小型软件开发

增量模型

每次迭代完成一个增量，可用于OO开发，适合容易分块的大型软件开发

螺旋模型

典型迭代模型，重视风险分析，可用于OO开发，适合具有不确定性大型软件开发

构件集成模型

软件开发与构件开发平行进行，适用于领域过程、行业的中型软件开发

转换模型

形式化的规格说明，自动的程序变换系统。属于理想化模型，尚无成熟工具支持

净室模型

形式化的增量模型，在洁净状态下实现软件制作。适合开发团队熟悉形式化方法，中小型软件开发。

统一过程和敏捷过程

统一过程（RUP）

描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动

基本特征是“用例驱动、以架构为中心的和受控的迭代式增量开发”

RUP

初始阶段：该阶段的主要任务包括确定项目范围和边界，识别系统的关键用例，展示系统的候选架构，估计项目费用和时间，评估项目风险。其意图是建立项目的范围和版本，确认业务实现的可能性和项目目标的稳定性。提交结果包括原始的项目需求和业务用例。

制品：构想文档、有关用例模型的调查、初始的业务用例、早期风险评估、显示阶段和迭代的项目计划等制品；

细化阶段：该阶段的主要任务包括分析系统问题领域，建立软件架构基础，淘汰最高风险元素。其意图是对问题域进行分析，建立系统的需求和架构，确认技术实现的可行性和系统架构的稳定性。提交结果包括系统结构及其相关文档、领域模型、修改后的业务用例和整个项目的开发计划。

制品：补充需求分析、软件架构描述、可执行的架构原型

构建阶段：该阶段相对简单一些，其主要任务包括资源管理、控制和流程优化，开发剩余的构件，然后进行构件组装和测试等。其主要意图是增长式开发一个可以交付用户的软件产品。

制品：准备交到最终用户手中的产品，包括具有最初运作能力的在适当的平台上集成的软件产品、用户手册和对当前版本的描述。

提交（迁移）阶段：该阶段的主要任务包括进行β测试，制作发布版本，用户文档定稿，确认新系统，获取用户反馈，培训、调整产品使最终用户可以使用产品。其主要意图是将软件产品提交用户。

每个阶段又分为若干次迭代，每次迭代有一个核心工作流，都会经历需求、分析、设计、实现和测试等活动。

9个核心工作流，分为6个核心过程工作流和3个核心支持流

核心过程工作流：商业建模、需求、分析和设计、实现、测试、部署

核心支持流：配置和变更管理、项目管理、环境

敏捷过程

一个以人为核心、迭代、循序渐进的开发方法，其软件开发过程称为“敏捷过程”

敏捷过程价值观：

个人和交互胜过过程和工具

可以运行的软件胜过面面俱到的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

极限过程

一种轻量级的、敏捷的软件开发方法

4个价值观：交流、简单、反馈、勇气

4个方面改善：加强交流、从简单做起、寻求反馈、用于实事求是

12个核心实践：完整团队、计划对策、测试、简单设计、结对编程、小软件版本、设计改进、持续集成、代码共有、编码标准、系统比喻、可持续的速度

软件可行性研究

目的：

研究项目是否可能实现和值得进行

回答做什么

研究的内容

经济可行性

运行可行性

技术可行性

法律可行性

可行性研究的步骤：

对当前系统进行调查和研究

弄清当前系统

导出新系统逻辑模型

导出新系统的解决方案

设计不同的解决方案

提出推荐的方案

本项目的开发价值

推荐这个方案的理由

编写可行性认证报告

系统概述

可行性分析

结论意见

软件风险分析

风险识别

项目风险

技术风险

商业风险

风险预测

风险发生的可能性

风险发生后的后果

风险的驾驶和监控

三、结构化分析与设计

结构化分析与设计

SP（结构化程序设计）-- SD（结构化设计） – SA （结构化分析）

讨论传统软件工程的系统开发技术，重点放在基于瀑布模型的结构化分析与设计和模块设计上，但不涉及同为传统软件工程的快速原型开发等内容。

SA与SD的流程

结构化分析（工具：DFD数据流图、PSPEC加工策略）-- 分析模型（分层DFD图） + SRS 软件需求规格说明书

结构化设计（工具：SC图）映射 – 初始设计模型（初始SC图）

初始设计模型（初始SC图）优化 – 最终设计模型（最终SC图）

基本任务与指导思想

结构化分析

建立分析模型

编写详情说明

结构化设计

软件设计 = 总体设计 + 详细设计

SC图需要分两步完成：初始SC图、最终SC图

细化和分解

逐步细化，细化的本质就是分解

SA模型的组成与描述

SA模型的描述工具

DFD、PSPEC,这是早期SA模型的基本组成部分
CFD、CSPEC和STD是早期SA模型的扩展成分，适应实时软件的建模需要
ER图，适用于描述具有复杂数据结构的软件数据模型

备注：DFD数据流图、PSPEC加工规格说明/加工策略、STD状态转换图、DD数据字典、CSPEC控制规格说明

数据流图（DFD）

数据流图（DFD）是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换，描述对数据流进行变换的功能和子功能

组成符号

圆框代表加工

箭头代表数据的流向，数据名称总是标在箭头的边上

方框表示数据的源点和终点

双杠（或单杠）表示数据文件或数据库

文件与加工之间用带箭头的直线连接，单向表示只读或只写，双向表示又读又写

数据字典（DD）

数据字典的任务：对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。

对软件中的每个数据规定一个定义条目

数据流：

数据流名：发票
别名：购书发票
组成：学号 +姓名 + {书号 + 单价 + 数量 + 总价} +书费总计
备注：

数据文件
数据项

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

加工说明（PSPEC）

对数据流图中出现的每个加工/处理的功能描述

主要工具：结构化语言，判定树活判定表

SD模型的组成与描述

包含数据设计、接口设计、过程设计、体系结构设计

体系结构设计是用来确定软件结构的，其描述工具是结构图，简称SC图

过程设计主要指模块内部的详细设计

SC图组成符号和模块调用关系的标识：

矩形框表示模块，带箭头的连线表示模块间的调用，并在调用线的两旁标出传入和传出模块的数据流

简单调用、选择调用、循环调用

例：在模块A的箭头尾部标以一个菱形符号，表示模块A有条件地调用另一个模块B，当一个在调用箭头尾部标以一个弧形符号，表示模块A反复调用模块C和模块D

程序的系统结构图

结构化系统分析

结构化分析的基本步骤

• 自顶向下对系统进行功能分解，画出分层DFD图

• 由后向前定义系统的数据和加工，编制DD和PSPEC

最终写出SRS

画分层数据流图：（自顶向下，逐步细化）

好处：便于实现，便于使用

通常把整个系统当作一个大的加工标明系统的输入和输出，以及数据的源点和终点（统称为“外部项”）

• 顶层DFD：
  

• 第二层DFD：
  

• 第三层DFD：
  

• 采购子系统：
  
  确定数据定义与加工策略（从数据的终点开始）

• 数据定义DD

• 加工策略PSPEC

• 需求规格说明书SRS

需求分析的复审

结构化系统设计

SD概述

面向数据流设计和面向数据设计

• 面向数据流：数据流是考虑一切问题的触发点
• 面向数据：以数据结构作为分析与设计的基础

结构化设计的描述工具：SC图

从分析模型导出设计模型

• 分析模型：数据对象描述、数据流图DFD、数据字典DD、实体联系图ER图、加工规格说明书PSPEC、状态转换图STD、控制规格说明CSPEC

• 设计模型：过程设计、接口设计、体系设计、数据设计由分析模型导出设计模型：过程设计可以由PSPEC,CSPEC,STD导出

• 接口设计可以由DFD导出；体系结构设计可以由DFD导出；数据设计可以由E-R、DD导出

数据流图的类型------变换型、事务型

变换（transform）型结构

传入路径 — 变换中心 — 传出路径

事务（transaction）型结构

一条接收路径 — 一个事务中心 — 若干条动作路径

同时存在变换型结构和事务型结构：

SD方法

结构化软件设计方法——变换映射，事务映射

变换映射是软件系统结构设计的主要方法。一般一个大型的软件系统是变换型结构和事务型结构的混合结构。所以，我们通常利用以变换映射为主，事务映射为辅的方式进行软件结构设计。

变换映射
划分DFD图的边界；
建立初始SC图的框架
分解SC图的各个分支





深度：5层；宽度（广度）：7层；

注意：必须对一个模块的全部直接下属模块都设计完成之后，才能转向另一个模块的下层模块的设计；在设计下层模块时，应考虑模块的耦合和内聚问题；使用“黑箱”技术，先把这个模块的所有下层模块定义成“黑箱”，不考虑其内部结构和实现；一个模块的直接下属模块一般在五个左右，如果直接下属模块超过10个，可设立中间层次。

事务映射：

在DFD图上确定事务中心、接受部分（包括接受路径）和发送部分（包括全部动作路径)

画出SC图框架，把DFD图的3个部分分别映射为事务控制模块、接受模块和动作发送模块

分解和细化接受分支和发送分支，完成初始的SC图

扇入扇出

煎饼型不可取，应增加中间层减少扇出，实现塔型结构

设计良好的软件通常具有瓮型结构，两头小，中间打，在低层模块使用了较多高扇入的共享模块

优化结构设计的指导原则

对模块划分的指导原则

提高内聚，降低耦合

简化模块接口

少用全局性数据和控制型信息

保持高扇入/低扇出的原则

扇入高则上级模块多，能够增加模块的利用率

扇出低则表示下级模块少，可以减少模块调用和控制的复杂度

模块设计

模块设计是传统软件工程的重要组成部分，其性质属于详细设计

目的

为SC图中的每个模块确定算法和数据结构，用选定的表达工具给出清晰的描述

主要任务

编写软件的“模块设计说明书”

原则与方法

清晰第一的设计风格

结构化的控制结构

仅用这三种控制结构（顺序、选择、循环）来构成程序

每个控制结构只应有一个入口和一个出口

逐步细化的实现方法

详细设计中常用的表达工具

流程图、N-S图、伪代码、PDL语言

四、面向对象与UML

面向对象概述

类和对象的关系

对象：代表客观世界中实际或抽象的事物

客观世界是有各种对象组成的

数据以及在其上的操作的封装体

类：一组相似的对象的共性抽象

类是一组客观对象的抽象

实现抽象数据类型的工具

类与对象的关系

抽象与具体的关系

组成类的每个对象都是该类的实例

实例是类的具体事物

类是各个实例的综合抽象

面向对象的基本特征

抽象、封装、继承、多态

面向对象开发的优点

可复用性、可扩展性、可维护性

UML（统一建模语言）简介

通用的可视化的建模语言

目前在软件工程里主要用于系统分析与系统设计

软件生存周期：RUP（统一过程）

软件建模方式：可视化的语言

软件文档规范：文档由UML建模工具自动产生

软件人员分工：岗位界面逐渐趋向模糊

静态图

• 类图：类以及类之间的相互关系
• 对象图：对象以及对象之间相互关系

实现图

• 构件图：构件及其相互依赖关系
• 部署图：构件在各节点上的部署

交互图

• 时序图：强调时间顺序的交互图
• 协作图：强调对象协作的交互图

行为图

• 状态图：类所经历的各种状态
• 活动图：对工作流建模

用例图

用例图：需求捕获，测试依据

UML的模型元素

表示模型中的某个概念

类、对象、构件、用例、结点、接口、包、注释

表示模型元素之间的关系

关联、泛化、依赖、实现、聚集、组合

UML的元模型结构

元元模型层、元模型层、模型层、用户模型层

UML的组成

①静态图

• 用例图
• 静态图：类图、对象图
• 实现图：构件图、部署图

动态图

• 行为图：状态图、活动图
• 交互图：时序图、协作图

②视图

• 用例视图（用例图【活动图】）
  从用户角度看到的系统应有的外部功能

• 逻辑视图（静态：类图，对象图；动态：状态图，时序图，协作图，活动图）
  描述系统的静态结构和对象间的动态协作关系

• 进程视图（状态图、时序图、协作图、活动图、构件图、部署图）
  展示系统的动态行为及其并发性

• 构件视图（构件图）
  展示系统实现的结构和行为特征

• 部署视图（部署图）
  显示系统的实现环境和构件被部署到物理结构中的映射

③原型元素

④通用机制

UML的特点

• 统一标准
• 面向对象
• 表达功能强大、可视化
• 独立于过程
• 易掌握、易用

UML五类九种图的符号体系

UML的主要内容

静态建模机制、动态建模机制

静态建模

静态建模包括:

用例图、类图、对象图

用例模型

使用用例表示

从最终用户的角度描述系统功能

类和对象模型

类图和对象图表示

用例图与用例模型

用例图的组成符号

用例之间的关系

①扩展关系

根据指定的条件，一个用例中有可能加入另一个用例的动作

如果一个用例明显地混合了两种或者两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样可能会使描述更加清晰。扩展用例为基用例添加新的行为，可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

是扩展关系的构造型，箭头指向基本用例。

②包含关系

一个用例的行为包含另一个用例的行为

当可以从两个或两个以上的用例中提取公共行为时，应该使用包含的关系来表示它们。其中这个提取出来的公共用例成为抽象用例，而把原始用例成为基本用例或基础用例。
是包含关系的构造型，箭头指向抽象用例。



包含关系和扩展关系的联系和区别：

联系：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

区别：扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。
包含关系中基本用例的基本流执行时，包含用例一定会执行。

例

现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警, 并实时打印病人的病情报告，立及更新病历。
要求根据现场情景，对医院病房监护系统进行需求分析， 建立系统的用例模型。

简单的需求分析说明
系统名称：医院病房监护系统
根据分析系统主要实现以下功能：
　　1、病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。
　　2、中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。
　　3、当病症信号异常时，系统自动更新病历并打印病情报告。
　　4、值班护士可以查看病情报告并进行打印。
　　5、医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。
　　6、系统定期自动更新病历。

类图Class Diagram

类图表示类间关系:

关联关系（Association）

• 类之间存在的语义上的关系
• 普通关联、递归关联、多重关联等

二元关联

• 表示为在两个类之间用一条直线连接，直线上可写上关联名
  
• 关联的两端可加上重数，表示该类有多少个对象可与对方的一个对象关联
  
• 允许一个类与自身关联
  
  多元关联
• 三个或三个以上的类之间可以互相关联
  
  
  受限关联
• 用于一对多或多对多的关联，限定符用来区分关联”多”端的对象集合，它指明了在关联“多”端的某个特殊对象

聚集关系（Aggregation）

• 特殊的关联：表示类之间具有整体与部分的关系
• 特征是“部分”对象可以是多个任意“整体”对象的一部分，“部分”可以参与到多个“整体”中，部分可以脱离整体

组合关系（Composition）

• 特殊的聚集：整体强烈拥有部分
• 在组合中，“整体”强烈拥有“部分”，“部分”与“整体”共存。如果“整体”不存在了，“部分”也会随之消失。“整体”的重数必须是0或1，“部分”的重数可以是任意的。
  
  泛化关系（Generalization）
• 又称继承
• 普通泛化，限制泛化

此处的一般元素可视作父类，特殊元素视作子类

• 一般元素所具有的关联、属性和操作，特殊元素也都隐含性地拥有；
• 特殊元素应包含额外信息；
• 允许使用特殊元素实例的地方，也应能使用一般元素。
  
  实现关系

实现关系将一个模型元素（如类）连接到另一个模型元素（如接口），后者是行为的规约，而不是结构，前者必须至少支持（通过集成或直接声明）后者的所有操作，可以认为前者是后者的实现。

依赖关系（Dependency）

对一个类/对象的修改会影响另一个类/对象

例如，某个类中使用另一个类的对象作为操作中的参数，一个类存取作为全局对象的另一个类的对象，或一个类的对象是另一个类的类操作中的局部变量等，都表示这两个类之间有依赖关系。

class Boss{
    
    
	void do(Staff s){
    
    
		s.do();
	}
}

约束与派生

• 约束与派生机制能应用于任何模型元素
• 用花括号括起放在模型元素旁边
• 典型的属性约束是该属性的取值范围
• 派生属性可由其它属性通过某种方式计算得到，通常在派生属性前面加一个“/”表示
• 关联关系可以被约束，也可以被派生

包图

• 描述系统的分层结构

对象图Object Diagram

• 对象图是类图的实例
  

动态建模

• 消息
  
• 状态图
  状态图描述对象的所有可能状态及事件发生时状态的转移条件

• 状态图之间发送消息
  
• 时序图（元素：对象、对象生命线、消息）

时序图用来描述对象之间的动态交互，着重体现对象间消息传递的时间顺序。它以垂直轴表示时间，水平轴表示不同的对象。对象用一个带有垂直虚线的矩形框表示，并标有对象名和类名。垂直虚线是对象的生命线，用于表示在某段时间内对象是存在的。对象间的通信在对象的生命线间通过消息符号来表示，消息的箭头指明消息的类型

• 协作图（元素有对象、链接和消息流）
  协作图描述了对象间的动态协作关系，但它强调消息发生和接收的对象的结构组织（及连接关系）（协作对象之间的交互和链接）
  
  

物理架构建模

• 逻辑架构和物理架构
• 构件图：显示软件构件直接的依赖关系。一般来说，软件构件就是一个实际文件，可以是源代码文件、二进制代码文件和可执行文件。构件图可以用来表现编译、链接或执行时构件之间的依赖关系

• 部署图：描述系统硬件的物理拓扑结构以及在此结构上执行的软件。部署图可以显示计算节点的拓扑结构和通信路径、结点上运行的软件构件、软件构件包含对的逻辑单元（对象、类）等。
  

五、需求工程与需求分析

软件需求工程

---

软件需求的定义

一个软件系统必须遵循的条件或具备的能力

• 系统的外部行为 ----- 解决用户的问题
• 系统的内部特性 ----- 满足了文档的要求

软件需求三个层次

• 业务需求 — 从业务的角度评估
• 用户需求 — 从用户使用的角度描述软件必须完成的任务
• 功能需求 — 开发人员必须实现的功能

软件需求的特性

软件质量准则“FURPS”

• 功能性
• 可用性（易用性）
• 可靠性（平均无故障时间、精确度等）
• 性能（响应时间、吞吐量等）
• 可支持性（与系统相关的特性要求）
• 设计约束

软件需求工程

一门应用有效的技术和方法、合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科。

需求分析与建模

需求分析的步骤（迭代）：

• 需求获取、需求建模、需求描述（编写SRS）、需求验证
• 需求获取的目的是让开发人员通过各种方式充分和用户交流，全面、准确的了解系统需求
• 建立需求模型是需求分析的核心，它通过各种图形及符合，可视化地从各个侧面描述系统需求；（结构化方法（包括数据流、数据字典、加工规格说明）和面向对象方法（面向对象方法包括用例模型、补充规约和术语表））
• 需求描述即编写需求规格说明书，它以各方共同认可的文档形式表述，是软件设计和系统验收的可靠依据；
• 需求验证用来检验以上各步的工作成果。
  需求分析是一个迭代的过程

需求获取的常用方法

常规的需求获取方法：

• 联合分析小组
• 用户代表、领域专家和系统分析员
• 客户访谈
• 充分准备，寻找共同语言
• 循序渐进、逐步逼近
• 问题分析与确定
• 多个来回
  用快速原型法获取需求
• 利用各种分析技术和方法，生成一个简化的需求规格说明；
• 对需求规格说明进行必要的检查和修改后，确定原型的软件结构、用户界面和数据结构等
• 在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试、改进；
• 将原型提交给用户评估并征求用户的修改意见；
• 重复上述过程，直到原型得到用户的认可。

需求模型

需求模型概述

• 结构化需求模型
• 面向对象需求模型

面向对象的需求建模

• 画用例图
• 写用例规约
• 描述补充规约
• 编写术语表

结构化需求模型

• 该模型主要由3部分组成，即：包括数据流图和加工规格说明的功能模型；主要由数据字典和E-R图等组成的数据模型；由状态转换图、控制流图和控制规格说明等组成的行为模型。

面向对象需求模型

• 面向对象需求模型由3个部分组成：用例模型、补充规约和术语表，其中用例模型又包括用例图和用例规约

用例建模

确认参与者

• 存在与系统外部、与系统交互的人、硬件、其他系统

确认用例

• 考察每个参与者与系统的交互和需要系统提供的服务

绘制和检查用例图

• 按UML标准画用例图
• 检查用例图

细化每个用例的用例规约

内容包括：

• 简要说明：简要介绍该用例的作用和目的

• 事件流:包括基本流和备选流,表示出所有可能的活动及流程

• 基本流:指该用例最正常的一种场景

• 备选流:用于描述用例执行过程中的异常或偶尔发生的情况。
  它和基本流合起来，能够覆盖该用例所有可能发生的场景。
  包含元素：

  • 起点：该备选流从事件流的那一步开始
  • 条件：在什么条件下会触发该备选流
  • 动作：系统在该备选流下会采取哪些动作
  • 恢复：该备选流结束之后，该用例应如何继续执行

• 特殊需求： 描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统和开发工具等）

• 前置条件和后置条件
  前置条件是执行用例之前必须存在的系统状态，后置条件是用例执行完毕后系统可能处于的一组状态。

用例模型的检查

• 功能需求的完备性
• 模型是否易于理解
• 是否存在不一致性
• 避免二义性语义

软件需求描述

软件需求规格说明书

• 引言
• 信息描述
• 功能描述
• 行为描述
• 质量保证
• 接口描述
• 其他

需求管理

---

需求管理的流程

需求确认

• 需求评审
• 需求承诺

需求跟踪

需求变更控制

• 需求变更利弊
• 需求变更流程

面向对象分析

---

软件分析概述

软件需求和软件分析

• 软件需求：用户角度，注重软件外在表现
• 软件分析：开发者角度，注意软件内部逻辑结构

面向对象软件分析

OOA的主要任务

• 理解用户需求
• 进行分析，提取类和对象，并结合分析进行建模。其基本步骤是：标识类，定义属性和方法；刻画类的层次；表示对象以及对象与对象之间的关系；为对象的行为建模。这些步骤反复进行，直至完成建模。

OOA的模型

• 处于OOA模型核心的是以用例模型为主体的需求模型，抽取和定义OOA模型的3种子模型：
• 类/对象模型，描述系统所涉及的全部类和对象，每一类/对象都可通过属性、操作和协作者来进一步描述；
• 对象-关系模型，描述对象之间的静态关系，同时定义了系统中对象间所有重要的信息路径，也可以具体到对象的属性、操作和协作者；
• 对象-行为模型，描述了系统的动态行为，即在特定的状态下对象间如何协作来响应外界的事件。
  

OOA的优点

• 同时加强了对问题域和软件系统的理解
• 改进包括用户在内的与软件分析有关的各类人员之间的交流
• 对需求的变化具有较强的适应性
• 很好地支持软件复用
• 确保从需求模型到设计模型的一致性

分析模型的特点

• 全面覆盖软件的功能需求
• 分析模型与软件的实现无关
• 分析模型的表述方法与所采用的分析技术有关

OOA的共同特征

共同特征

• 类和类层次的表示
• 建立对象 – 关系模型
• 建立对象 – 行为模型

OOA的建模步骤

• 需求理解
• 定义类和对象
• 标识对象的属性和操作
• 标识类的结构和层次
• 建立对象 – 关系模型
• 建立对象 – 行为模型
• 评审OOA模型

面向对象开发的全过程是OOA,OOD,OOP和OOT的迭代过程。

• 面向对象分析（OOA）是一种从问题空间中提取类和对象来进行分析的方法，用于建立一个与具体实现无关的面向对象分析模型；
• 面向对象设计（OOD）则从问题空间转移到解空间，在分析模型的基础上考虑实现细节，形成面向对象的设计模型；
• 面向对象编程（OOP）则用于将设计模型转换成实现模型，可获得源代码和相应的可执行代码；
• 面向对象测试（OOT）则通过运行可执行代码来检测程序存在的问题。

面向对象分析建模

---

识别与确定分析类

边界类 < < boundary> >

• 用户界面
• 系统接口
• 硬件接口
• 负责和用户进行交互的界面即用户界面

控制类 < < control > >

• 封装用例所特有的控制行为
• 负责实体类和边界类之间的交互

实体类 << entity >>>

• 系统存储的信息及其相关行为
• 主要复制数据和业务逻辑
  
  为每对参与者/用例确定一个边界类
  

为每个用例设置一个控制类

确定相关的各个实体（包括属性与方法）

建立对象-行为模型

时序图（以选课用例中创建课表事件流的时序图）

协作图（以选课用例为例创建课表事件流的协作图）

建立对象-关系模型

分析类的属性：

• 分析类本身具有的信息
  分析类的关联
• 通过关联可以找到其他分析类，链与关联的对应关系

分析类图：表现分析类及其关系

• 描述用例的分析类图称为参与类图（VOPC）
• 每个用例可对应一张完整的参与类图，参与类图可以显示类的实例之间的数量关系。
  
• 100个用例->100个VOPC类图（每个类图有3个类）->全类图（<=300）个类

分析类的合并：

• 每个分析类都代表一个明确定义的概念，具有不相重叠的职责。一个类可以参与不同数量的用例，因此就整个系统而言，需要合并分析类，把具有相似行为的类合并为一个。每当更新了一个类，就要更新或补充用例规约，必要时还有更新原始的需求。

控制类（很少合并）
实体类（基本都合并）
边界类（部分合并）

• 软件分析将软件需求阶段产生的需求模型转变为软件分析模型。分析模型其实就是从软件开发者的角度，在静态组成结构和动态行为两个方面来描述的待开发的软件系统。
• 面向对象分析利用面向对象的技术来分析问题、建立问题域的静态模型和动态模型，并用UML等工具来表示这一需求对应的类对象模型、对象–关系模型和对象–行为模型等，从而完成对问题域建模，形成面向对象的分析模型。
• 软件分析通常从用例分析开始，建立系统需求的静态结构模型和动态行为模型。

五、需求工程与需求分析

软件设计的目标

设计的目标，是细化解决方案的可视化设计模型，确保设计模型最终能平滑地过渡到程序代码。关键是构造解决问题的方案，并在决定实施细节的基础上获得该方案的设计模型。

设计模型和分析模型

分析模型强调的是软件“应该做什么”，并不给出解决问题的方案，也不涉及具体的技术和平台。

设计模式要回答“该怎么做”的问题，而且要提供解决问题的全部方案，包括软件如何实现、如何适应特定的实施环境等。

分析=内容；设计=方式

分析vs设计
分析

• 关注问题的理解
• 理想化设计
• 行为
• 系统结构
• 功能需求
• 一个小的模型

设计

• 关注解决方案的理解
• 操作和属性
• 性能
• 接近实际的代码
• 对象的生命周期
• 非功能需求
• 一个大的模型

软件设计的概念及基本原则

模块与构件、抽象与细化、信息隐藏、软件复用

软件设计的任务

把分析阶段产生的分析模型转换为用适当手段表示的软件设计模型

软件设计一般包括数据设计、体系结构设计、过程设计、结构设计

• 数据设计将分析阶段创建的信息模型转变成实现软件所需的数据结构；
• 体系结构设计定义软件主要组成部件之间的关系；
• 接口设计描述软件内部、软件和接口系统直接以及软件与人直接是如何通信的（包括数据流和控制流）；
• 过程设计将软件体系结构的组成部件转变为对软件组件的过程性描述

数据和过程被封装为类/对象的属性和操作；接口被封装成对象间的消息；体系结构的设计则表现为系统的技术基础设计和具有控制流程的对象间的协作

模块化设计

• 分解
• 模块独立性
• 自顶向下
• 自底向上
• 模块是一个拥有明确定义的输入、输出和特性的程序实体。模块的所有输入都是事先功能必不可少的，所有输出都有动作产生。
• 在软件的体系结构中，模块是可组合、分解和更换的单元。

模块的基本属性：

• 接口：指模块的输入与输出
• 功能：值模块实现什么功能
• 逻辑：描述内部如何实现要求的功能即所需的数据

模块化设计

• 目的是按照规定的原则把大型软件划分为一个较小的、相对独立但相互关联的模块。
• 依据：开发一个大而复杂的软件系统，将它进行适当的分解，不但可降低其复杂性，还可减少开发工作量，从而降低开发成本，提高软件生产率，这就是模块化的依据。

模块的独立性

• 模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他模块的接口是简单的。

模块独立的含义

• 模块完成独立的功能
• 符合信息隐蔽和信息局部化的原则
• 模块间关联和依赖程度尽量小

模块独立程度可由两个定性标准度量：内聚、耦合

• 内聚：指模块内部各个成分之间的联系，也称为块内联系活模块强度
• 耦合：指一个模块与其他模块间的联系，也称为块间联系。
• 模块的独立性愈高，则块内联系越强，块间联系越弱。

内聚

内聚是从功能的角度对模块内部聚合能力的量度，按照由弱到强的顺序，内聚可分为7类，从小到大内聚强度逐步增强

低内聚

①偶然性内聚 ②逻辑性内聚 ③时间性内聚

中内聚

①过程性内聚 ②通信性内聚

高内聚

①顺序性内聚 ②功能性内聚

• 偶然性内聚：当模块内各部分之间没有联系，或者即使有联系，这种联系也很松散，则称这种模块为偶然性内聚或巧合内聚模块，是内聚程度最低的模块
• 逻辑内聚：把几种相关功能（逻辑上相似的功能）组合在一模块内，每次调用由传给模块的参数确定执行哪种功能
  例：由参数决定执行读操作还是写操作：
  
• 时间内聚：又称经典内聚。这种模块大多为功能模块，但模块的各个功能的执行与时间有关，统称要求所有功能必须在同一时间段内执行。

例如初始化模块和终止模块，系统结束模块、紧急故障处理模块等均是实践性内聚模块

• 过程内聚：一个模块中包含的一组任务必须按照某一特定的次序执行时，就称为过程性模块。
• 通信内聚：模块内部的各个成分都使用同一种输入数据，或者产生同一个输出数据
• 顺序性内聚：模块中的各组成成分是顺序执行的。通常情况下，上一个处理框的输出就是下一个处理框的输入
• 功能性内聚：一个模块中各个部分都是完成某一具体功能必不可少的组成部分，或者说该模块中所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的。是内聚性最强的模块

耦合

耦合性是程序结构中各个模块之间相互关联的度量，它取决于各个模块之间接口的复杂程度、调用模块的方式以及哪些信息通过接口

• 非直接耦合：两个模块之间没有直接关系，模块独立性最强
• 数据耦合：一模块调用另一模块时，被调用模块的输入、输出都是简单的数据（若干参数），属松散耦合。
  
  
• 特征耦合（标记耦合）

两个模块通过传递数据结构，（不是简单数据，而是记录、数组等）加以联系，或都与一个数据结构有关系，则称这俩个模块间存在特征耦合

• 控制耦合 ：如果一个模块通过传送开关、标志、名字等控制信息，明显的控制选择另一模块的功能，就是控制耦合
  
  去除模块间控制耦合的方法：
  将被调用模块内的判定上移到调用模块中进行
  被调用模块分解成若干单一功能模块
  
• 外部耦合：一组模块均与同一外部环境关联（例如，I/O模块与特定的设备、格式和通信协议相关联），它们之间便存在外部耦合

外部耦合必不可少，但这种模块数目应尽量少

• 公共环境耦合
  
• 内容耦合：耦合最强。如果一个模块可以直接调用另一个模块中的数据，或者允许一个模块直接转移到另一个模块中去，就称内容耦合

耦合是影响软件复杂程度的一个重要因素，应该采取下述设计原则：

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

内聚和耦合关系密切，与其他模块直接强耦合的模块意味着弱内聚，强内聚模块意味着与其它模块间松散耦合。

设计目标：高内聚、低耦合

• 耦合、内聚与模块独立性关系
• 耦合与内聚都是模块独立性的定性标准，都反应模块独立性的良好程度，但耦合是直接的住到因素，内聚则辅助耦合共同对模块独立性进行衡量

面向对象设计建模

面向对象设计模型

• 系统架构层（系统架构层描述了整个系统的总体结构）
• 类和对象层（包含类层次信息，同时包含了每个对象的设计表示）
• 消息层（对象间的消息模型，建立了系统的内部和外部接口）
• 责任层（每个对象的所有属性和操作的数据结构和算法）

面向对象设计的任务

• 系统架构设计
• 系统元素设计

模式的应用

• 模块是解决某一类问题的方法论，也是对通用问题的通用解决方案
• 软件模块可以分为架构模式、设计模式和习惯用法三种

七、子系统VS包

子系统 ：

• 提供行为
• 完全封装实现细节
• 容易替换

包：

• 不提供行为
• 不完全封装实现细节
• 难以替换

子系统的主要用途：子系统可以将系统划分成独立的部分，将被实现为独立的构件，这些构件在保存结构不变的情况下，可以

• 独立地开发和部署
• 适应变更，而不影响其他系统

子系统也可用于

• 将系统划分成若干单元
• 表示设计中的既存产品和外部系统

八、编码与测试

软件测试

• 动态查找程序代码中的各类错误和问题的过程
• 软件测试是一个与项目开发并行的过程，按照新的观点，测试活动应分布于需求、分析、设计、编码、测试和验收等各个阶段。它是软件开发时期最繁重的任务，也是保证软件可靠性的最主要手段。

测试与纠错

测试：

• 目的：发现程序的错误
• 任务：通过在计算机上执行程序，暴露程序中潜在的错误

纠错

• 目的：定位和纠正错误
• 任务：消除软件故障，保证程序的可靠运行

测试用例：一次执行需要的测试数据
测试用例 = { 测试数据 + 预期结果 } （{}表示重复）
测试结果 = { 测试数据 + 预期结果 + 实际结果 }

每一个测试用例产生一个相应的测试结果，如果它与期望结果不相符合，便说明程序中存在错误，需要通过纠错来改正

选择测试用例的目标：是用可能少的测试数据，达到尽可能大的程序覆盖面，发现尽可能多的软件错误和问题

测试与纠错

• 挑剔性、复杂性、不测底性、经济性
• 穷举测试：让被测程序在一切可能的输入情况下全部执行一遍
• 选择测试：选择一些典型的、有代表性的测试用例进行有限的测试

测试的种类

• 静态分析（程序不执行）
  静态分析器分析（自动方式） 代码评审（人工方式）：代码会审、走查、办公室检查
• 动态测试（程序执行）
  黑盒测试（测试程序功能）、白盒测试（测试程序结构）

黑盒测试（功能测试）

等价分析法

• 所谓等价分类，就是把输入数据的可能值划分为若干等价类，使每类中的任何一个测试用例，都能代表同一等价类中的其他测试用例。

注意：

一是划分等价类不仅要考虑代表有效输入值的有效等价类，还需考虑代表无效输入值的无效等价类；

二是每一无效等价类至少要用一个测试用例，不然就可能漏掉某一类错误，但允许若干有效等价类合用同一个测试用例，以便进一步减少测试的次数。

例：某公司公开招工，规定报名者年龄应在16周岁至35周岁之间（到2008年3月止）。若出生年月不在上述范围内，将拒绝接受，并显示“年龄不合格”等出错信息。试用等价分类法设计对这一程序功能的测试用例。

测试等价类表：

测试用例：

边界值分析法

在数组容量、循环次数以及输入数据域输出数据的边界值附近程序出错的概率往往较大。采用边界值分析法，就是要这样来选择测试用例，使得被测程序能在边界值及其附近运行，从而更有效地暴露程序中隐藏的错误。

所谓边界值分析，就是要把测试的重点放在各个等价类的边界上，选取刚好等于，刚好小于，刚好大于边界值的数据为测试数据，并据此设计出相应的测试用例。

比较

• ①等价分类法的测试数据是在各个等价类允许的值域内任意选取的，而边界类分析的测试数据必须在边界值附近选取
• ②一般的说，用边界值分析法设计的测试用例比等价分类法的代表性更广，发现错误的能力也更强

错误猜测法

所谓猜错，就是猜测被测程序在哪些地方容易出错，然后针对可能的薄弱环节来设计测试用例。

因果图法

是一种简化了的逻辑图，当被测程序具有多种输入条件，程序的输出又依赖于输入条件的各种组合时，用因果图直观地表明输入条件和输出动作之间的因果关系，能帮助测试人员把注意力集中到与程序功能有关的那些输入组合上，比采用等价分类法有更高明的测试效率。

白盒测试

• 白盒测试以程序的结构为依据，所以又称为结构测试早期的白盒测试把注意咯放在流程图的各个判定框，使用不同的逻辑覆盖标准来表达对程序进行测试的详尽程度，称为逻辑覆盖测试；
• 用程序图代替流程图来设计测试用例，称为路径测试。

逻辑覆盖测试的5种标准

发现错误的能力由弱到强

• 语句覆盖：每条语句至少执行一次 A与B为true
• 判定覆盖：每一判定的每个分支至少执行一次 A与B为true，A与B为false
• 条件覆盖：每一判定中的每个条件，分别按“真”“假”至少各执行一次
  A=true，B=true，A=fasle，B=false
• 判定/条件覆盖：同时满足判定覆盖和条件覆盖的要求 A与B=true，A与B=false，A=true，B=true，A=false，B=false
• 条件组合覆盖：求出判定中所有条件的各种可能组合值，每一可能的条件组合至少执行一次 A=true与B=true，A=true与B=false，A=false与B=true，A=false与B=false

语句覆盖发现错误的能力最弱，一般不单独采用

判定覆盖与条件覆盖的差别在于：前者把判定看成一个整体，后者则着眼于其中的一个条件。当一个判定只含一个条件时，判定覆盖也就是条件覆盖。但如果一个判定含有一个以上的条件（称其为复合条件）

采用判定覆盖有可能出现漏洞：盘定制有些条件得到测试，另一些条件却被忽略。判定/条件覆盖解决了条件覆盖的不足之处。条件组合覆盖在5种覆盖中发现错误的能力最强。

路径测试法
着眼于程序的执行路径，程序图是考察测试路径的有用工具。

• 顺序执行的多个结点，在程序图中可以合并画成一个结点。
• 含有复合条件的判定框，应先将其分解成几个简单条件判定框，然后再画程序图

程序图关心的是程序中的判定框，而不是顺序执行部分的细节。

路径测试的特征

对程序图中每一条可能的程序执行路径至少测试一次，如果程序中含有循环（在程序图中表现为环），则每个循环至少执行一次。

①满足结构测试的最低要求。语句覆盖（点覆盖）加判定覆盖（边覆盖）是对白盒测试的最低要求，同时满足这两种标准的覆盖称为完全覆盖。

②有利于安排循环测试。对单循环结构的路径测试包括：

• 零次循环，即不执行循环体，直接从循环入口跳到出口；
• 一次循环，循环体仅执行一次，主要检查在循环初始化中可能存在的错误；
• 典型次数的循环
• 最大值次循环，如果循环次数存在最大值，应按此最大值进行循环，需要时还可增加比最大值次数少一次或多一次的循环测试

选择测试路径的原则

• ①选择具有功能含义的路径
• ②尽量用短路径代替长路径
• ③从上一条测试路径到下一条测试路径，应尽量减少变动的部分（包括变动的边和结点）
• ④由简入繁，如果可能，应先考虑不含循环的测试路径，然后补充对循环的测试；
• ⑤除非不得已（如为了要覆盖某条边），不要选取没有明显功能含义的复杂路径。

多模块程序的测试策略

测试的层次

单元测试、集成测试、高级测试（确定测试、系统测试）

单元测试（编码阶段，以白盒（结构）测试为主）

• 单元测试是层次测试的第一步，也是整个测试的基础。在编码阶段完成。单元一般以模块或子程序为单位，故又称模块测试。
• 目的：通过对象模块的静态分析与动态测试，使其代码达到模块说明书的需求。
• 静态分析与动态测试的重点，均应放在模块内部的重要执行路径、出错处理路径和局部数据结构，也要重视模块的对外接口。

集成测试（测试阶段，以黑盒（功能）测试为主）

• 集成测试是一个逐步组装的过程，它从一个单元开始，逐一地添加新的单元，边添加边测试边纠错，直至最终将所有单元集成为一个系统。
• 除进行新的测试项目外，还需重复先前已经进行过的测试，也称为回归测试。回归测试可用于防止因软件组装改变而导致新的不协调，出现不可预料的错误。
• 目的：将经过单元测试的模块逐步组装成具有良好一致性的完整的程序 集成测试的策略：可以分为自顶向下、由底向上以及两头逼近的混合方式。

确认测试（测试阶段，以黑盒（功能）测试为主）
确认测试是对整个程序的测试，用于确认组装完毕的程序确能满足需求规格说明书（SRS）的要求。

• ①有效性测试（黑盒测试）和配置复审
• ②验收测试（由用户进行）
• ③a与β测试
  -a测试是在一个受控的环境下，由用户在开发者的指导下进行的测试，由开发者负责记录错误和使用中出现的问题。
  β测试是由最终用户在自己的场所进行的，开发者通常不会在场，也不能控制应用的环境。所有在β测试中遇到的问题均由用户记录，并定期把报告给开发者。

系统测试（安装与验收阶段，以黑盒（功能）测试为主）

• 系统测试是在验收阶段进行。
• 目的是检查把确认测试合格的软件安装到系统以后，能否与系统的其余部分协调进行，并且实现SRS的要求。

九、软件维护

软件维护的种类：

• 完善性维护、适应性维护、纠错性维护、预防性维护
  软件的可维护性：
• 是衡量维护容易程度的一种软件属性。定性的说，可维护性取决于软件的可理解性、可修改性与可测试性，三者一起构成软件的质量属性。
  软件维护的副作用：因修改而引起副作用
• 修改编码的副作用；
• 修改数据的副作用；
• 修改文档的副作用