PPT3 软件过程

一、软件过程模型

1．  瀑布模型：每个过程阶段独立，直到上一个过程完成，下一个过程才启动

其间伴随着过程反复

瀑布模型的缺点是过程进行中对应变更比较困难。

问题：将项目生硬地划分成几个明显不同的阶段，这使得响应客户的需求比较困难，所以这个模型适用于需求能够较好地理解的情况

2．  进化式开发：描述与开发交替进行

探索式：其目标是与客户一起工作，从最初的需求草案进化到最后的系统。应该从理解最清楚的需求开始。

抛弃式：目的是理解系统需求。从理解较差的需求开始

问题：缺乏过程可见性；系统结构通常较差；需要特殊的工具和技术 (例如采用快速建立原型的语言)

适用性：中小型交互式系统；大型系统的一部分 (如用户界面)；生命周期短的系统

3．  形式化的系统开发

基于用形式化数学转换将系统描述转换成一个可执行程序

转换是保证正确性的，所以程序是符合描述的。

具体实现如IBM的净室(Cleanroom)过程软件开发

问题：应用这项技术需要专门的技能和训练；系统的某些方面难以形式化描述，例如用户界面

适应性：适合于严格的系统，特别是安全性和保密性要求极高的系统

4．  面向复用的开发

基于已有的组件或者COTS系统的系统重用

5．  过程反复：系统需求在项目进行期间总是进化的，所以对大型系统来说经常是早期阶段反复的过程；反复可以应用于任何通用过程模型

两个混合模型

a.       增量式开发：系统不是一次交付，而是将要求的功能分成多次增量进行开发和交付

用户需求是有优先顺序的。优先级最高的需求包含在最初的增量中。

一旦一个增量的开发开始时，需求就要冻结。虽然后面的增量可以继续进化

优势：客户要求的功能随着每次增量被交付，所以系统功能可以较早看到

较早的增量可以作为原型帮助引出后面增量的需求

项目总体失败的风险降低

最高优先级的系统服务由于是最早增量，得到最多的测试

  极限编程：基于非常小的功能增量的开发和交付的一种新的方法；依靠连续的代码改进，用户参与到开发团队一起开发，是敏捷开发的一种

b.       螺旋式开发

将过程表示为螺旋线，而不是用一系列活动和活动间的回溯来表示

螺旋线中的每个回路表示过程中的一个阶段

没有固定的阶段。螺旋线中的回路根据需要选取

风险需要明确评估、然后在过程中解决

二、 软件设计方法

1．  数据流模型：包括数据元素，数据操作，数据流向

2．  实体-关系模型

3．  结构模型

4．  对象模型：将数据与操作封装视为对象，具有一定的属性，各个对象之间连线构成模型

PPT4

一、项目管理

1．  软件项目管理涉及的行为，是为了确保软件及时并按照进度的要求交付，同时满足开发或者采购该软件的机构的需求 项目管理是需要的，因为软件开发总是受到预算和进度的约束，这些约束是由开发该软件的机构所设置的。

2．  软件管理的特别之处：

产品是无形的

产品是灵活可变的，其它产品中这是比较少见的。

软件工程学科被认为还是不完整的，跟机械、电子工程等学科不同

软件开发过程是非标准化的

许多软件项目是一次性的项目

3．  项目计划的类型：

质量计划，有效性验证计划，配置管理计划（支持系统的集成计划，使每个开发人员可以在管理中访问工程代码和文档，超找变更，编译连接组件并生成系统），维护计划，人员发展计划

4．  活动组织

里程碑：是一个过程活动的终点，瀑布过程可以定义明显的进度里程碑

可交付物：是交付给客户的项目结果

5．  项目调度

将项目分解成多个任务，估算完成每个任务需要的时间和资源

并发地组织任务以形成劳动力的优化利用

使得任务间的依赖性最小化以避免一个任务等待另一个任务带来的延迟

依赖于项目管理者的直觉和经验

甘特图：活动的时间条形图

6．  风险管理

风险包括项目风险、产品风险和业务风险

过程：

风险识别：识别项目、产品和业务风险

风险分析：评估这些风险出现的可能性及其后果

风险规划：制订计划说明如何规避风险或降低风险对项目的影响

风险监控：监控整个项目过程中的风险

管理者要扮演多种角色，其中最主要的活动是规划、估算和进度

PPT5

1．  需求工程：

建立用户需求以及使用和开发的约束的过程

需求工程过程中生成的需求本身是系统服务和约束的描述

2．  需求的双重功能：

可能是一个合同标书的基础 – 所以必须公开解释

可能是合同本身的基础 – 所以必须详细定义

这两种情形都可能称为需求

3．  需求的类型：

用户需求：关于系统服务和约束的自然语言加上方块图表述。为客户撰写。较为粗略。

系统需求：一个结构化的文档写出系统的服务。作为客户和承包商之间的合同内容。较为细致。

软件描述：一个详细的软件描述可以作为设计或实现的基础。为开发人员撰写。

4．  功能与非功能需求

功能需求：系统需要提供的服务的表述，系统应该如何响应特定输入，系统在特定的情形下应该如何动作。

非功能需求：系统提供的服务或功能上的约束，例如时间约束、开发过程约束、标准等。

领域需求：需求从系统应用领域中得出，反映了领域的特征。

5．  需求应该具有完整性和一致性

完整性：需要的所有服务都应该给出描述

一致性：在系统服务的描述上应该没有冲突和矛盾

6．  非功能需求分类

产品需求：描述交付产品的行为，如执行速度、可靠性等

机构需求：机构政策和程序的结果，如过程标准、实现要求

外部需求：系统外部因素和开发过程，如互操作性要求、法律要求等

7．  需求的度量：

8．  领域需求

从使用领域中得到，描述反映领域的特征和性质

可能是新的功能需求、已有需求的约束或者定义一个特定的计算

如果领域需求不被满足，系统可能无法工作

如：

问题：

易懂性不够：需求使用应用领域中的语言表达；开发系统的软件工程师往往无法理解

不够清晰明了：领域专家能够很好的理解领域知识所以他们不愿把领域需求表达得更加清晰明了

9．  用户需求：

应该描述功能性和非功能性需求，使得没有具体的技术知识的系统用户也能理解

用户需求用自然语言、表和方块图定义

自然语言的问题：

不够清楚：为了使得文档易读，保证精确性是困难的

需求混乱： 功能性和非功能性需求会混在一起

需求合并：几个不同的需求可能放在一起表达

10． 系统需求

比用户需求更详细的描述

作为系统设计的基础

可以作为系统合同的一部分

系统需求可用结构化的自然语言、PDL或者格式化的语言来撰写

11． 需求和设计：

自然语言的问题：

二义性：需求的读者和作者必需对同一词语有同样的解释。自然语言是做到这点比较困难，因为自然语言存在二义性。

随意性太大：同一件事情可能在描述中用好几种不同的方式讲述.

模块化不够：自然语言的结构不足以构建系统需求

改用结构化的语言描述

12． 需求文档

需求文档是对系统开发者要求的正式表述

应该包括系统定义和需求描述

不是设计文档，陈述的是系统应该做什么而不是怎么做。

13． IEEE 需求标准

PPT6 需求工程过程

1．  共通的过程：需求导出，需求分析，需求验证，需求管理

2．  可行性研究

决定一个建议的系统是否值得做

3．  导出和分析

也叫需求导出或者需求发现

相关的技术人员和客户一起工作以发现应用领域、系统提供的服务、系统的运行限制

可能涉及终端用户、管理者、维护工程师、领域专家等项目相关人员。

需求分析有三种活动

区分. 识别实体之间的结构关系

提取. 识别实体中的一般特性

发散. 识别看一个问题的不同方式

4．  面向视点的需求导出

项目相关人员不同的问题视点，这种多视点的分析是重要的，因为分析系统需求没有单个正确的方式

过程模型：

视点识别：发现接收系统服务的视点，以及识别每个视点提供的服务

视点组织：组织相关的视点形成层次结构。通用的放在较高的层次。

视点文档：对被识别的视点和服务描述的精炼。

视点系统映射：将分析转化为面向对象的设计

椭圆. 来自视点和交付给视点的数据

控制信息从每个方框的顶部出入

数据从每个方框的右侧出来

异常显示在方框的底部

场景完成后预期的下一个事件的名称表示在一个粗线框中

5．  用例

6．  序列图：目录管理的序列图

序列图中：方块表示活动，横向箭头表示转移，纵向直线表示时间

7．  需求的有效性验证

证明系统中定义的需求是客户真正想要的

需求错误的代价是很高的，所以有效性验证非常重要

需求有效性验证技术：

需求评审：对需求做系统性的手工分析

原型开发：用一个可执行的系统模型来检查需求。在第8章详述

测试案例生成：检查需求的易测性

自动一致性分析：检查结构化需求描述的一致性

8．  需求管理过程包括规划和变更管理

PPT7 系统模型

一 系统建模

系统建模有助于分析者理解系统功能，模型可用来和客户沟通

不同的模型从不同的角度来描述系统

从外部来看，是对系统上下文或系统环境建模

从行为来看，是对系统行为建模

从结构上看，是对系统的体系结构和系统处理的数据的结构建模

二 系统模型类型

数据处理模型，说明数据在不同的阶段如何被处理的。（数据流图）

组成模型，说明系统中的实体是如何由其它实体组成的。（实体-关系图）

体系结构模型，说明构成整个系统的主要子系统。（体系结构图）

分类模型，说明实体间怎样具有共同特性。（对象类/继承关系图）

激励/响应模型，说明系统对事件的响应。（状态转换图）

1．  上下文建模

上下文模型用来说明系统的边界

更多课程资料请到大学课程网www.0206.cc学习

第二篇：软件工程复习笔记总结

? Unit1

? 软件危机包含两方面的问题：一是如何开发软件，怎样满足人们对软件日益增长的需求？二是如何维护软件，使它们持久地满足人们的要求。

? 软件工程学定义：把软件当作一种工业产品，采用工程学的原理来管理和组织软件的开发和维护，称为软件工程。

? 软件是指程序、数据和文档三者共同构成的配臵。

? 包含与数据处理系统操作有关的程序、规程、规则以及相关文档的智力创作称为软件。文档是描述程序开发过程的，是智力创作的真实记录，是创作活动的历史档案和结晶。 ? 软件的描述性定义：软件由计算机程序，数据结构和文档组成。

? 软件质量定义为“与软件产品满足规定的和隐含的需求能力有关的特征和特性的全体” 具体来说： 1）软件产品中能满足给定需求的性质和特性的总体；

2）软件具有所期望的各种属性的组合程度。

? 将软件质量属性划分为六个特性(功能性、可靠性、易用性、效率、维护性和可移植性)，这六个属性是面向用户的观点——面向管理的观点，且是定性描述的。

? 软件质量度量体系：内部度量可用于开发阶段的非执行软件产品，外部度量只能在生存周期过程中的测试阶段和任何运行阶段使用。

? 软件工程项目的基本目标：（1）低成本；（2）满足功能要求；（3）高性能；（4）易移植；

（5）易维护。

? 软件工程方法学就是要从技术和管理上提供如何去设计和维护软件。

? 软件开发方法：面向数据流（约旦）方法、面向数据结构方法、面向对象方法。

? 结构程序设计是进行以模块功能和处理过程设计为主的详细设计的基本原则。它的主要观点是采用自顶向下、逐步求精的程序设计方法；使用三种基本控制结构构造程序，任何程序都可由顺序、选择、循环三种基本控制结构构造。

? 用来辅助软件开发、运行、维护、管理、支持等过程中活动的软件称为软件工具（CASE）。 ? 软件生存周期定义：软件产品从形成概念开始，经过开发、使用和维护，直到最后不再使用的整个过程。各阶段的任务彼此间尽可能的相对独立，同一阶段内各项任务的性质尽可能的相同。软件的开发就是“按软件顺时间发展的过程分阶段进行”的。

? 软件生存周期模型：

瀑布模型（阶段间具有顺序型和依赖性，清楚地区分逻辑设计与物理设计、尽可能推迟程序的物理实现，是文档驱动模型，遵循结构化设计）；

原型模型（软件产品的开发是线性顺序进行的，本质是快速，用途是获知用户的真正需求，一旦需求确定，原型将被抛弃）。 其核心都是将软件开发划分为：分析、设计、编码、测试和维护。

? 软件生存周期划分为以下几个阶段：可行性研究与计划、需求分析、总体设计、详细设计、实现、组装测试、确认测试、使用和维护。

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

? 软件工程方法学：通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称范型

? 软件工程过程是软件生存周期中各个可能的过程，这些过程可进一步划分成为了提供或获得软件产品或服务，或是为了完成软件工程项目需要完成的有关软件工程活动，每一项活动又可分解为一些软件工程任务。标准定义了21个过程分属三类：基本过程（include获取、供应、开发、运作、维护过程）、支持过程和组织过程。

? 软件工程三要素：方法、工具和过程。

? 软件工程管理

目的：为了按照进度及预算完成软件计划，实现预期的经济和社会效益。

内容：成本估算、进度安排、人员组织、质量保证、配臵管理等等。

怎么强调软件工程管理的极其重要性都不会过分

? Unit2

? 可行性研究

任务和目的：用最小的代价在尽可能短的时间内确定问题是否能够在一定规模之内解决。（确定这一问题是否存在值得去做的解）

过程和步骤：

实质：进行一次大大压缩简化了的系统分析和设计过程，也就是在较高层次上以抽象方式进行的系统分析和设计过程。

技术和工具：DFD+DD

? 主要内容

（1）澄清问题定义 ——规模、约束和限制

（2）导出新系统的逻辑模型

（3）导出若干个供选择的物理解法（物理模型），并分别研究它们的可能行： ? 数据流图符号

Example：

?

?

?

?

?

? Unit3

? 需求分析：

目的：精确地定义系统必须做什么，也就是对目标系统提出完整、准确、清晰、具体的要求。——为目标系统提出精确的逻辑模型。

任务：确定对系统的综合要求，包括功能需求、性能需求、可靠性和可用性需求、运行要求、将来可能提出的要求。

过程：处理逻辑的分解：自顶向下逐步分解直到每个处理逻辑已是不可再分的“功能单元”为止。

书写文档：软件需求规格说明

工具：状态图、IPO图、层次方框图、Warnier图

? 结构化分析设计技术是70年代中期由E.Yourdon等人提出来的一种面向数据流的方法；要

求系统的开发工作在结构化和模块化的基础上进行，它系统的运用了描述模型的概念，按照软件内部数据传递和变换的关系，自顶向下逐层分解，直到找出满足要求的可实现的软件。

在这个方法里，“抽象”，“分解”，“模块化”，“结构化”是它的主要手段；面向数据

传递、变换所形成的数据流（Dataflow）和数据流程图（DFD）是它的主要依据。

这个方法的关键工作是：画分层的DFD和确定数据定义与加工策略。

? Yourdon方法(对应的瀑布模型)的缺陷: 数据流图的基本目的是 利用它作为交流信息的工具，另一个主要目的是作为分析和设计的工具。 数据字典是关于数据信息的集合，也就是对数据流图中包含的所有元素的定义的集合，它是通过对数据元素和数据结构的定义，来描述数据流和数据存储的逻辑内容的。 数据流和数据字典共同构成系统的逻辑模型。 数据字典的内容： 数据流、数据元素、数据存储、处理 数据字典最重要的用途是作为分析阶段的工具。

其实Yourdon方法是建立在三个假设之上的：

假设1：所有的需求都是可以预先定义的；

假设2：需求在较长一段时间内是不变的（相对稳定的）；

假设3：运用所提供的工具可以做到项目参与者之间清晰、准确、有效的沟通。

这三个假设往往是很难成立的：

“逻辑模型”的精确描述依赖于“自顶向下的求精过程”，而“自顶向下的求精过程”的顺利进行又依赖于精确的“逻辑模型”，这二个问题互相缠绕依赖而构成方法学上的“死锁”。 ? 原型法（原型模型）：

原型就是模型的意思（原型=模型），它指的是模拟某种产品的原始模型。

运用原型的策略：抛弃策略&附加策略

对原型的逐步求精过程是一个迭代过程

相对于Yourdon方法来说原型法是一个非线性的系统开发方法。

不再强调高质量的阶段性文档。

? 螺旋模型：沿螺线自内向外每旋转一圈便开发出一个更为完善的软件版本

? Yourdon方法适合于“预先指定的系统”；

? 原型法适合于“用户驱动的系统”。

? 通常用“范式”定义消除数据冗余程度。第一范式数据冗余程度最大，第五范式数据冗余程

度最小。

? 状态转换图：

状态是可以被观察到的系统行为模式，一个状态代表系统的一种行为模式，它规定了系统对事件的响应方式。一张状态图有一个初态和0至多个终态。

事件：在某个特定时刻引起系统做动作和（或）状态转换的控制信息。

? 验证软件需求的正确性：

一致性、完整性、现实性、有效性

? Unit4

? 总体设计：

目的：确定系统的具体物理实现方案（系统结构设计），确定组成每一个程序的模块，以及模块间的关系（软件结构设计）。

任务：软件结构设计(过程设计是详细设计阶段的任务)

过程：

设想供选择的方案

选取合理方案（每份方案有 系统流程图、组成系统的物理元素清单、成本/效益分

析、实现这个系统的进度计划 4份资料）等9步（P92）

? 在软件开发早期阶段考虑测试问题，能促使软件设计人员在设计时注意提高软件的可测试性。 ? 总体设计阶段书写的文档：系统说明、用户手册、测试计划、详细的实现计划、数据库设计

结果。

? 总体设计过程中，推荐最佳方案后进入“软件结构”设计：设计出组成这个系统的所有程序、

文件和数据库，以及它们之间的联系。软件结构：由模块组成的层次系统。模块：数据说明、可执行语句等程序。

? C/S（Client/Server）结构是软件系统体系结构

? “结构化设计”概括地说就是：用一组标准的工具和准则来确定系统应该由哪些模块、用什

么方式联结在一起，才能构成一个最好的软件结构。

? 模块化就是把程序划分成若干个模块，每个模块完成一个子功能，把这些模块集成起来构成

一个整体，可以完成指定的功能满足用户的需求。

? 模块: 具有四种属性的一组程序语句称为一个模块，这四种属性分别是：输入和输出、逻辑

功能、运行程序、内部数据。(前两个是模块外部属性，后两个是内部属性，总体设计完成外部属性设计、详细设计完成内部属性设计)

? 软件结构图中，模块用一矩形表示。

? 模块间调用：用→连接

? 开发具有独立功能而且和其它模块之间没有过多相互作用的模块，可以做到模块独立。 ? 影响模块独立的因素：

耦合（不同模块间互联程度）

内聚（同一模块内各元素紧密程度）

? 力争高内聚、低耦合。

? 5种耦合形式：

数据耦合、控制耦合、特征耦合、公共耦合、内容耦合（从左到右耦合程度递增）

最弱的耦合是非直接耦合

? 7种内聚形式：

功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚（从左到右程度依次递减）

? 模块的扇出与扇入：

模块的扇出是指一个模块拥有的直接下级模块的个数。

模块的扇入是指一个模块的直接上级模块的个数。

模块的扇出系数应控制在7以内，尽可能的加大模块的扇入系数。

? 作用域应该是控制域的子集；

? 模块的控制域和作用域：

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

模块的作用域（判断作用范围）：是指受该模块内一个判断影响的所有模块的集合。（也就是该模块内存在着判断调用语句，而所有受到该判断逻辑影响的模块，就是该模块的作用域。）

作用域应该是控制域的子集；理想的是作用域都是直接下属模块。

? 数据流类型——数据在DFD中流径特征

变换流：进入系统中的数据所流经的路径几乎是一样的。

事务流：进入系统中的数据所流经的路径不完全是一样的。

?

? 事务中心往往包含多个处理逻辑。

?

? ? “事务”是指一组输入数据。

? Unit5

? 详细设计:

目的:完成模块的过程设计 (为SC中每个模块确定采用的算法和块内数据结构，用某种选定的表达工具给出详细清晰的描述。)

模块的逻辑设计（模块的过程描述）

主要内容：

1）为每个模块确定采用的算法

2）确定每个模块使用的内部数据结构

3）确定模块的接口细节

4）制定模块的测试计划

完成模块的“内部属性”设计，即给出系统中各个模块的“运行程序”和“内部数据”；由此可见详细设计的结果基本上决定了最终软件的质量。

详细设计的目标更重要的是便于维护。

工具：

1.程序流程图(流程图)

2.N-S图（盒图）

3.PAD图（问题分析图）

? 4.伪代码和PDL语言 逻辑设计应遵循的理念：

1.从效率第一到清晰第一

2.结构化的控制结构：结构化程序设计=仅使用单入口单出口的三种基本控制结构

3.逐步细化的实现方法

[例] 在一组数中找出其中的最大数 分别用程序流程图、N-S图和PAD图描述

用“结构化”保证程序的清晰易读，用“逐步细化”实现程序的正确可靠，它们导致了一条自然的结论：模块的逻辑设计必须用结构化程序设计的原理来指导。（结构化设计在详细设计阶段）

Yourdon方法的技术途径：DFD→DFD+DD→SC→PDL

Yourdon方法在分析阶段，我们用DFD来表示软件的逻辑模型；在设计阶段，又按照数据流类型，分别用变换分析或事务分析将它们转换成相应的软件结构。

面向数据结构设计方法的根据和基本思想： ? ? ?

算法和数据结构是程序设计中不可分割的侧面，算法的结构依赖于它要处理的数据结

构。只要事先知道一个问题的数据结构，就可以由此导出它的程序结构。

? 基于数据流还是基于数据结构的出发点不同，最终目标也不同。SADT（结构化分析设计工具）

方法的目标是得出软件的最终SC图，它把注意力集中在模块的合理划分上；面向数据结构的设计则要求得出程序的过程性描述，并不明确也提出软件应该先分成模块等概念。

? SADT方法：DFD ->SC（软件结构图）->模块的过程性描述(PDL等)

|<-------总体设计-------> | |<--------详细设计------->|

Jackson方法(面向数据结构)：数据结构 ->程序结构->程序的过程性描述(伪代码等)

|<-----总体设计-----> | |<----------详细设计--------->| ? 程序复杂程度的定量度量：

1. 程序图（流图）(用任何方法表示的详细设计结果都可以变换成程序图)

流程图中的各种处理框均简化成一个结点

2.环域复杂度

程序的结构复杂度可用强连通的有向图中线性无关环的个数来度量

V（G）= 判定结点数 + 1

? Unit6

? 编码（也称实现）

任务：把模块的过程性描述翻译为用该语言书写的源程序（或源代码）。

? 编码的风格

1.程序要清晰直观，不要过于巧妙

2.用一定的原则指导控制结构的使用（避免使用容易引起混淆的结构和语句）

3.有规律地使用GOTO语句

不得不把效率的考虑放在首位的时候，而结构化程序又不能满足时间要求时，就可用GOTO语句来减少重复的代码段；

4.实现源程序的文档化(软件=程序+文档)<有意义的变量名称、适当注释、标准的书写格式>

? Unit7：

? 软件测试：

定义：程序测试是为了发现错误而执行程序的过程。

纠错（调试）是为了确定错误的性质，并且加以纠正。

? 软件测试包括机器测试(动态测试)（黑盒测试&白盒测试）和人工测试(代码复审)（代码走查

+会审+办公桌检查）

程序编译通过后，应该先人工测试（发现逻辑错误）后机器测试(在设定的测试数据上执行被测程序).

? 动态测试是一个包括：①设计“测试用例”→②执行被测程序→③分析测试结果并发现错误

的过程。(①设计“测试用例”是最关键)

测试用例＝{ 输入数据 + 期望结果 }

按照在设计“测试用例”时，是否涉及程序的内部结构，把动态测试分为：

白盒测试：从程序的内部逻辑入手，按照一定原则设计测试用例。

黑盒测试：仅以程序外部功能为依据来设计测试用例。检查程序是否完成应做的和是否做了不该做的。（按规格说明书的规定）

? 软件测试的的步骤：[见笔记本上图]

单元测试：在编码阶段完成；以模块为单位，（主要白盒）发现的往往是编码和详细设计的错误

综合测试：（模块组装测试、集成测试）以软件的设计信息为依据，主要用黑盒，发现设计错误，也可能发现需求说明错误。

确认测试（验收测试）：以软件的需求信息为依据，用黑盒，发现需求说明书中的错误，验证软件的有效性

系统测试：指整个计算机系统（包括软件与硬件）的测试。

? 代码复审

1.代码会审：开会逐句朗读和讲解程序，精力集中于发现错误，会后改正错误

2.走查：与会者扮演“计算机”的角色

3.办公桌检查：一个人参加的代码会审

? 黑盒测试方法：

? 等价分类法：

按测试结果“等价”把被测程序的输入域划分为若干个等价类，每一个等价类都选择一例“测试用例”，与“应做的事情”相对应的是“有效等价类”，而与“不应该做的事情”相对应的称之为“无效等价类”。

设计等价类的测试用例分为两步：

1.划分等价类并给出定义；

2.选择测试用例的原则：有效等价类的测试用例尽量公用；无效等价类必须每类一例。

[例]某城市的电话号码……[看笔记]

? 边界值分析法（边值法）

? 错误猜测法（猜错法）

? 因果图法

? 白盒测试方法：[见笔记]

合理的白盒测试，就是要选取足够的测试用例，以实现对源程序比较充分的覆盖。

? 逻辑覆盖法：（按照由低到高对程序逻辑覆盖程度的顺序）

语句覆盖：每条语句至少执行一次；

判定覆盖：不仅每条语句至少执行一次，而且每一分支至少执行一次；

条件覆盖：不仅语句覆盖，而且每个条件均按“真”、“假”两种结果至少执行一次； 条件组合覆盖：不仅语句覆盖，而且每个条件的所有可能组合都至少执行一次。

? 路径覆盖法：（按照由低到高对程序逻辑覆盖程度）

结点覆盖：每个结点走一次；相当于语句覆盖

边覆盖：每条边走一次；相当于判定覆盖

路径覆盖：每条路径走一次；（不需要考虑程序的循环）

? Unit8

? 面向对象基本原理：使描述问题的问题空间和在计算机上解决问题的解空间在结构上尽可能

一致。

? 基本概念：

（1）对象：由数据以及可以施加在这些数据上的操作（或服务、方法、处理）所构成的统一体，它是面向对象软件的基本模块。

（2）类：对具有相同数据和相同操作的一组相似对象的定义（抽象）。

（3）不同的对象彼此之间只能通过消息相互作用、相互联系

（4）继承:处于下一层次上的派生类自动继承了位于上一层次基类的属性（数据）和行为（操作）

? 面向对象就是既使用对象又使用类和继承等机制，而对象之间仅能通过传递消息实现彼此间

的通信。

? UML 用视图来表示被建模系统的各个方面，它把软件模型分成5个视图，每一个视图代表完

整系统的一个特定方面。每一个视图又由一种或多种模型图构成。

1． 用例视图：用来支持需求分析，也就是说系统将提供的功能是在用例视图中描述的。

2． 逻辑视图：定义系统的实现逻辑,重点关注的是系统的静态结构（类、对象及它们之间的

关系）,也描述系统内部的动态协作关系。它的模型图包括类图、对象图、状态图、顺序图、协作图及活动图等。

3． 组件视图：描述系统的实现模块及它们之间的依赖关系。组件是不同类型的代码模块，

通过代码模块的结构和依赖关系来表示。

4． 部署视图：描述软件系统在计算机硬件系统和网络上的安装、分发和分布情况。

5． 实现视图：描述组成软件系统的各个物理部件。

? UML由三部分组成：基本构造块、规则和公用机制

? UML 定义了二类模型元素的图形表示：一类模型元素用于表示模型中的某个概念，一类模

型元素用于表示模型元素之间的关系

? 面向对象建模：

对象模型——“谁做？”（类图）

动态模型——“什么时候做？”（状态图）

功能模型——“做什么？”（用例图）

这三种模型都是必不可少的，对象模型是最核心的。

在面向对象分析中，构造出完全独立于实现的应用域模型；在面向对象设计中，把求解域的结构逐渐加入到模型中；在实现阶段，把应用域和求解域的结构进行编码和验证。

? OO方法：OOA→OOD→OOP→OOT 是一个逐渐扩充模型的过程，其间无需转换概念和

表示，开发活动之间基本做到了平滑无缝过渡；

? 对象模型：

类与类之间一般有四种关系：关联、聚集、泛化（继承）、依赖和细化。

1. 关联：表示两个类的“对象”之间存在某种语义上的联系。

2. 聚集：聚集是关联的特例，它表示类与类之间的关系是整体与部分的关系。

3. 泛化（继承）：泛化关系指的是类与类之间是“一般 --- 特殊”的关系。

4. 依赖和细化：依赖关系是指一个模型元素依赖于另一个独立的模型元素，细化关系是指一个

模型元素细化成了另一个模型元素。

? 动态模型：

描述了对象模型中对象的生命周期过程，即对象的状态，我们把一个触发行为称为一个事件。 动态模型就是通过描述对象的状态、触发状态转换的事件、以及对象的行为来描述软件系统的动态行为（行为模型）。

? 功能模型：

UML提供用例图来表示功能模型，并称之为用例模型。

功能模型也可用SADT中的一组DFD来表示。（也是需求分析阶段）

一幅用例图包含的模型元素有：系统、行为者、用例和用例之间的关系。

一个用例是系统的一个完整的功能，通过关联与行为者连接，关联指出一个用例与哪些行为者交互，这种交互是双向的。

用例是一个类，用例的实例是系统的一种实际使用方法，我们称之为脚本。

用例之间的关系主要有二种：扩展关系和使用关系。

创建用例模型的工作包括：定义系统、寻找行为者和用例、描述用例、定义用例之间的关系，并确认用例模型。

? Unit9：

? 面向对象分析（Object-Oriented Analysis,简称OOA）的关键就是识别出对象与类，并分

析它们之间的关系，最终建立对象模型、动态模型和功能模型。

图： 参照当前系统建立目标系统

? 通过划分“主题”把一个复杂系统的对象模型分解成几个不同的概念范畴。

?

? 软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 ? 维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求

之前，与软件维护有关的工作已经开始了。

? 进行维护的原因：改正程序中的错误和缺陷；改进设计以适应新的软、硬件环境;增加新的应

用范围；为了将来的维护工作。

? 维护分为以下几类：改正性维护；适应性维护；完善性维护；预防性维护

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

? 未涵盖进来的内容： 需求分析目的：确定目标系统必须具备哪些功能 总体设计的主要任务：一.制定几种可能的实现方案；二.设计程序的体系结构 详细设计（模块设计）任务：设计出程序的详细规格说明 集成测试和验收测试： 集成测试（组装测试）：根据设计的软件结构 验收测试：按照规格说明书的规定，由用户参与下对目标系统进行验收的测试 通过对软件测试结果的分析可以预测软件的可靠性。 传统软件工程方法学的软件过程，可以用瀑布模型来描述 瀑布模型的特点：阶段间具有顺序性和依赖性、推迟实现的观点 清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现。 瀑布模型带反馈环，发现前面阶段的错误时，沿反馈线回头修改 快速原型模型不带反馈环，软件产品开发是线性顺序进行的，用途是获知用户的需求 增量模型（渐增模型）：把软件产品分解成增量构件。原则：当把新构件集成到原有构件时，所形成的产品必须是可测试的。它能在较短时间内向用户提交可完成部分工作的产品。 要求开始实现各个构件前就全部完成的需求分析、规格说明、总体设计。 螺旋模型的基本思想：使用原形及其他方法来尽量降低风险。可以看作每个阶段前都加了风险分析的快速原型模型。螺旋模型是风险驱动型的。 喷泉模型体现了面向对象开发过程迭代和无缝的特性。 采用先行顺序的开发方法不可能开发出当今客户需要的大型复杂系统。 构件：功能清晰的模块或子系统。 模型：对事物的无歧义的书面描述。 RUP强调采用迭代和渐增的方式来开发软件，重复一系列组成软件生命周期的循环。 面向对象方法=对象+类+继承+用消息通信 可行性分析中导出供选择的解法的最简单途径，是从技术角度出发考虑解决问题的不同方案。 系统流程图是概括地描绘物理系统的工具，表达数据在系统各部件之间的流动情况，而非对数据加工处理。 数据流图（DFD）描绘信息流和数据从输入移动到输出的过程中所经受的变换。（描绘数据在软件中流动和被处理的逻辑过程），设计时只考虑系统必须完成的基本逻辑功能。 画数据流图的基本目的：利用它作为交流信息的工具;作为分析和设计的工具。 符号：数据源点/终点，变换数据的处理，数据存储，数据流 数据存储是处于静止状态的数据流，数据流是处于运动中的数据。 数据字典是关于数据的信息的集合，即对数据流图中包含的所有元素的定义的集合。 数据字典包含内容：数据流，数据流分量，数据存储，处理 数据字典用途：分析阶段的工具。 逆向需求说明软件系统不应该做什么 分析系统常用图形工具：层次方框图、Warnier图 需求分析时要把数据结构规范化。 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

把分析过程中得到的有关数据元素记录在数据字典中，对算法的简明描述记录在IPO图中。 快速建立软件原型是最好的需求分析技术。为快速构建和修改原型，使用三种工具和方法： 第四代技术

可重用的软件构件

形式化规格说明和原型环境

? 概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。 ? 数据对象是软件必须理解的复合信息的抽象。

? 用“范式”定义消除数据冗余的程度，第一范式冗余最大。

? 状态是任何可被观察到的系统行为模式，一个状态代表系统的一种行为模式。

? 状态图的活动表中经常使用entry,exit,do三种标准事件。

? IPO图是输入、处理、输出图，处理框中列出处理的次序暗示了执行的顺序。

? 验证软件需求的正确性：一致性、完整性、现实性、有效性

? 结构设计是总体设计阶段的任务，过程设计是详细设计阶段的任务

? 软件结构（即由模块组成的层次系统）可以用层次图或结构图描绘。

? 随着模块数增加，设计模块间接口所需工作量也增加。

? 逐步求精是规格说明技术、设计和实现技术的基础。

逐步求精定义：为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。

? 模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果。

? 耦合强弱取决于模块接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。 ? 模块间的耦合程度影响系统的可理解性、可测试性、可靠性和可维护性

? 内聚比耦合更重要。

? 深度表示软件结构中控制的层数，能粗略标识系统大小。

宽度是软件结构内同一层次上的模块总数的最大值。

扇出过大意味着模块过分复杂，扇入越大则共享该模块的上级模块越多（好）。

好的软件结构通常顶层扇出高，中层扇出较少，底层模块有高扇入。

? 面向数据流的设计方法把信息流映射成软件结构，信息流的类型（变换流、事务流）决定映

射方法。

? 经典程序设计：只允许使用顺序、IF_THEN_ELSE、DO_WHILE

扩展的结构程序设计:外加DO_CASE、DO_UNTIL

修改的结构程序设计：外加BREAK

? 系统响应时间的两个属性：长度、易变性

? 用户界面设计是一个迭代过程。

? 过程涉及工具：程序流程图、盒图、PAD图、判定表、判定树、过程设计语言PDL ? 程序复杂度定量度量：

1.McCabe方法(流图，也叫程序图)：流图中的区域数=环形复杂度=判定节点数+1

程序的环形复杂度取决于程序控制流的复杂程度，即取决于程序结构的复杂程度。所以它是对测试难度的定量度量，也能对软件可靠性预测。

2.Halstead方法（根据程序中运算符和操作数总数来度量）

? 编码和测试统称为实现。

? 程序的质量主要取决于软件设计的质量。

? 测试的目的：发现软件中的错误，根本任务：保证软件质量

? 调试的目的：诊断并改正测试中发现的错误

? 效率主要指处理机时间和存储器容量两方面。

? 用户角度：最严重的错误是导致程序不能满足用户需求的错误。

? 一旦完成了需求模型就可以着手制定测试计划，建立了设计模型之后就可以立即开始设计详

细的测试方案。

? 最佳测试效果：有最大可能性发现错误的测试

? 模块组装测试两种方法：非渐增式测试（分别测试每个模块）&渐增式测试（把下一个要测

试的同已经测好的结合起来测试）

? 渐增方式分 自顶向下集成和自底向上集成

? 为了保证加入模块没有引进新的错误，可能需要进行回归测试

? 自顶向下测试方法主要优点:不需要测试驱动程序，能够在测试阶段的早期发现接口错误。 ? 回归测试：重新执行已经做过的测试的某个子集。它用于保证由于调试或其他原因引起的变

化，不会导致非预期的软件行为或额外错误。

? 确认测试的目的：验证软件的有效性。

? 如果软件的功能和性能如同用户期望的，就是有效的

? 确认测试以用户为主，重要内容是复查软件配臵。

? 条件测试的目的不仅是检测程序条件中的错误，而且是检测程序中的其他错误。 ? 在一段程序中已经发现的错误数往往和尚未发现的错误数成正比。

? 等价划分法和边界值分析法都只孤立地考虑各个输入数据的测试功效，而未考虑多个输入数

据的组合效应。

? 软件可靠性：程序在给定的时间间隔内，按照规格说明书的规定成功运行的概率 ? 错误：由开发人员造成的bug；故障：由错误引起的软件的不正确行为

? 软件可用性：程序在给定的时间点，按照规格说明书上的规定，成功地运行的概率。 ? 预防性维护：为了改进未来的可维护性或可靠性……

? 软件维护分为 非结构化维护和结构化维护

? 维护事件流的最后一个事件是复审，它再次检验软件配臵的有效性，并保证事实上满足了维

护要求表中的要求。

? 软件的可维护性：维护人员理解、改正、改动或改进这个软件的难易程度。提高软件维护性

是支配软件工程方法学所有步骤的关键目标。

? 决定软件可维护性因素：可理解性、可测试性、可修改性、可移植性、可重用性 ? 用户文档包括：功能描述、安装文档、使用手册、参考手册、操作员指南

? 面向对象方法用对象分解取代了传统方法的功能分解。

? 对象彼此之间仅通过消息传递相互联系。

? 面向对象=对象+类+继承+消息传递通信

如果仅用对象和消息，则称为基于对象的方法，而非面向对象的方法。

如果进一步要求把所有对象都划分成类，则称为基于类的方法，仍非面向对象的方法。 只有同时使用以上4点，才是面向对象的。

? OOD不同于面向过程设计，其思想是：使用现实世界的概念抽象地思考问题而自然的解决

问题。（重要的是应用模型）

? 人在认识和解决复杂问题时最有力的思维工具是抽象。

? 传统的软件开发方法以算法为核心，开发过程基于功能分析和分解。

面向对象方法基于构造问题领域的对象模型，以对象为中心构造软件系统。

? 对象=描述属性的数据+对数据施加的操作

? 对象是具有相同状态的一组操作的集合。（从OOD看对象）

对象是对问题域中某个东西的抽象，这种抽象反映了系统保存有关这个东西的能力与他交互的能力。（从信息模拟看对象）

? 对象：以数据为中心的、主动的、实现了数据封装、本质上具有并行性、模块独立性好 ? 一个对象类型也可以看成是一种抽象数据类型

? 类：对具有相同数据和相同操作的一组相似对象的定义。

? 消息具有：接受消息的对象、消息选择符（消息名）、变元。

? 属性是对客观世界实体所具有的性质的抽象

? 继承分但继承和多重继承（多个父类），使用多重继承是要注意避免二义性。继承中，底层的

性质将屏蔽高层的同名性质。

? 多态性通过虚函数实现。

? 虚函数->实现动态联编

? 函数重载通过静态联编实现。

? OO 3models：

? 描述 系统数据结构——对象模型

? 描述 系统控制结构——动态模型

? 描述 系统功能计算——功能模型

? 典型的软件系统使用数据结构（对象模型），执行操作（动态模型）并且完成数据值的变化（功

能模型）

? 聚集表示类与类之间的关系是整体与部分的关系。

? 泛化即继承。

? 动态模型表示瞬时的、行为化的系统的“控制”性质，它规定了对象模型中的对象的合法变

化序列。

? 所有对象都具有自己的生命周期，状态是对对象属性值的一种抽象。一个触发行为称作一个

事件。

? 用状态图描绘对象的状态、触发状态转换的事件以及对象的行为（对事件的响应）。

? 每个类的动态行为用一张状态图来描绘，各个类的状态图通过共享事件合并，从而构成系统

的动态模型。动态模型是基于事件共享而相互关联的一组状态图的集合。

? 用例模型描述的是外部行为者所理解的系统功能。

? 用例是一个类，他代表一类功能而不是使用该功能的某个具体实例。用例的实例称脚本。 ? 一个用例模型的创建包括：定义系统、寻找行为者和用例、描述用力、定义用力之间的关系、

确认模型。

? 针对每个类建立的动态模型，描述了类实例的生命周期或运行周期。

? 状态转换趋势行为发生，这些行为在数据流图中->处理，在用例图中->用例，同时与类图中

的服务对应

? 数据流图的对应：

数据存储，原点/终点：对象

数据流：对象的属性值或对象

对象模型描述了数据流图中的数据流、数据存储以及数据原点/终点的结构。

? 分析过程总是提取系统需求的过程。

? 需求陈述的内容：问题范围、功能需求、性能需求、应用环境、假设条件

? 面向对象分析首要的工作：建立问题域的对象模型。

? 对象模型的建立：

确定对象类和关联

给类增添属性

用适当的继承关系合并组织类

建立了动态模型和功能模型后，再定义类中的操作

? 应该按问题领域而不是功能分解方法来确定主题。

? 脚本描述事件序列

? 从OOA到OOD，是一个逐渐扩充模型的过程，OOD即是用OO的观点建立求解域模型

的过程。

?

?

?

?

?

?

?

? OO中，对象是最基本的模块。 对象之间，应降低交互耦合，提高继承耦合。 对象间存在 服务内聚、雷内聚、一般-特殊内聚。 OOD准则：模块化、抽象、信息隐藏、若耦合、强内聚、可重用。 类构件的三种重用方式：实例重用（最基本的重用）、继承重用和多态重用。 系统的总框架是基于问题域的。 设计实现服务的算法：算法复杂度、易理解、易实现、容易修改 程序设计风格中从所完成的功能看，有两类不同类型的方法：

策略方法：检查系统运行状态，处理出错情况，并不直接完成计算或实现复杂算法。 实现方法：仅针对具体数据完成特定处理，用于实现复杂算法。

? OO测试：单元测试、集成测试、确认测试