软件工程主要内容

第一章 软件工程学概述

1． 软件危机

（1） 软件危机的介绍

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

2）软件危机的两个主要问题：如何开发软件，以满足对软件日益增长的需求；

如何维护数量不断膨胀的已有软件。

3）软件危机的典型表现：

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

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

(3) 软件产品的质量往往靠不住。

(4) 软件常常是不可维护的。

(5) 软件通常没有适当的文档资料。

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

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

势。

（2） 产生软件危机的原因

软件本身特点：

1） 缺乏可见性，在运行之前往往难以衡量，质量也难以评价

2） 不会因为长期使用而用坏，软件维护通常意味着修正或修改原来的设计，较

难维护。

3） 规模庞大，需分工合作，如何保证每个人的工作合在一起是极端复杂的问题。

软件开发与维护的方法不正确

产生软件危机的原因可归结为两个重要的方面：软件生产本身存在的复杂性；

软件开发所使用的方法和技术。

软件生命周期：一个软件从定义、开发、使用和维护直到最早被废弃。

软件产品必须由一个完整的配置组成（程序、文档、数据）

（3） 消除软件危机的途径

1） 正确认识计算机软件

2） 认识到软件开发是一个协同配合、共同完成的工程项目并吸取经验。

3） 推广使用已总结的开发软件成功的技术和方法

4） 开发使用更好的软件工具

2． 软件工程

（1） 软件工程的介绍

软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原

理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和

当前能够得到的最好的技术方法结合起来，以经济地、高效的开发出高质量的

软件并有效地维护它，这就是软件工程。

本质特性：

1） 软件工程关注于大型程序的构造

2） 软件工程的中心课题是控制复杂性

3） 软件经常变化

4） 开发软件的效率非常重要

5） 和谐地合作是开发软件的关键

6） 软件必须有效地支持它的用户

7） 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的

人创造产品。

（2） 软件工程的基本原理

1） 用分阶段的生命周期计划严格管理

2） 坚持进行阶段评审

3） 实行严格的产品控制

4） 采用现代程序设计技术

5） 结果应能清楚地审查

6） 开发小组的人员应该少而精

7） 承认不断改进软件工程实践的必要性

（3） 软件工程方法学

在软件生命周期全过程中使用的一整套技术方法的集合称为方法学。

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

1） 传统方法学

2） 面向对象方法学

3． 软件生命周期：定义、开发、维护

（1） 问题定义

（2） 可行性研究

（3） 需求分析

（4） 总体设计

（5） 详细设计

（6） 编码和单元测试

（7） 综合测试

（8） 软件维护

4． 软件过程：为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任

务的工作步骤。通常使用生命周期模型简洁的描述软件过程。

（1） 瀑布模型

1)各个阶段的顺序性和依赖性；

2)划分逻辑设计与物理设计，尽可能推迟程序的物理实现；

3)每个阶段必须完成规定的文档，对其中问题通过复审及早发现，及早解决。

（2） 快速还原模型

（3） 增量模型

(1) 从部分需求出发，先建立一个不完全的系统，通过测试运行该系统取

得经验和信息反馈，加深对软件需求的理解，进一步使系统扩充和完善。如此反复，直至软件人员和用户对所设计完成的软件系统满意为止。

(2) 在渐增型开发下的软件是随软件开发的过程而逐渐形成的。

(3) 渐增型开发方法适合于知识型软件的开发，设计系统时对用户需求的认识开始不是很清楚的，需要在开发过程中不断认识、不断获得新的知识去丰富和完善系统。多数研究性质的试验软件，一般采用此方法。

（4） 螺旋模型

（5）

（6）

（7）

（8） 喷泉模型 Rational统一过程 敏捷过程与极限编程 微软过程

第二章 可行性研究

可行性研究的目的，就是用最小的代价在尽可能短的时间内确定问题是否能够解决。

问题定义的任务：将用户提出的要求具体化、定量化；确定研制系统的范围，明确研制的边界。

问题定义阶段的工作：

1) 通过调查研究，了解系统需求；

2) 确定系统的功能需求、性能需求、可靠性需求、安全及保密性、资源、开发费用及开发进度等的需求；

3) 问题定义阶段的产品--系统目标与范围说明书。

1. 可行性研究的任务

（1） 技术可行性

（2） 经济可行性

（3） 操作可行性

2. 可行性研究的过程

（1） 复查系统规模和目标

（2） 研究目前正在使用的系统

（3） 导出新系统的高层逻辑模型

（4） 进一步定义问题

（5） 导出和评价供选择的解法

（6） 推荐行动方针

（7） 草拟开发计划

（8） 书写文档提交审查

3. 系统流程图

系统流程图是描述物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘系统里的每个部件（程序、文件、数据库、表格、人工过程等）。系统流程图表达的是部件的信息流程，而不表示对信息进行加工处理的控制过程。

4. 数据流图

DFD是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。 与程序流程图不同，DFD不表示程序的控制结构，只描述数据的流动

DFD分成多层(子图、父图概念)表示, 从而逐步展开数据流和功能的细节。

绘制数据流图步骤

（1）确定所开发的系统的外部项（外部实体），即系统的数据来源和去处。

（2）确定整个系统的输出数据流和输入数据流，把系统作为一个加工环节，画出关联图。

（3）确定系统的主要信息处理功能，按此将整个系统分解成几个加工环节（子系统）确定每个加工的输出与输入数据流以及与这些加工有关的数据存储。

（4） 根据自顶向下，逐层分解的原则，对上层图中全部或部分加工环节进行分解。

（5） 重复步骤（4），直到逐层分解结束。

（6） 对图进行检查和合理布局，主要检查分解是否恰当、彻底，DFD中各层是否有

遗漏、重复、冲突之处，各层DFD及同层DFD之间关系是否争取及命名、编号

是否确切、合理等，对错误与不当之处进行修改。

（7） 和用户进行交流，在用户完全理解数据图的内容的基础上征求用户的意见。

注意事项：

（1） 不要把控制流作为数据流

（2） 不要标出激发条件

（3） 数据流必须要么从某个加工流出、要么流入某个加工，而不能直接从外部项流

向数据存储等等。

5. 数据字典（对数据的定义）

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

（1） 数据字典的内容

数据流、数据流分量（数据元素）、数据存储、处理

数据字典要对数据流图中出现的所有名字（数据流，加工，文件）进行定义。

数据字典的条目由三大类组成，分别是：数据流条目、数据项条目、文件条目、

加工条目（小说明）。

（2） 定义数据的方法

+ ：和，连接两个分量

= ：等价于

[ ]：或，用|隔开分量

{ }：重复花括号内的分量 0{字母或数字}7表示8位字符串

（）：可选，即可有可无

（3） 数据字典的用途

（4） 数据字典的实现

6. 成本/效益分析

（1） 成本估计

1） 代码行技术

2） 任务分解技术

3） 自动估计成本技术

（2） 成本/效益分析方法

1） 货币时间价值

F=P(1+i)n次方

2） 投资回收期

3） 纯收入

4） 投资回收率

第三章 需求分析

1.

1)需求分析目的：

可行性分析研究阶段已经粗略的描述了用户的需求，甚至还提出了一些可行的方案，但是，许多细节被忽略了，在最终目标系统中是不能忽略、遗漏任何一个微小细节的，所以，可行性研究不能代替需求分析。

需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标提出完整、准确、清晰、具体的要求。

通过需求分析，明确用户对目标软件系统在功能、性能、行为、设计约束等方面的期望，回答软件系统“必须做什么”。

开发人员准确的理解用户的要求，进行细致的调查分析，讲用户形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的需求规格说明的过程。

2)需求分析的方法：

需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成，它定义了表示系统逻辑视图和物理视图的方式，大多数的需求分析方法是由数据驱动的，也就是说，这些方法提供了一种表示数据域的机制，分析员根据这种表示，确定软件功能及其特性，最终建立一个待开发软件的抽象模型，即目标系统的逻辑模型。

2.需求分析的任务

问题识别、分析与综合导出软件逻辑模型、编写文档

它的基本任务是准确地回答“系统必须做什么？”这个问题。需求分析所要做的工作是深入描述软件的共能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。需求分析的任务不是确定系统如何完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。其实现步骤如下图所示：

(1) 确定对系统的综合要求

系统功能需求

系统性能需求

可靠性和可用性需求、

错处理需求

接口需求、

约束

逆向需求

将来可能提出的需求

(2) 分析系统的数据需求

就是在理解当前系统“怎样做”的基础上，抽取其“做什么”的本质，明确目标系统要“做什么”，可以导出系统的详细的逻辑模型。具体做法：首先确定目标系统与当前系统的逻辑差别；然后将变化部分看作是新的处理步骤，对功能图（一般为数据流图）及对象图进行调整；最后有外及里对变化的部分进行分析，推断其结构，获得目标系统的逻辑模型。通常用数据流图、数字字典和主要的处理算法描述这个逻辑模型。

分析系统的数据要求通常采用建立数据模型的方法，常常利用图形工具辅助描绘数据结构。

(3)导出系统的逻辑模型

(4)修正系统开发计划

3.与用户沟通获取需求的方法

(1)访谈

正式和非正式访谈、发调查表、情景分析

(2) 面向数据流自顶向下求精

结构化分析:使用数据流程图、数据字典、结构化英语、判定表和判定树等工具，来建立

一 种新的、称为结构化说明书的目标文档-需求规格说明书。

结构化分析法就是面向数据流自顶向下逐步求精进行需求分析的方法，把数据流和数据存储定义到元素级

(3)简易的应用规格说明技术

(4)快速建立软件原型

4．分析建模与规格说明

(1)分析建模

数据模型（ER图）、功能模型（数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能）、行为模型（状态图，指明了作为外部事件结果的系统行为）

(3) 软件需求规格说明书

为了消除用自然语言书写的软件需求规格说明书中可能存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题，用形式化方法描述用户对软件系统的需求。

5.实体—联系图（数据对象及数据对象之间的关系）

(1)数据对象

一系列不同性质或属性的事务

(4) 属性

数据对象的性质

(5) 联系

数据对象彼此之间相互连接的方式称为联系，也称为关系

6.数据规范化

为了减少数据冗余，避免出现插入或删除异常，简化修改数据的过程，通常需要把数据结

构规范化。

第一范式

第二范式

第三范式

7.状态转换图

通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图还指明了作为特定事件的结果系统将做哪些动作。

（1） 状态

（2） 事件

（3） 符号

8.其他图

（1）层次方框图:用树形结构的一系列多层次的矩形描绘数据的层次结构。

（2）wanrnier图

（3）IPO图：输入、处理、输出图的简称。

9. 软件需求的验证：

需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。

（1） 应该从下述4个方面进行验证：

1）一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。

2）完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。

3）现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。

4）有效性必须证明需求是正确有效的，确实能解决用户面对的问题。

（2） 验证软件需求的方法

（3） 用于需求分析的软件工具

RSL（需求陈述语言）

PSL/PSA（问题陈述语言/问题陈述分析程序）

第四章 形式化说明技术

用自然语言描述需求规格说明，是典型的非形式化方法。用数据流图或实体-联系图建立模型，是典型的半形式化方法。

所谓形式化方法，是描述系统性质的基于数学的技术，也就是说，如果一种方法有坚实的数学基础，那么它就是形式化的。

1. 概述

（1） 非形式化方法的缺点：用自然语言书写的系统规格说明书，可能存在矛盾、二

义性、含糊性、不完整性及抽象层次混乱等问题。

（2） 形式化方法的优点

（3） 应用形式化方法的准则

2. 有穷状态机

当前状态+事件+谓词→下个状态

3. Petri网

4. Z语言

形式化的规格说明可以用数学方法研究、验证(例如，一个正确的程序可以被证明满足其规格说明，两个规格说明可以被证明是等价的，规格说明中存在的某些形式的不完整性和不一致性可以被自动地检测出来)。此外，形式化的规格说明消除了二义性，而且它鼓励软件开发者在软件工程过程的早期阶段使用更严格的方法，从而可以减少差错。

当然，形式化方法也有缺点：大多数形式化的规格说明主要关注于系统的功能和数据，而问题的时序、控制和行为等方面的需求却更难于表示。此外，形式化方法比欠形式化方法更难学习，不仅在培训阶段要花大量的投资，而且对某些软件工程师来说，它代表了一种“文化冲击”。

第五章 总体设计

总体设计的基本目的就是回答“概括地说，系统应该如何实现?”这个问题，因此，总体设计又称为概要设计或初步设计。

总体设计过程两个主要阶段：

（1）系统设计阶段，确定系统的具体实现方案

（2）结构设计阶段，确定软件结构

1. 设计过程

（1）设想供选择的方案

（2）选取合理的方案

（3）推荐最佳方案

（4）功能分解（结构设计及由哪些模块组成和过程设计-确定每个模块的处理过程）

（5）设计软件结构（层次图或结构图）

（6）设计数据库

（7）制定测试计划

（8）书写文档：系统说明、用户手册、测试计划、详细的实现计划、数据库设计结果；

（9）审查和复审

2. 设计原理

（1） 模块化

就是把程序划分成独立命名且可独立访问的模块,每个模块完成一个子功能,把这些模块集成起来构成一个整体,可以完成指定的功能满足用户的需求. 把复杂的问题分解成许多容易解决的小问题,原来的问题也就容易解决了.

模块化和软件成本关系:根据总成本曲线,每个程序都相应地有一个最适当的模块数目M,,使得系统的开发成本最小.

（2） 抽象

抽出事务的本质特性而暂时不考虑它们的细节.

（3） 逐步求精

（4） 信息隐藏和局部化

模块中所包括的信息不允许其它不需这些信息的模块调用

信息局部化：是把一些关系密切的软件元素物理地放得彼此靠近

（5） 模块独立

是软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中的 其它的模块接口是简单的。模块独立的概念是模块化、抽象、信息隐蔽和局部化概念的直接结果。

1) 耦合

也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模

块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低

取决于模块间接口的复杂性、调用的方式及传递的信息。

（a） 数据耦合：如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅

是数据。

（b） 控制耦合：模块传递的信息中有控制信息，就称作控制耦合。

（c） 特征耦合：把整个数据结构作为参数传递而被调用的模块只需要使用其中

一部分数据元素。

（d） 公共耦合：一组模块通过同一个公共数据环境相互作用，则它们之间的耦

合称为公共耦合。

（e） 内容耦合：如果发生下列情形之一，两个模块之间就发生了内容耦合。

一个模块直接访问另一个模块的内部数据

一个模块不能通过正常入口转到另一模块的内部

两个模块有一部分程序代码重叠（只可能出现在汇编语言中）

一个模块有多个入口

2) 内聚

又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的

紧密程度的度量。若一个模块内各元素(语句之间、程序段之间)联系得越紧密，

则它的内聚性就越高。

（a） 偶然内聚：如果一个模块各部分之间没有关系，或者即使有关系，这种关

系也是很松散的，则称作偶然内聚。（低内聚）

（b） 时间内聚：如果一个模块所包含的任务必须在同一时间内执行，称作时间

内聚。（低内聚）

（c） 逻辑内聚：一个模块完成的任务在逻辑上属于相同或相似的一类（低内聚）

（d） 过程内聚：如果一个模块内的处理是相关的，而且必须以特定次序执行，

则称为过程内聚。（中内聚）

（e） 通信内聚：如果一个模块中的所有元素都使用了相同的输入数据，或产生

了相同的输出数据，则称为通信内聚。（中内聚）

（f） 顺序内聚：如果一个模块内的处理元素和同一个功能密切相关，而且这些

处理必须顺序执行（通常一个处理元素的输出数据作为下一个处理元素

的输入数据），则称为顺序内聚。（高内聚）

（g） 功能内聚：如果一个模块内所有处理元素属于一个整体，完成一个单一的

功能，则称作功能内聚。（高内聚）

耦合性与内聚性是模块独立性的两个定性标准，将软件系统划分模块时，尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。

模块的高内聚、低耦合的原则称为模块独立原则，也称为模块设计的原则。

3. 启发规则

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

（2）模块规模应该适中

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

深度表示软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。

宽度是软件结构内同一个层次上的模块总数的最大值；一般来说，宽度越大系统越复杂。

宽度影响最大的因素是模块的扇出。

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

一个模块的扇出是指该模块直接调用的下级模块的个数。

设计原则：低扇出、高扇入。

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

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

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

合。

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

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

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

4. 描绘软件结构的图形工具

（1） 层次图和HIPO(层次图加输入/处理/输出图)

层次图是用来描述软件的层次结构的。

层次图

HIPO图

（2） 结构图

结构图和层次图类似，都是描述软件结构的图形工具

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

面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法。面向数据流的设计要解决的任务，就是上述需求分析的基础上，将DFD图映射为软件系统的结构。

（1） 概念

变换流

事务流

数据流图的类型：交换型结构和事务型结构

交换型结构：由3部分组成，传入路径，变换中心，输出路径。系统的传入流经过变换中心的处理，变换为系统的传出流。

事务型结构：有至少一条接受路径，一个事务中心与若干条动作路径组成。当外部信息沿着接受路径进入系统后，经过事务中心获得某个特定值，就能据此启动某一条动作路径的操作。

（2） 变换分析

变换分析是一系列设计步骤的总称，经过这些步骤把具有变换流特点的数据流

图按预先确定的模式映射成软件结构。

（3） 事务分析

（4） 设计优化

第六章 详细设计

详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。

1． 结构程序设计

2． 人机界面设计

（1） 设计问题

系统响应时间

用户帮助设施

出错信息处理

命令交互

（2） 设计过程

（3） 人机界面设计指南

一般交互指南

信息显示指南

数据输入指南

3． 过程设计的工具

（1） 程序流程图

（2） 盒图（N-S图）

（3） PAD（问题分析图）图

（4） 判定表

（5） 判定树

（6） 过程设计语言（PDL）

它是正文形式表示数据和处理过程的设计工具

4． 面向数据结构的设计方法

（1）Jackson图

（2）改进的Jackson图

（3）Jackson方法

Jackson方法是最著名的面向数据结构的设计方法,而不是面向数据流的设计方法。它是以信息驱动的，是将信息转换成软件的程序结构

Jackson方法的基本步骤是：

1）分析并确定输入数据和输出数据的逻辑结果，并用Jackson图描绘这些数据结构.

2）找出输入数据结构和输出数据结构中有对应关系的数据单元。

3）从描绘数据结构的Jackson图导出描绘程序结构的Jackson图

4）列出所有操作和条件（包括分支条件和循环结束条件），并且把他们分配到程序结构图的适当位置

5）用伪代码表示程序

5． 程序复杂程度的定量度量

（1） McCabe方法

根据程序控制流的复杂程度定量度量程序的复杂程度，称为程序的环形复杂度。 程序的环形复杂度取决于程序控制流的复杂程度，即取决于程序结构的复杂难度。

（2） Halstead方法

根据程序中运算符和操作数的总数来度量程序的复杂程度。

第七章 实现

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

1. 编码

（1） 选择程序设计语言

（2） 编码风格

1） 程序内部文档：符号名的命名、程序的注释、标准的书写格式

2） 数据说明: 数据说明的次序应当规范化。使数据属性容易查找，也有利于测

试，排错和维护

3） 语句构造: 语句结构力求简单、直接，不能为了片面追求效率而使语句复杂

化，可以从以下几点注意：使用标准的控制结构、尽可能使用库函数、程序

编写首先应该考虑清晰性、注意使用goto语句

4） 输入输出: 输入/输出地方式和格式应当尽可能做到对用户友善，尽可能方

便用户的使用。

5） 效率：程序效率：程序效率是指程序的执行速度及程序占用的存储空间。影

响程序效率的因素是多方面的。

2. 软件测试基础

（1） 软件测试的目标：为了发现程序中的错误而执行程序的过程

（2） 软件测试的准则

1）所有测试都应该能够追溯到用户需求

2）应该远在测试开始之前就制定出测试计划

3）把Pareto原理应用到软件测试中

4）应该从“小规模”测试开始，并逐步进行“大规模”测试

5）穷举测试是不可能的。

6）为了达到最佳的测试效果，应该由独立的第三方从事测试工作。

（3） 测试方法

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

，黑盒测试是在程序接口进行的测试，它只检查程序功能能否按照规格说明

书的规定正常使用，程序能否适当地接收输入数据并产生正确的输出信息。

2）白盒测试：结构测试，把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。

（4） 测试步骤

1）单元测试(模块测试) ：保证每个模块正常运行，发现编码和详细设计的错误。

2）子系统测试：把经过单元测试的模块放在一起形成一个子系统测试。

3）系统测试：经过测试的子系统装配成一个完整的系统来测试。

4）验收测试（确认测试）：验证系统能否满足用户需要。

5）平行运行：运行新旧系统，相比较。

（5） 测试阶段的信息流

3. 单元测试

主要使用白盒测试技术，集中检测软件设计的最小单元模块。

（1） 测试重点

1） 模块接口

2） 局部数据结构

3） 重要执行通路

4） 出错处理通路

5） 边界条件

（2） 代码审查

（3） 计算机测试

驱动程序：接收测试数据，把这些数据传送给被测试的模块，并且印出有关结果。

存根程序：代替被测试的模块所调用的模块，也可称为虚拟子程序。

4. 集成测试

也称为组装测试，在单元测试的基础之上，把所有的模块组装成一个系统进行测试。主要测试设计阶段产生的错误，集成测试计划应该在概要设计阶段制定。

（A）非渐增式测试方法：先分别测试每个模块，再把所有模块按设计要求放在一起结合所要的程序。

（B）渐增式测试：把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

比较：

㈠非渐增式测试方法把单元测试和集成测试分成两个不同的阶段，前一阶段完成模块的单元测试，后一阶段完成集成测试。而渐增式测试往往把单元测试与集成测试和在一起，同时完成。

㈡非渐增式需要更多的工作量，因为每个模块都需要驱动模块和桩模块，而渐增式利用已测试过的模块作为驱动模块或桩模块，因此工作量较少。

㈢渐增式可以较早的发现接口之间的错误，非渐增式最后组装是才发现。

㈣渐增式有利于排错，发生错误往往和最近加进来的模块有关，而非渐增式发现接口错误推迟到最后，很难判断是哪一部分接口出错。

㈤渐增式比较彻底，已测试的模块和新的模块再测试。

㈥渐增式占用的时间较多，但非渐增式须更多的驱动模块、桩模块也占用一些时间。 ㈦非渐增式开始可并行测试所有模块，能充分利用人力，对测试大型软件很有意义。

（1） 自顶向下集成:从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个

模块结合起来。

（2） 自底向上集成：从原子模块即在软件结构最底层的模块开始组装和测试。

（3） 不同集成测试策略的比较

① 自顶向下测试方法的主要优点是不需要测试驱动程序，能够在测试阶段的早期

实现并验证系统的主要功能，而且能在早期发现上层模块的接口错误。

② 自顶向下的测试方法主要缺点是需要存根程序，可能遇到与此相联系的测试困

难，低层关键模块中的错误发现较晚，而且用这种方法在早期不能充分展开人力。

混合策略：改进的自顶向下测试方法、混合法

（4）回归测试：集成测试中当每一个新模块结合进来时，程序就发生了变化，所谓回归

测试是指重新执行已经做过的测试的某个子集。

5. 确认测试：也称为验收测试，目标是严重软件的有效性

验证：保证软件正确实现了某个特定要求的一系列活动

确认：为了保证软件确实满足了用户需求

有效性：如果软件的功能和性能如图用户所合理期待的那样，软件就是有效的

（1） 确认测试的范围

（2） 软件配置复查

（3） Alpha测试：用户在开发者场所进行，并在开发者对用户指导下进行测试。

Beta测试：软件的最终用户们在一个或多个客户场所进行。

6. 白盒测试技术

白盒测试时将程序看作是一个透明的盒子，也就是说测试人员完全了解程序的内部结构和处理过程。所以测试时按照程序内部的逻辑测试程序、检验程序中的每条通路是否都能按预定的要求正确工作。白盒测试又称为结构测试。

白盒测试多用于单元测试阶段。逻辑覆盖是主要的白盒测试技术。白盒测试时，确定测试数据应根据程序的内部逻辑和指定的覆盖方式。

（1） 逻辑覆盖

1） 语句覆盖：使被测程序中每个语句至少执行一次

2） 判断覆盖：不仅每个语句至少执行一次，每个判定的每种可能结果应该至少

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

3） 条件覆盖：不仅每个语句至少执行一次，而且使判定表达式中的每个条件都

取到各种可能结果。

4） 判断/条件覆盖：使判定表达式中的每个条件都取到各种可能的值，而且每

个判定表达式都能取到各种可能的结果

5） 条件组合覆盖：使每个判定表达式中条件的各种可能组合都至少出现一次

6） 点覆盖

7） 边覆盖

8） 路径覆盖

（2） 控制结构测试

1) 基本路径测试

2) 条件测试

3) 循环测试

7. 黑盒测试技术

黑盒测试时完全不考虑程序内部的结构和处理过程，只按照规格说明书的规定来检查程序是否符合它的功能要求。黑盒测试是在程序接口进行的测试，又称为功能测试。

（1） 等价划分

把程序的输入域划分成若干个数据类，据此导出测试用例。

使用等价划分法设计测试方案首先需要划分输入数据的等价类，为此需要研究程序的功能说明，从而确定输入数据的有效等价类和无效等价类。

（2） 边界值分析

（3） 错误推测

8. 调试

（1） 调试过程

（2） 调试途径

1） 蛮干法

2） 回溯法

3） 原因排除法

9. 软件可靠性

（1） 基本概念

1） 软件可靠性定义：程序在给定的时间间隔内，按照规格说明书的规定成功的

运行的概率

2） 软件可用性：程序在给定的时间点，按照规格说明书的规定成功的运行的概

率。

（2） 估算平均无故障时间的方法

1） 符号

2） 基本假定

3） 估算平均无故障时间

4） 估计错误总数的方法

第八章 维护

1. 软件维护的定义

软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程

（1）改正性维护：纠正开发期间未发现的遗留错误，即在程序使用期间发现的程序错误进行诊断和改正的过程。

（2）完善性维护：满足用户在使用过程中提出增加新的功能或修改已有功能，以满足用户日益增长的需要而进行的工作； 该维护活动通常占软件维护工作的大部分；

（3）预防性维护：为了改善未来的可维护性或可靠性而修改软件的工作。 用于维护工作的劳动可以分成生产性活动（如：分析评价，修改设计和编写程序代码）和非生产性活动（如：理解程序代码的功能，解释数据结构、接口特点和性能限度）。

（4）适应性维护：是为了和变化的环境适当地配置而进行的修改软件的活动，是既必要又经常的维护活动。是软件适应新的运行环境而进行的工作；

2. 软件维护的特点

（1） 结构化维护与非结构化维护差别巨大

1） 非结构化维护（软件配置唯一成分是程序代码

2） 结构化维护（完整的软件配置存在）

（2） 维护的代价高昂

（3） 维护的问题很多

3. 软件维护过程

（1） 维护组织

（2） 维护报告

（3） 维护的事件流

（4） 保存维护记录

（5） 评价维护活动

4. 软件的可维护性

维护人员理解、改正、改动或改进这个软件的难易程度。

（1） 决定软件可维护性的因素

1） 可理解性

2） 可测试性

3） 可修改性

4） 可移植性

5） 可重用性

（2） 文档

1） 用户文档

2） 系统文档

（3） 可维护性复审

5. 预防性维护

6. 软件再工程过程

（1） 库存目录分析

（2） 文档重构

（3） 逆向工程:分析程序以便在比源代码更高的抽象层次上创建出程序的某种表示

的过程，也就是说，逆向工程是一个恢复设计结果的过程，逆向工程工具从现

存的代码中抽取有关数据、体系结构和处理过程的设计信息。

（4） 代码重构

（5） 数据重构

（6） 正向工程：革新或改造，不仅从现有程序中恢复设计信息，而且使用该信息去

改变或重构现有系统，以提高其整体质量。

软件的可理解性、可测试性、可修改性、可移植性和可重用性是决定软件可维护性的基本因素。

第九章 面向对象方法学引论

1. 面向对象方法学概述

（1） 面向对象方法学的要点

面向对象方法学的出发点和基本原则，是尽可能模拟人类习惯的思维方式，使开

发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，也就是使

描述问题的问题空间与实现解法的解空间在结构上尽可能一致。

OO=objects+classes+inheritance+communication with messages

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

息实现彼此通信。

（2） 面向对象方法学的优点

1） 与人类习惯的思维方法一致

2） 稳定性好

3） 可重用性好

4） 较易开发大型软件产品

5） 可维护性好

1）、面向对象的软件稳定性比较好

2）、面向对象的软件比较容易修改

3）、面向对象的软件比较容易理解

4）、易于测试和调试

2. 面向对象的概念

（1） 对象

对象：它是封装了数据结构及可以施加在这些数据结构上的操作的封装体，这个

封装体有可以唯一地标识它的名字，而且向外界提供一组服务（即公有的操作）。 对象的特点：以数据为中心；对象是主动的；实现了数据封装；本质上具有并行

性；模块独立性好

（2） 其他概念

1） 类：对具有相同数据和相同操作的一组相似对象的定义，也就是说，类是对

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

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

3） 消息: 消息传递时对象与外界相互关系的唯一途径。对象可以向其它对象发

送消息以请求服务，也可以响应其他对象传来的消息，完成自身固有的某些

操作，从而服务于其他对象。

消息就是要求某个对象执行在定义它的那个类中所定义的某个操作的规格

说明。

一个消息有3部分组成： 接收消息的对象；消息选择符（也称消息名）；

零个或多个变元。

4） 方法: 方法就是对象所能执行的操作，也就是类中所定义的服务。方法描述

了对象执行操作的算法，响应消息的方法。

5） 属性: 属性就是类中定义的数据，它是对客观世界实体所具有的性质的抽

象。

6） 封装: 封装也就是信息隐藏，通过封装对外界隐藏了对象的实现细节。

7） 继承: 是现实世界中遗传关系的直接模拟。可用来表示类之间的内在联系以

及对属性和操作的共享。子类可以沿用父类的某些特征，同时子类也可以具

有自己独立的属性和特征。

8） 多态性：子类对象可以像父类对象那样使用，同样的消息既可以发送给父类

对象也可以发送给子类对象。

9） 重载：函数重载是指在同一作用域内的若干个参数特征不同的函数可以使用

相同的函数名字。运算符重载是指同一个运算符可以施加于不同类型的操作

数上面。

3. 面向对象建模

模型，就是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。 描述系统数据结构的对象模型、描述系统控制结构的动态模型、描述系统功能的功能模型。通常，模型由一组图形符号和组织这些符号的规则组成，利用它们来定义和描述问题域中的术语和概念。更进一步地讲，模型是一种思维工具，利用这种工具可以把知识规范地表示出来。

4. 对象模型

对象模型表示静态的、结构化的系统的“数据”性质，描述数据结构。它是对模拟客观世界实体的对象以及对象彼此间的关系的映射，描述了系统的静态结构。

通常，使用UML提供的类图来建立对象模型。在UML中术语“类”的实际含义是，“一个类及属于该类的对象”。

（1） 类图的基本符号

1） 定义类

UML中类的图形符号为长方形，用两条横线把长方形分成上、中、下3个

区域（下面两个区域可省略），3个区域分别放类的名字、属性和服务，如

图所示。

2） 定义属性

UML描述属性的语法格式如下：可见性 属性名：类型名=初值{性质串}

3） 定义服务

服务也就是操作，UML描述操作的语法格式如下：

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

（2） 表示关系的符号

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

（a） 普通关联：只要类与类之间存在连接关系。

（b） 关联的角色：在任何关联中都会涉及到参与此关联的对象所扮演的角

色（即起的作用），在某些情况下显式标明角色名有助于别人理解类

图。

（c） 限定关联：限定关联通常用在一对多或多对多的关联关系中，可以把

模型中的重数从一对多变成一对一，或从多对多简化成多对一。在

类图中把限定词放在关联关系末端的一个小方框内。

（d） 关联类：为了说明关联的性质，可能需要一些附加信息。可以引入一

个关联类来记录这些信息。关联类通过一条虚线与关联连接。

2） 聚集：聚集也称为聚合，是关联的特例。聚集表示类与类之间的关系是整体

与部分的关系。

（a） 共享聚集：如果在聚集关系中处于部分方的对象可同时参与多个处于

整体方对象的构成。

（b） 组合聚集：如果部分类完全属于整体类，部分与整体共存，整体不存

在了部分也会随之消失，则该聚集称为组合聚集。

3） 泛化：即继承关系，它是通用元素和具体元素之间的一种分类关系。用一端

为空心三角形的连线表示泛化关系。

（a） 普通泛化

（b） 受限泛化（附加约束条件）

4） 依赖和细化

（a） 依赖关系：依赖关系描述两个模型元素（类、用例等）之间的语义连

接关系： 其中一个模型元素是独立的，另一个模型元素不是独立的，

它依赖于独立的模型元素，如果独立的模型元素改变了，将影响依

赖于它的模型元素。

（b） 细化关系: 当对同一个事物在不同抽象层次上描述时，这些描述之间

具有细化关系。

5. 动态模型

6. 功能模型: 功能模型表示变化的系统的“功能”性质，它指明了系统应该“做什么”，

因此更直接地反映了用户对目标系统的需求。通常，功能模型由一组数据流图组成。

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

1） 系统

2） 用例：系统完成的一系列动作，动作的结果能被特定的行为者察觉到。

用例是一个类，它代表一类功能而不是使用该功能的某个具体实例。用

例的实例是系统的一种实际使用方法，通常把用例的实例称为脚本。脚

本是系统的一次具体执行过程。

3） 行为者：与系统交互的人或其他系统，代表外部实体。

4） 用例之间的关系

（a） 扩展关系：向一个用例中添加一些动作后构成了另一个用例，这两个

用例之间的关系就是扩展关系，后者继承前者的一些行为，通常把

后者称为扩展用例。

（b） 使用关系：当一个用例使用另一个用例时，这两个用例之间就构成了

使用关系。

（2） 用例建模

1） 寻找行为者

2） 寻找用例

7. 三种模型之间的关系

在面向对象方法学中，对象模型是最基本最重要的，它为其他两种模型奠定基础。

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

2）状态转换驱使行为发生，这些行为在数据流图中被映射成处理，在用例图中被映射成用例，它们同时与类图中的服务相对应。

3）功能模型中的处理（或用例）对应于对象模型中的类所提供的服务。通常，复杂的处理（或用例）对应于复杂对象提供的服务，简单的处理（或用例）对应于更基本的对象提供的服务。有时一个处理（或用例）对应多个服务，也有一个服务对应多个处理（或用例）。

4）数据流图中的数据存储，以及数据的源点/终点，通常是对象模型中的对象。

5）数据流图中的数据流，往往是对象模型中对象的属性值，也可能是整个对象。

6）用例中的行为者，可能是对象模型中的对象。

7）功能模型中的处理（或用例）可能产生动态模型中的事件。

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

总之，功能模型指明了系统应该”做什么”;动态模型明确规定了什么时候(即在何种状态下接受了什么事件的触发)做;对象模型则定义了做事情的实体.

第十章 面向对象的分析

开发软件，分析的过程都是系统需求提取的过程，它要求系统分析员通过与用户及相关领域的专家交流，充分理解用户的需求和相关领域的背景知识，最终把这种理解制作成文档资料的过程，但由于问题的复杂性，该理解过程并不能达到理想的成程度，因此需要进一步去验证说明规格文档的正确性、完整性、有效性。

1、分析工作主要内容: 理解、表达、验证（其中理解和验证的过程是反复进行的，有事还需要原型系统作为辅助工具）。

2、分析过程得出的结果就是软件需求规格说明文档，相对于面向对象，由对象模型、动态模型、功能模型组成。

面向对象分析的关键是识别出问题域内的类与对象，分析确定它们之间的关系，最

终建立起问题域的对象模型、动态模型和功能模型。

1. 面向对象分析的基本过程

（1） 概述

面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。

基本过程流程:

1）从分析陈述用户需求的文件开始（可由用户单方，也可由系统人员与用户 配合写出需求陈述）。

2）需求陈述通常是不完整、不准确的、还是非正式的。因此，需求陈述不是 一成不变， 应通过分析，补充和改正其内容。

3）系统人员深入分析理解用户的需求，抽象出系统的本质属性，并用模型准 确表示出来。

4）建模过程中，分析员应该认真向领域专家学习，还应仔细研究以前针对 相同的或类似问题域进行面向对象分析得出的结果。

（2） 3个子模型与5个层次

a) 对象模型（静态模型）：几乎解决任何一个问题，都需要从客观世界

实体及实体间相互关系抽象出极有价值的对象模型。

b) 动态模型（交互次序）：问题涉及交互作用和时序时最重要。

c) 功能模型（数据变换）：解决运算量很大的问题时很重要。

五个层次：主题层、类与对象层、结构层、属性层、服务层

与之对应的面向对象分析过程中建立的对象模型为：找出类与对象、识别结构、识别主题、定义属性、定义服务

综合以上知，面向对象分析可按下列顺序进行：找出类与对象、识别结构、识

别主题、定义属性、建议动态模型、建立功能模型、定义服务。

2. 需求陈述

（1） 书写要点: 需求陈述通常包括：问题范围，功能需求，性能需求，应用环境及

假设条件等。

（2） 应该阐明“做什么”，而不是“怎么做”

（3） 应该描述用户的需求，而不是提出解决问题的方法

（4） 应该指出哪些是系统必要的性质，哪些是任选的性质

（5） 应该避免对设计策略施加过多的约束，也不要描述系统的内部结构，否则将限制实现的灵活性

（6） 对系统性能及外界环境交互协议的描述是合适的需求

（7） 对采用的软件工程标准、模块构造准则、将来可能做的扩充以及可维

护性要求等方面描述，也都是适当的需求

（8） 系统分析员必须与用户及领域专家密切配合协同工作，共同提炼和整

理用户需求

（9） 例子

3. 建立对象模型

对象模型描述了现实世界中的“类与对象”以及它们之间的关系，表示了目标系统的静态数据结构。

静态数据结构对应用细节依赖较少，比较容易确定

当用户的需求变化时，静态数据结构相对来说比较稳定

（1） 确定类与对象

1） 找出候选的类与对象

对象是对问题域中有意义的事物的抽象，它们既可能是物理实体，也可能是抽象概念

2） 筛选出正确的类与对象

非正式分析仅仅帮助我们找到一些候选的类与对象，接下来应该严格考察每个候选对象，从中去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象

1) 冗余

2) 无关

3) 笼统

4) 属性

5) 操作

在需求陈述中有时可能使用一些既可作为名词，又可作为动词的词，应

该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是

作为类中定义的操作。

6) 实现

在分析阶段不应该过早地考虑怎样实现目标系统。因此，应该去掉仅和

实现有关的候选的对象/类。在设计和实现阶段，这些对象/类可能是重

要的，但在分析阶段过早地考虑它们反而会分散我们的注意力。

（2） 确定关联

1） 初步确定关联

直接提取动词短语得出的关联

需求陈述中隐含的关联

根据问题域知识得出的关联

2） 筛选

已删去的类之间的关联

与问题无关的或在实现阶段考虑的关联

瞬时事件

三元关联

派生关联

3） 进一步完善

正名

分解

补充

标明重数

（3） 划分主题

（4） 确定属性

1） 分析

2） 选择

（5） 识别继承关系

（6） 反复修改

4. 建立动态模型

（1） 编写脚本

（2） 设想用户界面

（3） 画事件跟踪图

（4） 画状态图

（5） 审查动态模型

各个类的状态图通过共享事件合并起来，构成了系统的动态模型。

5. 建立功能模型

功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能，它由一组数据流图组成。其中的处理功能可以用IPO图（或表）、伪码等多种方式进一步描述。

通常在建立了对象模型和动态模型之后再建立功能模型。

（1） 画出基本系统模型图

基本系统模型由若干个数据源点/终点，及一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。

（2） 画出功能级数据流图

把基本系统模型中的单一的处理框分解成若干个处理框，以描述系统加工、变换数据的基本功能，就得到功能级数据流图。

（3） 描述处理框功能

把数据流图分解细化到一定程度后，应该描述图中各个处理框的功能。注意，应该着重描述每个处理框所代表的功能，而不是实现功能的具体算法。

6. 定义服务

（1） 常规行为

（2） 从事件导出的操作

状态图中发往对象的事件也就是该对象接收到的消息，因此该对象必须提供由消息选择符指定的操作，这个操作修改对象状态(即属性值)并启动相应的服务。

（3） 与数据流图中处理框对应的操作

数据流图中每个处理框都与一个对象（也可能是若干个对象）上的操作相应。应该仔细对照状态图和数据流图，以便更正确地确定对象应该提供的服务。

（4） 利用继承减少冗余操作

应该尽量利用继承机制以减少所需定义的服务数目。

第十一章 面向对象设计

1． 面向对象设计的准则

（1） 模块化

（2） 抽象

（3） 信息隐藏

（4） 弱耦合

1） 交互耦合：对象之间的耦合通过消息来实现

2） 继承耦合：应该提高继承耦合。

（5） 强内聚：衡量一个模块内各个元素彼此结合的紧密程度

1） 服务内聚：一个服务应该完成一个且仅完成一个功能

2） 类内聚

3） 一般特殊内聚（与继承耦合一致）

（6） 可重用

2． 启发规则

（1） 设计结果应该清晰易懂

（2） 一般-特殊结构的深度适当（类等级中包含的层次数适当）

（3） 设计简单的类

（4） 使用简单的协议

（5） 使用简单的服务

（6） 把设计变动减至最小

3． 软件重用

（1） 概述

1） 重用：也叫再用或复用，是指同一事物不作修改或稍加改动就多次重复使用。

2） 软件成分的重用级别

代码重用、设计结果重用、分析结果重用

3） 典型的可重用软件成分

（2） 类构件：比较理想的可重用软构件

1） 可重用软构件应具备的特点

模块独立性强、具有高度可塑性、接口清晰、简明、可靠

2） 类构件的重用方式

实例重用、继承重用、多态重用

（3） 软件重用的效益

1） 质量

2） 生产率

3） 成本

4． 系统分解

典型的面向对象设计模型,逻辑上由4部分组成:人机交互部分,问题域部分,任务管理部分,数据管理部分.

（1） 子系统之间的两种交互方式

1） 客户-供应商关系

2） 平等伙伴关系

（2） 组织系统的两种方案

1） 层次组织（开放式和封闭式）

2） 块状组织

（3） 设计系统拓扑结构

5． 设计问题域子系统

在面向对象设计过程中,可能面向对象分析所得出的问题域模型做的补充或修改:

（1） 调整需求

（2） 重用已有的类

（3） 把问题域类组合在一起

（4） 增添一般化类以建立协议

（5） 调整继承层次

6． 设计人机交互子系统

（1） 分类用户

（2） 描述用户

（3） 设计命令层次

（4） 设计人机交互类

7． 设计任务管理子系统

（1） 分析并发性

（2） 设计任务管理子系统

8． 设计数据管理子系统

（1） 选择数据存储管理模式

1） 文件管理系统

2） 关系数据库管理系统

3） 面向对象数据库管理系统

（2） 设计数据管理子系统

1） 设计数据格式

2） 设计相应的服务

9． 设计类中的服务

（1） 确定类中应有的服务

（2） 设计实现服务的方法

1） 设计实现服务的算法

2） 选择数据结构

3） 定义内部类和内部操作

10. 设计关联

（1） 关联的遍历

（2） 实现单向关联

（3） 实现双向关联

（4） 关联对象的实现

11. 设计优化

（1） 确定优先级

（2） 提高效率的几项技术

1） 增加冗余关联以提高访问效率

2） 调整查询次序

3） 保留派生属性

（3） 调整继承关系

1） 抽象与具体

2） 为提高继承程度而修改类定义

3） 利用委托实现行为共享

第十二章 面向对象实现

面向对象实现包括：把面向对象设计结果翻译成用某种程序语言书写的面向对象程序；测试并调试面向对象的程序。

1. 程序设计语言

面向对象设计的结果既可以用面向对象语言、也可以用非面向对象语言实现。使用面向对象语言时，由于语言本身充分支持面向对象概念的实现，因此，编译程序可以自动把面向对象概念映射到目标程序中。使用非面向对象语言编写面向对象程序，则必须由程序员自己把面向对象概念映射到目标程序中。

（1） 面向对象语言的优点

从原理上说，使用任何一种通用语言都可以实现面向对象概念。当然，使用面

向对象语言，实现面向对象概念，远比使用非面向对象语言方便，但是，方便

性也并不是决定选择何种语言的关键因素。选择编程语言的关键因素，是语言

的一致的表达能力、可重用性及可维护性。从面向对象观点看来，能够更完整、更准确地表达问题域语义的面向对象语言的语法是非常重要的，因为这会带来

下述几个重要优点：

1） 一致的表示方法

2） 可重用性

3） 可维护性

（2） 面向对象语言的技术特点

1） 支持类与对象概念的机制

2） 实现整体-部分（即聚集）结构的机制

3） 实现一般-特殊（即泛化）结构的机制

4） 实现属性和服务的机制

5） 类型检查

6） 类库

7） 效率

8） 持久保存对象

9） 参数化类

10） 开发环境

（3） 选择面向对象语言（考虑因素）

1） 将来能否占主导地位

2） 可重用性

3） 类库和开发环境

4） 其他因素

2. 程序设计风格（良好风格准则）

（1） 提高可重用性

1） 提高方法的内聚

2） 减小方法的规模

3） 保持方法的一致性

4） 把策略与现实分开

5） 全面覆盖

6） 尽量不使用全局信息

7） 利用继承机制

（2） 提高可扩充性

1） 封装实现策略

2） 不要用一个方法遍历多条联链

3） 避免使用多分支语句

4） 精心确定公有方法

（3） 提高健壮性

1） 预防用户的操作错误

2） 检查参数的合法性

3） 不要预先确定限制条件

4） 先测试后优化

3. 测试策略

（1） 面向对象的单元测试

当考虑面向对象的软件时，单元的概念改变了。“封装”导致了类和对象的定义，这意味着类和类的实例（对象）包装了属性（数据）和处理这些数据的操作（也称为方法或服务）。现在，最小的可测试单元是封装起来的类和对象。一个类可以包含一组不同的操作，而一个特定的操作也可能存在于一组不同的类中。因此，对于面向对象的软件来说，单元测试的含义发生了很大变化。

在测试面向对象软件时，不再孤立地测试单个操作，而应该把操作为类的一部分来测试。

（2） 面向对象的集成测试

因为在面向对象的软件中不存在层次的控制结构，传统的自顶向下或自底向上的集成策略就没有意义了。此外，由于构成类的各个成分彼此间存在直接或间接的交互，一次集成一个操作到类中（传统的渐增式集成方法）通常是不现实的。

基于线程的测试和基于使用的测试两种

（3） 面向对象的确认测试：和传统的确认测试一样，面向对象的确认测试也集中检

查用户可见的动作和用户可识别的输出。对于面向对象的软件来说，主要还是根据动态模型和描述系统行为的脚本来设计确认测试用例。

在确认测试或系统测试层次，不再考虑类之间相互连接的细节。和传统的确认测试一样，面向对象软件的确认测试也集中检查用户可见的动作和用户可识别的输出。为了导出确认测试用例，测试人员应该认真研究动态模型和描述系统行为的脚本，以确定最可能发现用户交互需求错误的情景。

4. 设计测试用例

（1） 测试类的方法

1） 随机测试

2） 划分测试

1） 基于状态的划分

2） 基于属性的划分

3） 基于功能的划分

3） 基于故障的测试

（2） 集成测试方法

可采用基于线程或基于使用的策略完成集成测试，也可以采用随机测试和划分测试方法，从动态模型导出的测试用例，可以测试指定的类及其协作者。

测试类协作可以使用随机测试方法和划分测试方法，以及基于情景的测试和行为测试来完成。

1） 多类测试

2） 从动态模型导出测试用例

（3） 确认测试

可以采用传统的黑盒方法完成测试工作，基于情景的测试是面向对象系统确认测试的主要方法。

第十三章 软件项目管理

1. 估算软件规模

（1） 代码行技术

（2） 功能点技术

2. 工作量估算

软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模(KLOC或FP)的函数，工作量的单位通常是人月(pm)。

（1） 静态单变量模型

（2） 动态多变量模型

（3） COCOMO2模型（构造性成本模型）

3. 进度计划

（1） 估算开发时间

（2） Gantt图

（3） 工程网络

（4） 估算工程进度

（5） 关键路径

（6） 机动时间

4. 人员组织

（1） 民主制程序员组:小组成员完全平等,充分享有民主通过协商做出决策。

（2） 主程序员组

（3） 现代程序员组

5. 质量保证

（1） 软件质量

软件与明确地和隐含地定义的需求相一致的程度。具体的说。软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度

（1）软件需求是度量软件质量的基础。

（2）有没有显式描述的隐含需求。

（3）不遵守一组指导软件开发的准则，会导致软件质量不高。

（2） 软件质量保证措施

基于非执行的测试（复审或评审）、基于执行的测试、程序正确性证明

1） 技术复审的必要性

2） 走查

3） 审查

4） 程序正确性证明：使用数学方法严格验证程序是否与它的说明完全一致。

6. 软件配置管理

软件的整个生命期内管理变化的一组活动，目标是使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。

（1） 软件配置

1） 软件配置项（程序、文档、数据）

2） 基线：已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发

的基础，并且只有通过正式的变化控制过程才能改变它。

（2） 软件配置管理过程

1） 标识软件配置中的对象

2） 版本控制

3） 变化控制

4） 配置审计

正式的技术复审:关注被修改后的配置对象的技术正确性。

软件配置审计:通过评估配置对象那些通常不在复审过程中考虑的特征，是

对正式技术复审的补充。

7. 能力成熟度模型CMM

基本思想：由于问题是由人们管理软件过程的方法不正当引起的，所以新软件技术的运用并不会自动提高软件的生产率和质量。能力成熟度模型有助于软件开发机构建立一个有规律、成熟的软件过程。

1） 初始级

2） 可重复级

3） 已定义级

4） 已管理级

5） 优化级