《软件工程》自考02333 重点难点汇集 - 图文

《软件工程》串讲讲义 应考指导

一、课程介绍 1、课程性质

《软件工程》是全国高等教育自学考试计算机及应用（独立本科段）的一门专业课。 软件工程是研究软件开发的一门课程，其主要内容包括：软件开发所需要的过程、活动和任务，以及这些活动和任务的组织、实施和管理。 2、指定教材

本课程指定教材为《软件工程》，全国高等教育自学考试指导委员会组编，王立福主编，机械工业出版社出版，2011年版。

新版教材与2000年版相比，无论是内容还是内容的组织，都有了很大的变化。整个知识体系、章节安排、内容选取都不一样，这是考生一定要注意的。新版教材的内容组织特点主要体现在：

基于对软件开发本质的认识，讲解软件工程的两大技术问题：一是开发逻辑，二是开发途径。

开发逻辑涉及软件生存周期过程、软件生存周期模型（有关过程、活动和任务的组织框架）以及项目软件生存周期的规划与监控。

开发途径涉及结构化方法和面向对象方法，以及支持软件评估所需要的软件测试技术等。 3、章节体系

本课程共有8章：

第1章：回答什么是软件开发的本质 第2章：软件需求与软件需求规约 第3章：结构化方法 第4章：面向对象方法-UML 第5章：面向对象方法-RUP 第6章：软件测试。

第7章：软件生存周期过程及管理 第8章：集成化能力成熟度模型CMMI 二、考情分析

1

1. 历年真题的分布情况

由于教材刚刚经过改版，新教材刚经过2011年10月、2012年01月、2012年10月三次考试。 通过对2011年10月、2012年01月这两次真题的分析，各章所占分值的分布情况如下表所示：

年 份 章名、题型 一、绪论（单项、填空题） 二、软件需求与软件需求规约 三、结构化方法（单、填、简答、综合） 四、面向对象方法-UML（单、填、简答） 五、面向对象方法-RUP（单、填、简答） 六、软件测试（单、填、简答、综合） 七、软件生存周期过程及管理（单、填、简） 八、集成化能力成熟度模型CMMI 5 5 2011-10 3分 9 25分 11分 12分 25分 10分 2012-01 3分 11 25分 11分 12分 23分 10分 从上面的统计数据可以看出：主要的分值分布在第3章和第6章，分别占到总分的25%左右。第1章和第8章的考核知识点相对较少。 2. 题型分析

本课程的考试题型分为：

（1） 单项选择题，共15小题，每小题2分，共30分 （2） 填空题，共20个空，每空1分，共20分 （3） 简答题，共6小题，每小题5分，共30分 （4） 综合应用题，共2题，每题10分，共20分 3. 复习方法

（1）以教学大纲为准绳。自学考试的原则是：考试范围既不超出大纲又不超出教材范围。所以考生一定根据教学大纲规定的考试内容和考核要求，认真学习教材，要全面、系统了解教材中的基本概念、基本知识。

（2）有的放矢。在学习的过程中，为了达到“事半功倍”，要学会“舍”。要用有限的时间去抓重点，对重点内容要进行深入细致的学习。

2

（3）注意学习方法，理论联系实际，注重理解

重视理论联系实际，训练并逐渐提高运用所学理论分析和解决实际案例的能力。考生应当注意在全面系统学习教材的基础上，尽可能多地了解和分析实际案例，以便更深刻地领会教材的内容，提高分析和解决实际问题的能力。

（4）合理安排时间，抓住学习重点

根据实际情况自己安排，利用平时空余时间观看网络课件，形成基本的了解。接下来认真地做一些练习题，不清楚的地方再回过头去看看书，并注意对不同的知识点进行比较，加深印象。

第一章 绪论

复习建议：

本章内容较少，主要是让大家了解软件工程的提出的背景-软件危机以及软件工程研究的内容。

考试题目类型主要是单项选择题、填空题，题量在3%~5%之间。

第一节 软件工程概念的提出与发展

1. 软件危机

（1） 速度：软件的发展水平远远滞后于硬件的发展水平，生产率低下，软件制造仍然是一种人工集约生产方式

（2） 质量：软件的质量低下，不能满足用户的需求、适应性差 （3） 成本：软件开发成本居高不下

软件开发的速度、软件制品的质量、软件开发成本是软件工程的三个核心问题。 2. 软件工程的发展 （1）20世纪60~80年代

瀑布模型；过程化语言；支持工具 （2）20世纪80年代~今

软件复用技术；软件生产管理；面向对象语言 （3）近几年

3

软件复用技术：构件技术、平台技术、需求工程技术、领域分析技术、应用集成技术等。

第二节 软件开发的本质

1. 软件 软件=程序+文档

2. 软件开发的本质：“映射”，即实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。

3. 系统建模

运用所掌握的知识，通过抽象，给出系统的一个结构。 4. 模型

模型是一个抽象。模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统边界的描述、对系统内各模型元素以及它们之间关系的语义描述。

5. 系统模型的类型

（1） 概念模型：描述软件是什么

（2） 软件模型：实现概念模型的软件解决方案。包括设计模型、实现模型和部署模型。

第二章 需求获取

复习建议：

正确定义问题，是解决问题的基础。

需求获取是软件开发的第一步，它的工作质量决定了整个软件开发工作的成败，因此本章的内容是考核的重点内容。

考核的题目类型主要有：单项选择题、填空题、简答题，分值在10%左右。 内容以基本概念、基本原理为主。

第一节 需求与需求获取

1. 需求的定义

一个需求是有关一个“要予构造”的陈述，描述了待开发产品/系统功能能力、性能参数或其它性质。 2.

需求的基本性质

4

（1） 必要的 （2） 无歧义的 （3） 可测的 （4） 可跟踪的 （5） 可测量的 3.

需求的分类 ★

（1） 功能需求，是整个需求的主体。

（2） 非功能需求：性能需求、外部接口需求、设计约束和质量属性需求。 能够区分哪些是功能需求，哪些是性能需求。 4.

接口需求的类别

（1） 用户接口 （2） 硬件接口 （3） 软件接口 （4） 通信接口 （5） 内存约束 （6） 运行 （7） 地点需求 5.

设计约束需求

（1） 法规政策 （2） 硬件限制 （3） 与其它应用的接口 （4） 并发操作 （5） 审计能力 （6） 控制功能 （7） 高级语言要求 （8） 握手协议 （9） 应用的关键程度 （10） 安全和保密 6.

质量属性

（1） 可靠性 （2） 存活性

5

（3） 可维护性 （4） 用户友好性 7.

需求发现的技术

（1） 自悟 （2） 交谈 （3） 观察 （4） 小组会 （5） 提炼 第二节 需求规约（SRS）

1. 需求规约的定义 ★

是一个软件/产品/系统所有需求陈述的正式文档，它表达了一个软件/产品/系统的概念模型。2. 需求规约的基本性质 ★

（1） 重要性和稳定性程度：对需求进行分级 （2） 可修改的

（3） 完整的：没有被遗漏的需求 （4） 一致的：不存在互斥的需求 3. 需求规约的格式

IEEE标准830-1998(IEEE 1998)描述的需求规格说明书模板。

6

4. 需求规约（规格说明书）的表达 （1） 非形式化的需求规约 （2） 半形式化的需求规约 （3） 形式化的需求规约 5. 需求规约的作用 ★ 7

（1） 需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现 （2） 需求规约是一个管理控制点

（3） 对于产品/系统的而设计，需求规约是一个正式的、受控的起始点 （4） 需求规约是创建产品验收计划和用户指南的基础

第三章 结构化方法

复习建议：

自顶向下，逐步求精。

本章是整个课程的重点内容，其基本思想、基本原理和基本方法是软件工程理论体系中最经典的内容，考核题型涉及单项选择题、填空题、简答题、综合应用题所有题目类型，占分值25%左右。

建议考生在牢记基本概念、基本原理的基础上，对综合应用题多下工夫，多做练习。

第一节 结构化需求分析

1. 需求分析面临的挑战

（1） 问题空间理解

（2） 人与人之间的通信，“有效沟通” （3） 需求的变化性

2. 结构化分析中的基本术语及表示方法

（1） 数据流

（2） 加工

（3） 数据存储

（4） 数据源和数据潭

8

3. 数据流图DFD图 ★

用于建立系统功能模型。

是一种描述数据变换的图形化工具，其中包含的元素可以是数据流、数据存储、加工、数据源和数据潭等。

4. 建模过程（绘制流程图的过程）

自顶向下、功能分解 （1） 建立系统环境图

（2） 0层图：从0层图开始对流程图中的要素编号 （3） 1层图 （4） ……

【例题】绘制数据流程图（2008年10月真题） 41.某个学生成绩管理系统的部分功能如下：

（1）基本信息管理：教务管理人员输入或修改学期教学执行计划、学生名单和教师名单； （2）学生选课：学生根据教学执行计划进行选课；

（3）分配任课教师：教务管理人员为符合开课条件的课程分配教师，并打印任课通知单给教师； （4）成绩管理：每门课程的教师在考试评分结束后将考试成绩交给教务管理人员，教务管理人员输入、维护成绩，系统可生成成绩单（发给学生）、成绩统计分析表（发给教务管理人员）。

请根据要求画出该问题的分层数据流图（要求画出顶层和0层数据流图）。 【解析】

顶层图：只包含数据源/数据潭以及相关的数据流和一个处理。

顶层图

选课信息 成绩单 成绩录入 9

学生成绩

教师 任课通知单 成绩管理系统 成绩单

学生 选课信息 成绩单 任课通知单 教师 学生

基本信息处理 学生选课 任课安排 学期教学执行计划 学生名单 学生选课结果 教师信息

0层图

要注意的问题：

①??

黑洞(black hole)，即只有输入而没有输出。

②只有输出而没有输入。

③灰洞(gray hole)，即输入不足以产生输出。灰洞是经常也是不易被察觉的错误。 ④加工处理只用来表示数据的处理和变化，避免将计算机命令作为处理。

⑤数据流必须起于且/或止于处理，即每一个数据流必须有一个处理与之有关，数据流不能起于数据存贮且止于一个数据源/数据潭或另一个数据存贮；也不能起于某个实体且止于另一个数据源/数据潭或数据存贮。 5. 数据字典

定义数据流程图中所有数据流和数据存储的数据结构。 顺序结构：+ 选择结构：| 重复结构：{ } 子界：m..n 6. 加工的描述 ★

（1） 判定表

判断表(Decision Table)也称为决策表，是一个二维表，它说明了每一种条件组合所产生的结果。 该表分为四个象限(quadrants)。

a)

左上限代表所有的条件

b) 左下限代表可能的结果 c)

右上限代表每一种条件的取值(用Y和N来表示)

d) 右下限用X表示所对应的条件组合所产生的结果

10

【例题】画出顾客购货的折扣政策的决策表。

销售商在给顾客的折扣时，要考虑付款日期和交易额这两个因素。若付款日期在10天以内(含10天)，则当交易额超过￥10,000时，给予5％的折扣；当交易额在￥5,000到￥10,000之间(含￥5,000)时，给予3％的折扣；当交易额低于￥5,000时，没有折扣。若付款日期超过10天，则无论交易额多少，均不给任何折扣。 【解析】

（2） 判定树

判断树 (Decision Tree)也称为决策树，是用来描述在一组不同的条件下，决策的行动是根据不同条件及其取值来选择的处理过程。业务规则的描述通常可以使用判断树这一过程描述工具。

11

【例题】画出顾客购货的折扣政策的决策树。

销售商在给顾客的折扣时，要考虑付款日期和交易额这两个因素。若付款日期在10天以内(含10天)，则当交易额超过￥10,000时，给予5％的折扣；当交易额在￥5,000到￥10,000之间(含￥5,000)时，给予3％的折扣；当交易额低于￥5,000时，没有折扣。若付款日期超过10天，则无论交易额多少，均不给任何折扣。 解析：

（3） 结构化语言

【例题】用结构化语言表达：顾客购货的折扣政策。

销售商在给顾客的折扣时，要考虑付款日期和交易额这两个因素。若付款日期在10天以内(含10天)，则当交易额超过￥10,000时，给予3％的折扣；当交易额在￥5,000到￥10,000之间(含￥5,000)时，给予2％的折扣；当交易额低于￥5,000时，没有折扣。若付款日期超过10天，则无论交易额多少，均不给任何折扣。

IF 付款日期在10日以上 折扣=0 ELSE

IF 交易额>=10000 折扣=3% ELSE

IF交易额>=5000 折扣=2% ELSE 折扣=0 7. 需求验证

（1） 验证每一个需求满足5个性质 （2） 验证需求规格说明书满足4个性质

12

第二节 结构化设计

分为总体设计和详细设计 1. 总体设计的任务

把系统的功能需求分配到一个特定的软件体系结构中。 2. 表达软件体系结构的工具 （1）模块结构图 （2）层次图 （3）HIPO图 3. 模块结构图 ★

结构图(Structure Chart)是对软件总体结构的一种图形描述，它显示了软件的层次结构、组织和通讯。也就是说，在结构图中，显示了软件是由哪些模块组成的，这些模块按照什么样的层次结构组织在一起以及模块之间通过什么接口联系在一起。

结构图也称之为控制结构图、模块结构图或系统结构图。

（1） 模块符号 （2） 模块调用关系 （3） 模块间的数据传递 （4） 模块间的控制信息传递

13

（5） 循环调用结构 （6） 选择调用结构 （7） 数据存储 4. 层次图

层次图中一个矩形框代表一个模块，框间的连线表示调用关系（位于上方的矩形框所代表的模块调用位于下方的矩形框所代表的模块）。

5. HIPO图

HIPO图是美国IBM公司发明的“层次图加输入/处理/输出图”的英文缩写。为了使HIPO图具有可追踪性，在H图(即层次图)里除了顶层的方框之外，每个方框都加了编号。

H图+IPO图

6. 总体设计步骤

将DFD图映射为设计层面的模块及模块调用。

（1） 变换流(Transform Flow)。基于变换流的数据流程图是一个线性的顺序结构，由输入臂、输出臂和

14

变换中心三部分组成。其中变换中心使系统数据发生本质的变化，输入臂将物理输入变换成逻辑输入，而输

出臂则将逻辑输出变换成物理输出。

（2） 事务流(Transaction Flow)。事务流的数据流程图中有一个事务处理中心，它将输入分为许多相互平行的加工路径，然后根据输入的属性，选择某一加工路径。如下图所示。

业务中心完成以下任务：

? ⑴接收事务(即输入数据)； ? ⑵分析每个事务并确定它的类型； ? ⑶根据事务的类型选取一条活动通路。

15

【例题】控制结构图的绘制

根据数据计算的数据流图：

输入数据 数据求解 打印输出

画出以转换为中心的控制结构图。

【解析】这是一个典型的以“转换为中心”结构的分解，可以转化为：

数据计算 输入数据 数据求解 打印输出

总结：任何处理都可以划分为两种转换类型之一：以转换为中心的分解和以业务为中心结构的分解。

【例题】产生固定资产资料数据流程图如下，做出以业务为中心的模块控制结构图。

16

【解析】

这是以业务为中心的处理，根据模板，可以转化为：

7. 模块

执行一个特殊任务的一个过程以及相关的数据结构。模块通常由两部分组成：模块接口和模块体。 8. 模块化

“分而治之”和“抽象”。

把一个待开发的软件分解成若干个简单的、具有高内聚低耦合的模块，这一过程称为模块化。 模块化是系统设计基本原理/原则之一。

9. 内聚(Cohesion)

是指一个模块内部个成分之间相互关联程度的度量。也就是说，凝聚是对模块内各处理动作组合强度的一种度量。很显然，一个模块的内聚越大越好。

（1）偶然凝聚 可维护性最差 （2）逻辑凝聚 （3） 时间凝聚 （4）过程内聚

固定资产卡片 资产变动表 折旧汇总表 固定资产明细表 报表类型 报表调度 报表制作

17

（5）通信内聚 （6）顺序凝聚

（7）功能凝聚 可维护性最好 10. 模块耦合

耦合(coupling)是对两个模块之间联接程度的一种度量。模块间的依赖程度越大，则其耦合程度也就越大；反之，模块间的依赖程度越小，则其耦合程度也就越小。

很显然，为了使软件具有较好的可维护性和可修改性，模块间的关联程度即耦合程度应越小越好。因为耦合程度越小，表明模块间的独立程度越大，这样在修改一个模块时，对其它模块的影响程度就越小，从而使模块的修改工作局限于一个最小范围之内。

（1） 内容耦合 （2） 公共耦合 （3） 数据耦合 （4） 控制耦合 （5） 标记耦合

原则是：尽量用数据耦合，少用控制耦合，限制公共耦合的范围，避免使用内容耦合。 11. 启发式规则 高内聚、低耦合。

（1） 改进软件结构，提高软件独立性。模块分解 （2） 模块规模适中

（3） 力求深度、宽度、扇出、扇入适中。

深度：表示其控制的层数。

宽度：同一层次上模块总数的最大值。 扇出：一个模块直接控制的下级模块的数目。 扇入：有多少个上级模块直接调用它。

原则：顶层模块扇出比较大，中间层模块扇出较小，底层模块具有较大的扇入。 （4） 尽量使模块的作用域在其控制域内。

模块的控制域：这个模块本身以及所有直接或间接从属它的模块的集合。 模块的作用域：受该模块内一个判断所影响的所有模块的集合。 （5） 尽力降低模块接口的复杂度 （6） 力求模块功能可以预测 12. 详细设计

具体描述模块结构图中的每一模块，即给出实现模块功能的实施机制，包括一组例程和数据结构。

18

13. 结构化程序设计方法

一种基于结构的编程方法，即采用顺序结构、选择结构和重复结构进行编程，其中每一结构只允许一个入口和一个出口。

三种基本的控制结构：

(a) 顺序结构，先执行A再执行B(b) IF-THEN-ELSE型选择(分支)(c)DO-WHILE型循环结构

14. 详细设计工具 （1） 程序流程图

程序流程图：程序流程图又称为程序框图，它是历史最悠久使用最广泛的描述过程设计的方法，然而它也是用得最混乱的一种方法。

（2） 盒图（N-S图）

出于要有一种不允许违背结构程序设计精神的图形工具的考虑，Nassi和Shneiderman提出了盒图，又称为N-S图。

19

(a) 顺序；(b) IF-THEN-ELSE型分支；(c) CASE型多分支； (d) 循环；(e) 调用子程序A （3） PAD图

PAD是问题分析图(Problem Analysis Diagram)的英文缩写，自1973年由日本日立公司发明以后，已得到一定程度的推广。它用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易。下图给出PAD图的基本符号。

（4） 类程序设计语言PDL

PDL也称为伪码，它是用正文形式表示数据和处理过程的设计工具。

PDL具有严格的关键字外部语法，用于定义控制结构和数据结构；另一方面，PDL表示实际操作和条件的内部语法通常又是灵活自由的，以便可以适应各种工程项目的需要。因此，一般说来PDL是一种“混杂”语言，它使用一种语言（通常是某种自然语言）的词汇，同时却使用另一种语言（某种结构化的程序设计语

20

第三节 软件测试步骤

软件测试是按照与系统开发相反的方向来进行的。依次为：单元测试(模块测试)、集成测试、有效性测试和系统测试。

1． 单元测试

单元测试（Unit Testing）又称模块测试（Module Testing），或模块分调，用于测试单个程序模块，确定模块的逻辑和功能是否正确。

单元测试采用白盒测试技术。 （1） 模块接口 （2） 局部数据结构 （3） 重要的执行路径 （4） 错误执行路径 驱动模块和承接模块。 2．集成测试

集成测试(Integration Testing)用来测试模块之间接口的正确性，也即模块之间的数据和控制传递。集成测试是与单元测试平行进行的。

集成测试采用黑盒测试技术。

（1） 自顶向下的集成测试：需要设计承接模块 （2） 自底向上的集成测试：需求设计驱动模块 3．有效性测试

目的：发现软件实现的功能与需求规格说明书不一致的错误。 方法：采用黑盒测试技术

第七章 软件生存周期过程与管理

复习建议

开发逻辑，是获取正确软件的关键！

围绕生命周期的阶段划分，掌握每一阶段的任务、内容、工作方法、工作成果。 题目类型包括单项选择题、填空题、简答题，分值在10%左右。

第一节 软件生存周期过程概述

46

1. 软件生存周期(SDLC，软件生命周期)

是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。

一般来说，软件生存周包括计划、开发、运行三个时期，每一时期又可分为若干更小的阶段。计划时期的主要任务是分析用户要求，分析新系统的主要目标以及开发该系统的可行性。开发时期要完成设计和实现两大任务具体。具体分为需求分析、概要设计、详细设计、编码、测试。其中编码和测试是软件开发期的最后两个阶段。运行时期是软件生存周期的最后一个时期，软件人员在这一时期的工作，主要是做好软件维护。

2. 基本过程

指那些与软件生产直接相关的活动集。 （1） 获取过程 （2） 供应过程 （3） 开发过程 （4） 运行过程 （5） 维护过程 3. 开发过程

软件开发者所从事的一系列活动和任务。将一组需求转换为一个软件产品或系统。 （1） 过程实现 （2） 系统需求分析 （3） 系统体系结构设计 （4） 软件需求分析 （5） 软件体系结构设计 （6） 软件详细设计 （7） 软件编码和测试 （8） 软件集成 （9） 软件合格性测试 （10） 系统集成 （11） 系统合格性测试 （12） 软件安装 （13） 软件验收支持 4. 过程实现

47

（1） 选择合适的生存周期模型

（2） 选择相应的标准、方法、工具和程序设计语言 （3） 制定实施开发计划

（4） 可以使用一些非交付的软件项。 5. 系统需求分析

（1） 建立系统需求规格说明 （2） 对系统需求进行评估

a) 有关获取方面需要的可追踪性 b) 有关获取方面需要的一致性 c)可测试性

d) 系统体系结构设计的可行性 e)运行与维护的可行性 6. 系统体系结构设计

（1） 建立系统的顶层体系结构

（2） 对体系结构及每一项的需求进行评估

a)

系统需求的可追踪性

b) 与系统需求的一致性 c)

所使用的设计标准和方法的适宜性

d) 软件项满足其所分配的需求的可行性 e)

运行与维护的可行性

7. 软件需求分析

（1） 建立软件需求规格说明

a) 功能与能力的规格说明 b) 该软件项的外部接口 c) 合格性需求 d) 有关安全的规格说明 e) 有关保密的规格说明 f) 人因工程的规格说明 g) 数据定义和数据库需求 h) 用户文档

i) 用户操作与执行需求 j) 用户维护需求

48

（2） 对软件需求进行评估

a) 对系统需求和系统设计的可追溯性 b) 与系统需求的外部一致性 c) 内部一致性 d) 可测试性 e) 软件设计的可行性 f) 运行和维护的可行性 （3） 联合复审 8. 软件体系结构设计

（1） 把对软件项的需求转变为一种体系结构

（2） 对该软件项的外部接口和各构件之间的接口进行顶层设计 （3） 进行数据库的顶层设计 （4） 编制用户文档的最初版本

（5） 为软件集成定义初步的测试需求文档

（6） 对软件项的体系结构、接口和数据库设计进行评估 （7） 实施联合评审 9. 支持过程

是指有关各方按他们的目标所从事的一系列支持活动集。支持活动有助于提高系统或软件产品的质量。 （1） 文档过程 （2） 配置管理过程 （3） 质量保证过程 （4） 验证过程 （5） 确认过程 （6） 联合评审过程 （7） 审计过程 （8） 问题解决过程 10. 支持过程—配置管理过程

应用管理上、技术上的规程来支持整个软件生存周期的过程。 （1） 过程实现：编制配置管理计划 （2） 配置标识

（3） 配置控制：标识并记录变更请求 （4） 配置状态统计：编制管理记录和状态报告

49

（5） 配置评价 （6） 发布管理和交付 11. 组织过程

与软件生产组织有关的活动集。 （1） 管理过程 （2） 基础设施过程 （3） 培训过程 （4） 改进过程 12. 组织过程—管理过程 （1） 启动与范围定义 （2） 规划 （3） 测量 （4） 执行与控制 （5） 评审与评价 （6） 结束处理

13. ISO/IEC系统与软件工程-软件生存周期过程12207-2008

2个过程类、7个过程组、43个过程。 “系统语境的过程”和“软件开发的过程”。 （1） 协议过程组 （2） 项目过程组 （3） 技术过程组

（4） 组织上项目使能过程组 （5） 软件实现过程组 （6） 软件支持过程组 （7） 软件复用过程组

第二节 过程描述1. 过程描述 过程→活动→任务 2.

供应过程 活动1：机遇标识 活动2：供应方投标

50

言）的语法。

可以作为注释工具直接插在源程序中间。

15. 设计规约

完整准确地描述满足需求规约所要求的所有功能模块，以及伴随功能模块而出现的非功能机制。 设计规约包括概要设计规约和详细设计规约。 （1） 概要设计规约 指明高层软件体系结构。

? 系统环境 ? 软件模块的结构 ? 模块描述

? 文件结构和全局数据文件的逻辑结构 ? 测试需求 （2） 详细设计规约

? 各处理过程的算法

? 算法所涉及的全部数据结构的描述

【例题】根据下列变换型的数据流图，设计出初始软件结构图。

题40图

【答案】

主控模块

21

输 入 A

输入B 输入模块 f5 f5 F9 F9 变换模块 输出模块G 变换C 变换D 变换 E 变换F 【解析】这是一个典型的变换型数据流程图，将其转换为模块控制图时，第一层可以分解为三个模块：输入模块、变换模块、输出模块。每一模块还可以继续分解。

第四章 面向对象方法UML

复习建议：

以不变应万变。

统一建模语言（Unified Modeling Language，UML）

UML是目前流行的建模语言，特别是在网站开发中广泛应用。

UML涉及很多的图，每一种图都有不同的图形符号、作用，在什么情况下用何种图来描述是本章的重点内容。

考核题目类型包括单项选择题、填空题、简答题，分值在10%~15%之间。需要考生掌握各种UML图的作用。

面向对象建模过程的步骤： （1） 需求获取

a) 建立用况（use case）模型和用况场景 （2） 需求分析

a) 建立活动图和状态图 b) 类图（建立域模型）

22

c) 顺序图（实现用况） （3） 编写需求规格说明书 （4） 需求验证

第一节 UML术语表

1. 对象（object）

对象（object）是系统中用来描述客观事物的一个实体。一个对象由一组属性和对这组属性进行操作的一组方法组成。

对象只描述客观事物本质的与系统目标有关的特征。

对象之间通过消息通信，一个对象通过向另一个对象发送消息激活某一个功能。 2. 类

类（Class）是具有相同属性、操作、关系和语义的一组对象的集合，它为属于该类的全部对象提供了同一的抽象描述，其内部包括属性和服务两个主要部分。

类有超类（Superclass）和子类（Subclass）之分。

（相对而言）对象与类的关系犹如程序设计语言中变量和类型的关系。对象是类的实例（Instance）。 类在类图上使用包含三个部分的矩形来描述，如下图4-1所示。最上面的部分显示类的名称，中间部分包含类的属性，最下面的部分包含类的操作（或者说\方法\）。

图4-1：类图中的示例类对象

3. 属性

对象或类的属性（attributes）描述了对象的具体特征。属性有属性名和属性值（或称属性状态）。 每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。 UML规定类的属性的语法为：

可见性 属性名 ： 类型 = 缺省值 {性质串}

可见性：public（+） 、protected（#）、private（-）、包内的（~） 4. 类的操作

通常也被称为功能，但是它们被约束在类的内部，只能作用到该类的对象上。操作名、返回类型和参数表组成操作界面。

UML规定操作的语法为:

可见性 操作名 （参数表） : 返回类型 {性质串}

23

例如：+取客户地址（客户名:字符串）：字符串 5. 接口

接口是操作的一个集合，其中每个操作描述了类、构件或子系统的一个服务。

（1） 采用具有分栏和关键字的矩形符号来表示 （2） 采用小圆圈和半圆圈来表示

6. 协作

协作是一个交互，涉及交互的三要素：交互各方、交互方式以及交互内容。 7. 用况（use case）/用况

对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果。 8. 主动类

至少具有一个进程或线程的类。能够启动系统的控制活动，并且其对象的行为通常与其它元素行为并发的。

表示方法：两条竖线。 9. 构件

系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现。

10. 制品

系统中包含物理信息的、可替代的物理部件。 11. 节点

节点是在运行时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源。

24

12. 关联（Association）

关联反映了类和类之间的静态关系。关联在模型中，特别是在永久业务对象模型中是最基本的关系。 链（link）是对象之间具有特定语义关系的抽象。 （1） 关联名 （2） 导航 （3） 角色 （4） 可见性

（5） 多重性：多重性（Multiplicity）定义了与一个对象/类相联系的对象/类出现一次，该对象/类可能出现的最小和最大的数目。

（6） 限定符

（7） 聚合：一个类是另一类的一部分。

（8） 组合：是聚合的一种特殊形式

（9） 关联类 （10） 约束

13. 泛化/继承

继承：特殊类（子类）的对象拥有其一般类（超类）的全部属性与服务，称作特殊类对一般类的继承（Inheritance） 。利用继承（inheritance），子类可以继承父类的属性和方法。子类／父类也可分别叫做特殊类／一般类、子类／超类、派生类／基类等。

继承反映了类之间的一种联系或结构:一般-特殊结构，也称分类结构（Classification Structure），是由一组具有继承关系的类所组成的结构。仅由一些单继承关系的类形成的结构又称作层次结构（Hierarchy Structure）；由一些存在多继承关系的类形成的结构又称作网格结构（Lattice Structure）。

25

14. 多态性（Polymorphism）

是指一般类中定义的属性或服务被特殊类继承之后，可以具有不同的数据类型或表现出不同的行为。这使得同一属性或服务名在一般类及其各个特殊类中具有不同的语义。

多态是指用同一界面形式表示不同对象类中的不同实现的能力。 多态性的实现基于两个基本原理：封装和泛化。 多态性实现的方法：

（1）泛化

（2）定义一个抽象类——接口类 15. 细化

细化是类目之间的语义关系，其中一个类目规约了保证另一类目执行的契约。 用空心三角形的虚线表示。 16. 依赖

依赖是一种使用关系，用于描述一个类目使用另一类目的信息和服务。 用有向虚线段表示。 17. 包

包是模型元素的一个分组，一个包本身可以被嵌套在其它包中，并且可以含有子包和其它类型的模型元素。

26

第二节 UML的模型表达格式

图形化工具。 图的类别： （一）结构图

（1）对象结构建模—类图和对象图

（2）应用结构建模—包图、构件图、部署图、组合结构图 （二）行为图

对象交互建模—顺序图、协作图（通信图、交互综述图、定时图）、状态图（状态机） 对象行为建模—用况图、活动图

1. 类图

任何系统都需要从两方面进行描述：结构信息和行为信息。系统的组成表达了系统各组成要素之间的联系，称为结构；这些组成要素的执行逻辑称为行为。在面向对象方法中，系统的结构信息是通过类图（class diagram）来描述的；而系统行为信息则通过用况图、交互图（包括顺序图和协作图）和状态图来描述的。也就是说，前者说明了系统的组成部分是什么，而后者则说明了系统做什么。

类图（class diagram）表达了系统的静态结构信息，即系统是由哪些类组成的，这些类之间的关系是什么。 类图显示系统各个部分以及怎样将它们组装起来;但却不能模拟组装后系统的工作情况。 构造类图的三个关键问题是： （1） 系统中有哪些需要关心的类？ （2） 这些类是如何描述的？ （3） 这些类之间的联系是什么？

27

创建一个系统的类图，要涉及4方面的工作： （1） 模型化待建系统中的概念，形成类图中基本元素 （2）模型化待建系统中的各种关系，形成该系统的初始关系。 （3）模型化系统中的协作，给出该系统的最终类图。 （4）模型化逻辑数据库模式

2. 用况图（use case 图）

用况是对一个参与者（actor）使用系统的一项功能时所进行的交互过程的一个文字描述序列。 用况是系统、子系统或类 与 外部的参与者（actor）交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。

用况图（Use Case Diagram）是指反映活动者，系统边界所封闭的用况，及活动者与用况之间，用况与用况之间关系的一种图。

6个模型元素： （1） 主题 （2） 用况 （3） 参与者：

? 系统用户: 是最常见的一种角色。是直接使用系统的人。

? 另一个系统：如DSS可作为MIS的一个活动者。补货系统可作为定单处理系统的活动者。 ? 时间：当经过一定时间触发系统中的某个事件时，时间就成了角色。例如定期的某些业务处理工作。 （4） 关联 （5） 泛化

28

（6） 依赖

3. 状态图

对象或者类的整体行为的某些规则所能适应的对象或类的状况、情况、条件、形式或生存周期。仅当对象的行为规则不同时，才称对象处于不同的状态。

在由对象的全部属性的属性值集合所构成的笛卡儿乘积中的每一个等价集合（即，使对象的服务呈现相同行为规则的属性值的集合）称之为对象的一种状态。

例如，对象发票（invoice）可以根据其付款的情况分为三个状态：未付款（unpaid）、部分付款（partly paid）以及付清款（fully paid）。

状态图（state chart diagram）使用状态、事件和转换来记录对象在其生命周期中所历经的状态序列。

29

① 对象的初始状态是图中任何事件都未对该对象起作用时的状态。 ② 状态代表对象生命周期中的某一瞬间。

③ 转换表明作为对事件的响应结果，对象将从一种状态转换到另一种状态并执行某个动作。

④ 触发状态转换的事件在状态转换字符串中命名。双击一个状态转换，除事件签名以外，还可用字符串为其加注临界条件、动作表达式等标签。

4. 顺序图

顺序图（sequence diagram）表示了对象之间传送消息的时间顺序，也就是对象之间的交互顺序，这些交互是指在场景或用况的事件流中发生的。每一个对象（类）用一条生命线来表示——即用垂直线代表整个交互过程中对象的生命期。生命线之间的箭头连线代表消息。

顺序图中的基本元素包括： ① 活动者，指用况中的活动者。 ② 对象，指在用况中的内部对象。

③ 生命线：在顺序图中的一个对象下面的竖线，用以显示这个对象的生命期。时间从上到下流过。生命线实际上显示了消息的顺序，在生命线之上的消息比在它之下的消息先发生。在生命线中的棒形方框表示的是活动生命线，用以强调一个对象只有在一个场景的部分中处于活动状态。

④ 消息，指场景内由事件流定义的内部事件成为在对象和活动者或其他对象之间的消息。

partial paymentUnpaidPartly Paidpartial paymentpartial paymentFully Paid

30

? 同步消息——返回消息。同步消息假定有一个返回消息。同步消息用有实心的箭头表示；返回消息用虚线、箭头也不是实心来表示。

? 反身消息——消息的发送方和接收方是同一个对象。 ? 异步消息——没有返回值的消息。用非实心箭头表示。

? 定时消息——对消息附加时间约束条件，包括：发送时间、接收时间、已用时间等。

第五章 面向对象方法-RUP

复习建议：

RUP（Rational Unified Process，统一软件开发过程）。 掌握RUP在解决下列三个问题的基本方法。

（1） 表达基本信息的术语 （2） 用于组织基本信息的表达格式

（3） 在不同抽象层之间进行“映射”的过程指导。

本章考核题目类型包括单项选择题、填空题、简答题，分值在10%~15%之间。 重点要掌握基本概念、基本原理。

1．迭代式开发

在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程都可以执行版本结束，可以鼓舞开发人员。

2．管理需求

31

确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用况和脚本的使用已被证明是捕获功能性需求的有效方法。

3．体系结构

组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于降低管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。

4．可视化建模

RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。

5．验证软件质量

在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。

6．控制软件变更

迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。

第一节 RUP的特点

以用况驱动的、以体系结构为中心的迭代、增量式开发。

1. 用况驱动

（1） 用况是能够向用户提供有价值结果的系统中的一种功能 （2） 用况获取的是功能需求

在系统的生存周期中，以用况作为基础，驱动系统有关人员对所要建立系统的功能需求进行交流，驱动系统分析、设计、实现和测试等活动，包括制定计划、分配任务、监控执行和进行测试等，并将它们有机地组织在一起，使各个阶段中都可以回溯到用户的实际需求。

2. 以体系结构为中心

系统体系结构：是对系统语义的概括描述，对所有项目有关人员都是可以理解的。 3. 迭代与增量

32

（1） 迭代是重复的部分 （2） 增量是增加的部分

一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。

图5-1 RUP迭代模型

二维开发模型：

RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle）、阶段（Phase）、迭代（Iteration）和里程碑(Milestone）；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动（Activity）、产物（Artifact）、工作者（Worker）和工作流（Workflow）。如图1：

RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。每个阶段结束于一个主要的里程碑（Major Milestones）；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

33

图5-2：RUP二维开发模型

（1） 初始阶段

初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。初始阶段结束时是第一个重要的里程碑：生命周期目标（Lifecycle Objective）里程碑。生命周期目标里程碑评价项目基本的生存能力。

（2） 细化阶段

细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。细化阶段结束时第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

（3）构造阶段

在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑决定了产品是否可以在

34

测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称

为“beta”版。

（4）交付阶段

交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

第二节 核心工作流

RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。

（1）商业建模

商业建模（Business Modeling）工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用况模型和商业对象模型中定义组织的过程，角色和责任。

（2）需求

需求（Requirement）工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。

（3）分析和设计

分析和设计（Analysis & Design）工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），而描述则体现了类的对象如何协同工作实现用况的功能。设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。

（4）实现

35

实现（Implementation）工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式（源文件、二进制文件、可执行文件）实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

（5）测试

测试（Test）工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现，识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。

（6）部署

部署（Deployment）工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

（7）配置和变更管理

配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。

（8）项目管理

软件项目管理（Project Management）平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。

（9）环境

环境（Environment）工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。

36

图5-3 RUP核心概念

1. 需求获取

RUP运用用况（Use Case）技术来获取需求。 （1） 列出候选的需求：特征列表 （2） 理解系统语境：领域模型或业务模型 （3） 捕获功能需求：用况模型

（4） 捕获非功能需求：补充需求或针对一些特定的用况 特征：是一个新的项（Item）及其简要描述。 领域模型：类图

(1) 业务对象 (2) 实在对象 (3) 事件

业务对象模型：交互图、活动图

（1） 工作人员 （2） 业务实体 （3） 工作单元

创建系统用况模型的活动和任务：

（1） 发现并描述参与者 （2） 发现并描述用况

37

（3） 确定用况的优先级 （4） 精化用况 （5） 构造用户界面原型 （6） 用况模型的结构化 2. 需求分析

在系统用况模型的基础上，创建系统分析模型以及在该分析模型视角下的体系结构描述。

分析类：是类的一种衍型，很少有操作和特征标记，而用责任来定义其行为，并且其属性和关系也是概念性的。

存在三种不同类型的类：实体类、边界类和控制类。 （1）实体类

实体类描述要保存到持久存储体中的信息。如：数据库、各种形式的数据文件中的信息。包括： 活动者类。活动者类代表出现在用况模型中的活动者。活动者是现实世界中与系统交互的人和/或机构。例如，订单处理系统中客户是一个活动者类。

业务类描述业务的地点、物品、概念和事件。例如订单处理系统中的订单、商品等都是业务类。 （2）边界类

也称界面类（UI类），是组成系统用户界面的屏幕显示、菜单和报表。例如，订单处理系统中客户登录系统的界面、显示和编辑订单的屏幕等都属于UI类。

边界类位于系统与外界的交界处。如：窗体类、报表类、描述通信协议的类、直接与外设交互的类、直接与外部系统交互的类。

（3）控制类

控制类是主要负责其它类工作的类。如：主程序类、主窗体类。

38

分析包:

分析包体现了“局部化”、“问题分离”等软件设计原理。

分析包把一些变化限制到一个业务过程、一个参与者的行为或一组紧密相关的用况，形成一些不同的分析包。

服务包和共享包。 用况细化：

（2）分析模型的表达 （3）分析的主要活动 活动1：体系结构分析 活动2：用况分析 3. 设计层

定义满足需求规约所需要的软件结构。

RUP的设计目标：定义满足系统/产品分析模型所规约需求的软件结构。 4个术语： （1） 设计类 （2） 用况细化 （3） 设计子系统 （4） 接口 两个角度： （1） 系统设计模型

39

（2） 表达物理分布的系统部署模型 4. 设计层的术语

（1） 设计类：是对系统实现中一个类或类似构造的一个无缝抽象。

了解设计类的主要特征：操作、属性、关系、方法、实现需求、是否为主动类。

（2） 用况细化：描述一个特定用况是如何予以细化的。 （3） 设计子系统 （4） 接口

5. 设计模型、部署模型、体系结构描述

（1） 设计模型 （2） 部署模型 （3） 体系结构描述 6. 设计的主要活动 活动1：体系结构设计

（1） 标识节点和它们的网络配置 （2） 标识子系统和它们的接口

（3） 标识在体系结构方面有意义的设计类和它们的接口 （4） 标识一般性的设计机制 活动2：用况的设计

（1） 标识参与用况细化的设计类 （2） 标识参与用况细化的子系统和接口 活动3：类的设计

（1） 概括描述设计类 （2） 标识操作 （3） 标识属性 （4） 标识关联和聚合 （5） 标识泛化 （6） 描述方法 （7） 描述状态 活动4：子系统设计

（1） 维护子系统依赖 （2） 维护子系统所提供的接口 （3） 维护子系统内容

40

7. RUP的实现

RUP实现的目标：

（1）基于设计类和子系统生成构件 （2）对构成进行单元测试 （3）进行集成和连接

（4）把可执行的构件映射到部署模型 RUP实现的主要活动： （1） 实现体系结构 （2） 集成系统 （3） 实现子系统 （4） 实现类 （5） 完成单元测试 8. RUP的测试

包括：内部测试、中间测试和最终测试。 RUP测试包括的主要活动： （1） 计划测试 （2） 设计测试 （3） 实现测试 （4） 执行集成测试 （5） 执行系统测试 （6） 评价测试

第六章 软件测试

复习建议

错误是不可避免的，我们要做的就是发现它，并改正它。

软件测试是保证软件过程质量和软件产品质量的基础。因此软件测试也是本课程的重点内容，题目类型涉及单项选择题、填空题、简答题、综合应用题全部题型，分值在25%左右。

本章既有基本概念，也有综合应用，要求考生多做练习。

第一节 软件测试目标与软件测试过程模型

41

1. 软件测试的对象

软件=程序+文档

测试对象：各个阶段产生的源程序和文档。 2. 软件测试的目的

基于不同的立场，对软件测试的目的存在着两种完全对立的观点。

（1） 一种观点是通过测试暴露出软件中所包含的故障和缺陷(从用户的角度)；

（2） 另一种是希望测试成为表明软件产品中不存在错误的过程，验证该软件中已正确地实现了用户的要求，因此，它们倾向于选取导致程序失败概率最小的测试实例和数据。

显然，第二种观点对完善和提高软件质量和可靠性毫无价值，因此测试的目的应该是通过软件测试尽可能多地发现并改正软件种存在的错误。 3. 软件测试的定义

Glenford J. Myers把这一观点归纳为：

⑴测试是程序执行的过程，其目的在于发现错误。 ⑵一个好的测试实例在于发现至今未发现的错误。 ⑶一个成功的测试是发现了至今未发现的错误的测试。

因此,软件测试(Software Testing)是从引起和发现错误的目的出发执行某一程序的过程。 4. 错误的类型

（1） 功能错误：处理功能说明不完整或不确切，致使编程时对功能有误解而产生的错误。 （2） 系统错误：与外部接口错误、子程序调用错误、参数使用错误等。 （3） 过程错误：算术运算错误和逻辑运算错误 （4） 数据错误：数据结构、实体、属性错误。

（5） 编程错误：语法错误、程序逻辑错误、编程书写错误等。 5. 软件测试过程模型 （1）测试设计 （2）测试执行 （3）测试结果比较

第二节 软件测试技术

42

测试法分为黑盒法和白盒法。 1.

黑盒（Black-box Testing）法：黑盒法又称为功能测试法，它是根据程序功能的分析，推演出由函数

定义域中有代表性的元素组成测试集，这些数据应包括对程序是有效的和无效的输入，极端的、正常的和特殊的数据元素。因此，黑盒测试法是从外界来检查模块或程序的功能，也即根据模块的输入和输出，得出所得结果得差异。这种测试无须知道模块的内部逻辑，而是给定一输入，检查是否会得到所期望的输出。功能测试法又具体分为等价类法，边值分析法，因果图法和错误猜测法等。

2.

白盒法（White-box Testing）：白盒法也称之为结构测试或逻辑覆盖法。它是根据对软件内部逻辑结

构的分析，选取测试数据集（即测试用例：Testing Case），而测试数据集对程序逻辑的覆盖程度决定了测试完全性的程度。常用的几个覆盖标准有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖。 【例题?填空题】黑盒法又称为＿＿＿＿＿＿＿法，黑盒测试法是从外界来检查模块或程序的功能，也即根据模块的输入和输出，得出所得结果得差异。

【答案】功能测试

3. 路径测试技术（白盒测试） ★

依据的是程序的逻辑结构。 （1） 控制流程图

基本元素：过程块、节点、判定。 链、路径的概念。

注意：控制流程图和程序流程图的差别。 （2） 测试策略

a) 路径覆盖：执行所有可能穿过程序控制流程的路径。 最强的测试度量。 b) 语句覆盖：至少执行程序中所有语句一次。最低的测试度量。 c) 分支覆盖：至少将程序中的每个分支执行一次。 d) 条件覆盖与条件组合覆盖

语句覆盖≤分支覆盖≤条件组合覆盖≤路径覆盖

43

（3） 路径选取与用例设计

最小的强制性测试需求是语句覆盖率。

【例题】根据下列程序流程图，设计不超过2组的测试用例，使之满足语句覆盖，要求给出每组测试数据的执行路径、输入值、输出值及两个判定（3）和（5）的判定结果。

【解析】此类题目属于综合应用题（每题10分），考核知识点为路径测试技术。 在本题中，要求设计测试用例，满足语句覆盖，即所有语句都必须执行一遍。 A、B、C的值决定了程序执行的顺序 A、B、C的值 执行顺序 结果 3,6,10 1,2,3,4,5,7,8 7 25,1,10 1,2,3,5,6,7,8 11 4.

路径选取的一般原则

（1） 选择最简单的、具有一定功能含义的入口/出口路径

（2） 在已选取的基础上，选择无循环的路径，选取短路径、简单路径 （3） 选取没有明显功能含义的路径，要研究该路径为什么存在 5. 基于事务流的测试技术

（1） 事务与事务流程图 事务的含义

44

事务流

（2） 事务流测试的步骤

a) 获得事务流程图 b) 浏览、复审 c) 用例设计 d) 测试执行

6.

等价类法

是根据程序的I/O特性，将程序的输入划分为有限个等价区段，使得从每个区段内抽取的代表性数据进行的测试等价于该区段内任何数据的测试。对于每个输入条件存在着程序有效输入的有效等价类和对程序错误输入的无效等价类。例如，某实数X的取值范围假设为a＜X＜b，则所有[a+1，b-1]之间的实数构成了有效等价类，而任何[-∞，a]或[b，+∞]之间的实数构成了两个无效等价类。 7.

边值分析法

是一种根据I/O边界等价类上或紧靠边界的条件，选择测试用例的更有效的方法。例如，给定三个点，判定能否构成三角形，可选取两边之和等于第三边的实例作为边值分析法的测试用例。

【例题】有一个学生选课系统：程序的输入条件为：每个学生可以选修1至3门课程，试用黑盒测试法完成测试。

(1)按等价类划分法，设计测试用例(要求列出设计过程)； (2)按边界值分析法，设计测试用例。 【解析】 （1）等价类法：

课程门数<1 课程门数>3 课程门数1~3 （2）边界值分析法

课程门数=1 课程门数=3 8.

因果图法

是通过从用自然语言书写的功能说明表中找出因—输入条件和果—输出结果，通过因果图将功能说明转换成一张判定表，然后为每种输出条件的组合设计测试用例。

错误推测法是根据测试人员的经验和直觉推测程序种可能存在的各种错误。

45

本文来源：https://www.bwwdw.com/article/v7e2.html