软件工程整理

基于张海藩老师出版的《软件工程导论（第六版）》，简单整理软件工程各章知识。

第一章 软件工程学概述

1.1软件危机

1.1.1软件危机的介绍

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

软件危机包括下述两个方面：

1. 如何开发软件，以满足软件日益增长的需求。
2. 如何维护数量不断膨胀的已有软件。

软件危机主要有一下一些典型表现：

1. 对软件开发成本和进度的估计常常不准确
2. 用户对“已完成的”的软件系统不满意的现象时常发生
3. 软件的质量往往靠不住
4. 软件常常是不可维护的
5. 软件通常没有适当的文档文件
6. 软件成本在计算机系统总成本中所占的比例逐年上升
7. 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势

1.1.2产生软件危机的原因

在软件开发和维护的过程中存在这么多严重问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。

1.1.3消除软件危机的途径

为了解决软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。

1.2软件工程

1.2.1软件工程的介绍

1993年IEEE进一步给出了一个更全面更具体的意义：“软件工程是：①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也及时把软件工程应用于软件；②研究①中提到的途径。”

软件工程具有以下的本质特征：

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

1.2.2软件工程的基本原理

七条基本原理：

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

1.2.3软件工程方法学

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

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

目前最广泛 的软件工程方法学，分别是传统法学和面向对象方法学。

1.3软件生命周期

软件生命周期由软件定义、软件开发和运行维护3个时期组成。（三时期）

每个时期又进一步划分成若干阶段（八阶段）：

1. 软件定义时期划分成3个阶段，即问题定义、可行性研究和需求分析。
2. 软件开发时期划分成4个阶段，即总体设计、详细设计、编码和单元测试、综合测试。
3. 对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发的过程。（软件维护）

1.4软件过程

生命周期模型规定了把规定生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也成过程模型。

1.4.1瀑布模型

传统方法学

特点：

1. 阶段间具有顺序性和依赖性（一定线性）
   ①必须等前一段的工作完成后，才能开始后一阶段的工作。②前一阶段的输出文档就是后一阶段的输入文档。

2. 推迟实现的观点（贡献：首次提出）

3. 质量保证的观点

   ①每个阶段都必须完成规定的文档。②每个阶段结束前都要对所完成的文档进行评审。

总结：文档驱动。

优点：瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型

缺点：

1. 用户很难清晰表达出需求
2. 程序员也不能一下理解
3. 文档过多

1.4.2快速原型模型

循环

特点：

1. 快速开发工具
2. 循环
3. 低成本

1.4.3增量模型

特点：

1. 在前面增量的基础上开发后面的增量
2. 每个增量的开发可用瀑布或快速模型
3. 迭代的思路

1.4.4螺旋模型

特点：

1. 瀑布模型+快速原型模型+风险分析
2. 迭代过程

优点：

1. 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。
2. 减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险。
3. 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。

风险驱动即时优点的主要来源，也可能是弱点。

1.4.5喷泉模型

面向对象开发学

“喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。

1.4.6Rational统一过程

面向对象开发学

1.4.7敏捷过程与极限编程

1. 敏捷过程

   敏捷宣言：

   ①个体和交互胜过过程和工具
   ②可以工作的软件胜过面面俱到的文档
   ③客户合作胜过合同谈判
   ④响应变化胜过遵循计划

2. 极限编程

1.4.8微软过程

1.5小结

第二章 可行性研究

2.1可行性研究

目的：是否值得去解决；是否能够解决。

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

方面：

1. 技术可行性
2. 经济可行性
3. 操作可行性
4. 法律、社会效益等更广泛的方面

2.2可行性研究过程

步骤：

1. 复查系统规模和目标
2. 研究目前正在使用的系统
3. 导出新系统的高层逻辑模型
4. 进一步定义问题
5. 导出和评价选择的解法
6. 推荐行动方针
7. 草拟开发
8. 书写文档提交审查

2.3系统流程图

物理数据图

描绘了组成系统的主要物理元素以及信息在这些元素间流动和处理的情况。（而不是对数据分析进行加工处理的控制过程）

2.4数据流图

基本逻辑功能

功能模型的基础

绘制方法：由内向外，自顶向下，分层绘制，逐步求精。

2.5数据字典

名称，别名，描述，定义，位置

2.6成本/效益分析

2.6.1成本估计

1. 代码行技术
2. 任务分解技术
3. 自动估计成本技术

2.6.2成本/效益分析的方法

1. 货币的时间价值
2. 投资回收期
3. 纯收入
4. 投资回收率

2.7小结

第三章 需求分析

常用方法有面向数据流的结构化分析方法，面向数据结构的分析方法，面向对象的分析方法。

3.1需求分析的任务

功能需求，性能需求，可靠性和可用性需求，出错处理需求，接口需求，约束，逆向需求，将来可能提出的需求

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

3.2.1访谈

不理想

正式和非正式

3.2.2面向数据流自顶向下求精

不理想

结构化分析方法

3.2.3简易的应用规格说明技术

主流

3.2.4快速建立软件原型

最准确、最有效、最强大

“快速”、“容易修改”

3.3分析建模与规格说明

3.4实体-联系图

描述数据对象之间的关系

数据模型的基础

3.4.1数据对象

有一组属性来定义

3.4.2属性

定义了数据对象的性质

3.4.3联系

数据对象之间相互连接的方式

3.4.4实体-联系图的符号

实体：矩形
关系：菱形
属性：椭圆

3.5数据规范化

范式

1. 减少数据冗余
2. 避免插入或删除异常

3.6状态转换图

外部事件结果的系统行为

行为建模的基础

3.7其他图形工具

3.7.1层次方框图

属性描绘数据的层次结构

3.7.2Warnier图

树形 > 层次方框图

最著名的数据结构设计方法：Jackson + Warnier

3.7.3IPO图

输入、处理、输出图

简略描述简单算法

3.8验证软件需求

15%的错误来源

3.8.1从哪些方面验证软件需求的正确性

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

3.8.2验证软件需求的方法

1. 人工/形式化
2. 根据以往开发经济
3. 原型系统

3.8.3用于需求分析的软件工具

PSL/PSA

第四章 形式化说明技术

4.1概述

4.1.1非形式化方法的缺点

矛盾、二义性、不完整性及抽象层次混乱

4.1.2形式化方法的优点

1. 准确、简介描述
2. 不同软件活动中平滑过渡
3. 高层确认的手段

4.1.3应用形式化方法的准则

辩证地看待

4.2有穷状态机

准确描述一个系统，表达规格说明的一种形式化方法

4.3Petri网

确定系统中隐含的定时问题，也可用于设计中

4.4Z语言

第五章 总体设计

划分物理元素、设计软件结构

5.1设计过程

系统设计阶段，确定具体实现方案、结构设计阶段、确定软件结构

5.2设计原理

5.2.1模块化

程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，这些模块集成起来成一个整体，可完成制定功能满足客户需求。

模块：边界元素限定相邻程序元素的序列，且有一总体标识符代表它。

5.2.2抽象

抽出失误的本质特征而暂时不考虑细节 / 分层次考虑与处理系统 / 一种忽略多余细节同时强调有关的细节

5.2.3逐步求精

为了能集中精力解决主要问题而尽量推迟对问题细节的考虑 / 是设计者在设计过程中逐步揭开底层细节

5.2.4信息隐藏和局部化

模块内的信息对不需要的模块是不可见的

将关系相近的物理放得近

“隐藏”意味着有效的模块化可以通过定义一组独立的模块而实现，这些独立的模块彼此间仅仅交换那些为了完成系统功能而必须交换信息。

5.2.5模块独立

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

1. 耦合

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

2. 内聚

   功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚

5.3启发规则

1. 改进软件结构提高模块独立性
2. 模块规模应该适中
3. 深度、宽度、扇出和扇入都应适当
4. 模块的作用域应该在控制域之内
5. 力争降低模块接口的复杂度
6. 设计单入口单出口的模块
7. 模块功能应该可以预测

5.4描绘软件结构的图形工具

5.4.1层次图和HIPO图

HIPO = 层次图 + IPO

5.4.2结构图

SC图

5.5面向数据流的设计方法

变换流和事务流

第六章 详细设计

6.1结构程序设计

3种基本控制结构：顺序、循环、选择

6.2人机界面设计

可使用性※、灵活性、可靠性

6.2.1设计问题

系统响应时间、用户帮助设施、出错信息处理、命令交互

6.2.2设计过程

迭代的过程

四个预示：

1. 规格说明书的长度和复杂程度 → 学习工作量
2. 命令和动作 → 系统交互时间和总体效率
3. 动作、命令和系统状态的数量 → 需要记忆的内容
4. 界面风格、帮助设施和出错处理协议 → 界面复杂度、用户接受该界面的程度

6.2.3人机界面设计指南

一般交互指南、信息显示指南、数据输入指南

6.3过程设计的工具

图示、表格、语言

6.3.1程序流程图

历史长、最混乱

三个缺点：

1. 本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流，而不去考虑程序的全剧结构。
2. 程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾程序设计的精神，随意转移控制。
3. 程序流程图不易表示数据结构。

6.3.2盒图

结构程序设计精神

四个特点：

1. 结构化功能域清晰
2. 控制不能随意转移
3. 数据的作用域清晰
4. 易表示嵌套、层次关系

6.3.3PAD图

问题分析图、二维树形、易译成代码

六个优点:

1. 结构化程序
2. 程序结构十分清晰
3. 程序逻辑，易读、易懂、易记（三个易）
4. 可用软件工具自动完成
5. 既可以表示程序逻辑，也可用于描绘数据结构
6. PAD图的符号支持自顶向下、逐步求精方法的使用（def符号增加细节）

6.3.4判定表

用于清楚地表示复杂的条件组合和应做的动作之间的关系

6.3.5判定树

形式简单，但重复多，分支的次序影响判定树的复杂度。

6.3.6过程设计语言

不如图形清晰

= 自然语言 + 结构化语言

四个特点：

1. 结构化控制结构、数据说明和模块化
2. 自然语言的自由语法
3. 数据说明的手段
4. 应提供接口描述模式

优点：

1. 可以作为注释，以提高文档的质量。
2. 可以使用普通的正文编辑程序或文字处理。
3. 有程序可以自动由PDL生成程序代码。

缺点：不如图形工具形象直观，不如判定表清晰简单。

6.4面向数据结构的设计方法

Jackson和Warnier最著名面向数据结构的设计方法。

6.5程序复杂程度的定量度量

6.5.1McCabe方法

根据程序控制流图的复杂度定量度量程序的复杂度。

环形复杂度V（G）= 图形数 = E – N + 2 = P + 1

V（G） ≤ 10最好

6.5.2Halstead方法

根据程序中的运算符（包括关键字）和操作数的总数度量程序的复杂度。

第七章 实现

开发是自顶向下、逐步细化，测试是自顶向上、逐步集成。

软件测试不等于程序测试，软件测试应贯穿于软件定义与开发的整个期间。

7.1编码

7.1.1选择程序设计语言

实用标准：

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

7.1.2编码风格

1. 程序内部的文档
2. 数据说明
3. 语句构成
4. 输入输出
5. 效率

7.2软件测试基础

7.2.1软件测试的目标

G.Myers测试定义：

1. 测试是为了发现程序中的错误而执行程序的过程
2. 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案
3. 成功的测试是发现了至今为止尚未发现的错误的测试

7.2.2软件测试准则

测试准则：

1. 所有测试都应该能追溯到用户需求
2. 应该远在测试开始之前就制定出测试计划
3. Pareto原理：80%的错误在20%的模块中
4. 测试顺序应该是从“小规模”测试开始，并逐步进行“大规模”测试
5. 穷举测试是不可能的
6. 应有独立的第三方从事测试工作

7.2.3测试方法

黑盒测试，即功能测试

白盒测试，即结构测试

7.2.4测试步骤

模块测试、子系统测试、系统测试、验收测试、平行运行

7.2.5测试阶段的信息流

7.3单元测试

集中检测软件设计的最小单元——模块

应用人工测试和计算机测试完成单元测试

7.3.1测试重点

1. 模块接口
2. 局部数据结构
3. 重要的执行通路
4. 出错处理通路
5. 边界条件

7.3.2代码审查

人工测试和计算机测试是相互补充，相辅相成的，缺少其中任何一种方法都会使查找错误的效率降低。

7.3.3计算机测试

需要驱动模块、存根模块，通常不把它们作为产品的一部分交给用户。

模块的内聚程度高可以简化单元测试过程

7.4集成测试

集成测试是测试和组装软件的系统化技术，主要目标是发现与**接口**有关的问题。

分为渐增测试方法与非渐增测试方法

7.4.1自顶向下集成

深度优先或宽度优先

在测试的早起对主要的控制或关键的抉择进行检验

优点：不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，而且能在早期发现上层模块的接口错误

缺点：需要存根程序，可能遇到与此相联系的测试困难，低层关键模块中的错误发现较晚，而且用这种方法在早期不能充分展开人力

7.4.2自底向上集成

优缺点与自顶向下集成刚好相反

7.4.3不同集成测试策略的比较

混合法，即对软件结构中较上层使用的自顶向下方法与对软件结构中较下层使用的自底向上方法相结合，可能是**最好的**折衷方法。

7.4.4回归测试

重新执行已经做过的测试的某个子集，以保证上述这些变化没有带来非预期的副作用。

7.5确认测试

※确认测试计划在需求分析阶段制定，其他测试都在总体设计阶段制定。

7.51确认测试的范围

通常使用黑盒测试法

要保证软件能满足所有功能要求，能达到每个性能要求，文档资料是准确而完整的，此外，还应该保证软件能满足其他预定的要求（例如安全性、可移植性、兼容性和可维护性）

7.5.2软件配置复查

确认测试的一个重要内容是复查软件配置。

复查的目的是保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节，而且已经编好目录。

7.5.3Alpha和Beta测试

Alpha测试：在开发场所进行测试，并有开发人员指导。

Beta测试：在使用环境下进行测试，尽量使用真实数据。

7.6白盒测试技术

设计测试方案的基本目的是，确定一组最可能发现某个错误或某类错误的测试数据。

7.6.1逻辑覆盖

1. 语句覆盖
2. 判定覆盖
3. 条件覆盖
4. 判定/条件覆盖
5. 条件组合覆盖
6. 点覆盖
7. 边覆盖
8. 路径覆盖

7.6.2控制结构测试

1. 基本路径测试
2. 条件测试
3. 循环测试

7.7黑盒测试

黑盒测试力图发现下述类型的错误：

1. 功能不正确或遗漏了功能
2. 界面错误
3. 数据从结构错误或外部数据仓库访问错误
4. 性能错误
5. 初始化和终止错误

7.7.1等价划分

7.7.2边界值划分

7.7.3错误推测

7.8调试

调试就是把症状和原因联系起来的尚未被人深入认识的智力过程。

7.8.1调试过程

调试不是测试，但是他总是发生在测试之后。

7.8.2调试途径

1. 蛮干法
2. 回溯法
3. 原因排除法：包括对分查找法、归纳法和演绎法

7.9软件可靠性

7.9.1基本概念

可靠性：在给定的时间间隔内，按照规格说明书的规定成功运行的概率。

可用性：在给定的时间点，按照规格说明书的规定成功运行的概率。

7.9.2估算平均无故障时间的方法

MTTF

第八章 维护

开发成本的四倍，组织中60%的人手

软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。

8.1软件维护的定义

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

8.2软件维护的特点

8.2.1结构化维护与非结构化维护差别巨大

区别：有无完整软件配置

结构化维护：评价文档 → 估量、设计 → 修改设计 → 修改代码 → 回归测试 → 交付

8.2.2维护的代价高昂

费用高、用户不满、新的错误、开发混乱、产率下降

8.2.3维护的问题很多

缺少软件配置、不易理解且与代码不一致、编写者已不在、设计时没考虑维护、软件维护不是一件吸引人的事

8.3软件维护过程

维护组织、维护报告、维护的事件流、保存维护记录、评价维护活动

8.4软件的可维护性

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

8.4.1决定软件可维护性的因素

可理解性、可测试性、可修改性、可移植性、可重用性

8.4.2文档

文档是影响软件可维护性的决定因素

文档分为：用户文档，主要描述系统功能和使用方法。
系统文档，描述系统设计、实现和测试等。

用户文档至少包括：功能描述、安装文档、使用手册、参考手册、操作员指南

8.4.3可维护性复审

8.5预防性维护

实质是软件再工程

8.6软件再工程过程

该模型所定义的六类活动：库存目录分析、文档重构、逆向工程、代码重构、数据重构、正向工程

第九章 面向对象方法学

面向对象 = 对象 + 类 + 继承 + 通信

9.1面向对象方法学概述

尽可能模拟人类习惯的思维方式

9.1.1面向对象方法学的要点

四个要点：

1. 对象：作为由数据及可以施加在这些数据上的操作所构成的统一体。
2. 类：对具有相同数据和相同操作的一组相似对象的定义。
3. 继承：下层的派生类自动具有和上层的基类相同的特性。
4. 消息：对象彼此之间仅能通过传递消息相互联系。

9.1.2面向对象方法的优点

1. 与人类习惯的思维方式一致
2. 稳定性好
3. 可重用性好
4. 较易开发大型软件产品
5. 可维护性好

9.2面向对象的概念

9.2.1对象

对象是对问题域中某个实体的抽象

对象是由描述该对象属性的数据以及可以对这些数据施加的所有操作封装在一起构成的统一体

9.2.2其他概念

1. 类

   就是对具有相同数据和相同操作的一组对象的定义

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

2. 实例

   一个具体的对象

   就是类的实际例子

3. 消息

   要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明

4. 方法

   对象所能执行的操作，也就是类中所定义的服务

5. 属性

   类中所定义的数据，它是对客观世界实体所具有的性质的抽象

6. 封装

   把数据和实现操作的代码集中起来放在对象内部

   三个条件：清晰边界、确定的接口、受保护的内部实现

7. 继承

   子类自动地共享基类中定义的数据和方法的机制

8. 多态性

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

   是指在父类中定义的属性或服务被子类继承后，可以具有不同的数据类型或表现出不同的行为

   在类等级不同层次可共享一个方法名，不同层次每个类按各自需要实现这个方法

9. 重载

   有两种重载：函数重载，同一作用域内的若干参数特征不同的函数可以使用相同的函数名字

   ​ 运算符重载，同一个运算符可以施加于不同类型的操作数上面

9.3面向对象建模

三种基本模型：对象模型（类图）、动态模型（状态图）、功能模型（用例图）

9.4对象模型

最重要的、实质性的框架

静态的、结构化的数据性质

9.4.1类图的基本符号

类与类之间的静态关系、一种静态模型

9.4.2表示关系的符号

关联、聚合、泛化、依赖和细化

9.5动态模型

基于事件共享而关联起来的状态图

9.6功能模型

9.6.1用例图

包含的模型元素有系统、行为者、用例及用例之间的关系

9.6.2用例建模

寻找行为者和用例是关键

9.7三种模型之间的关系

1. 针对每个类建立的动态模型，描述了类实例的生命周期或运行周期。
2. 状态转换驱使行为发生，这些行为在数据流图中被映射成处理，在用例图中被映射成用例，它们同时与类图中的服务相对应。
3. 功能模型中的处理对应于对象模型中的类所提供的服务。
4. 数据流图中的数据存储，以及数据的源点/终点，通常是对象模型中的对象。
5. 数据流图中的数据流，往往是对象模型中对象的属性值，也可能是整个对象。
6. 用例图中的行为者，可能是对象模型中的对象。
7. 功能模型中的处理可能产生动态模型中的事件。
8. 对象模型描述了数据流图中的数据流、数据存储以及数据源点/终点的结构。

第十章 面向对象分析

面向对象分析：不可能是顺序线性的、需求陈述不是一成不变的

10.1面向对象分析的基本过程

抽取和整理用户需求并建立精准问题域精确模型的过程

10.1.1概述

寻找类与对象、确认结构、确认主题、确认属性、建立动态模型、建立功能模型、确认服务

10.1.2三个子模型与五个层次

子模型：对象模型、动态模型、功能模型

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

10.2需求陈述

10.2.1书写要点

需求陈述的内容包括问题范围、功能需求、应用环境及假设条件等

10.2.2例子

10.3建立对象模型

OOA的首要工作

对象模型对细节依赖少，容易确定；需求变化时，更稳定。

10.3.1确定类与对象

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

10.3.2确定关联

两个或多个对象之间的相互依赖、相互作用的关系就是关联

10.3.3划分主题

为了降低复杂程度，人们习惯于把系统再进一步划分成几个不同的主题，也就是在概念上把系统包含的内容分解成若干个范畴。

10.3.4确定属性

属性是对象的性质，属性使人们能对类与对象和结构有更深入更具体的认识。

分析阶段不需要属性来表示对象之间的关系，使用关联能表示任何对象之间的关系，且清晰、醒目。

10.3.5识别继承关系

可以使用两种方法建立继承关系：自底向上、自顶向下

10.3.6反复修改

软件开发过程就是一次多次反复修改、逐步完善的过程。

10.4建立动态模型

在开发交互式系统时，建立正确的动态模型是至关重要的。

10.4.1编写脚本

脚本是指系统在某一执行期间内出现的一系列事件。

编写脚本的目的，是保证不遗漏重要的交互步骤，它有助于确保整个交互过程的正确性和清晰性。

10.4.2设想用户界面

大多交互行为都可以分为应用逻辑和用户界面两部分

应用逻辑是内在的、本质的内容，用户界面是外在的表现形式。

10.4.3画事件跟踪图

1. 确定事件
2. 画出事件跟踪图

脚本中容易找出正常事件，但不要遗漏了异常事件和出错条件。

10.4.4画状态图

10.4.5审查动态模型

10.5建立功能模型

功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能。

10.5.1画出基本系统模型图

10.5.2画出功能级数据流图

10.5.3描述处理框功能

10.6定义服务

1. 常规行为
2. 从事件导出的操作
3. 与数据流图中处理框对应的操作
4. 利用继承减少冗余操作

第十一章 面向对象设计

把需求分析阶段得到的需求转变成符合质量和成本要求的、抽象的系统实现方案的过程

11.1面向对象设计的准则

除了第五章讲述的几条基本原理，还应增加模块化、抽象、信息隐蔽、弱耦合、强内聚、可重用。

11.2启发规则

1. 设计结果应该清晰易懂
2. 一般-特殊结构的深度应适当
3. 设计简单的类
4. 使用简单的协议
5. 使用简单的服务
6. 把设计变动减至最小

11.3软件重用

11.3.1概述

1. 重用：知识重用、方法和标准的重用、软件成分的重用
2. 软件成分的重用级别：代码重用、设计结果重用、分析结果重用
3. 典型的可重用软件成分：项目计划、成本估计、体系结构、需求模型和规格说明、设计、源代码、用户文档和技术文档、用户界面、数据、测试用例

11.3.2类构件

1. 可重用软构件应具备的特点：模块独立性强、具有高度可塑性、接口清晰简明可靠
2. 类构件的重用方式：实例重用、继承重用、多态重用

11.3.3软件重用的效益

质量、生产率、成本

11.4系统分解

1. 子系统之间的两种交互方式
2. 组织系统的两种方案
3. 设计系统的拓扑结构

11.5设计问题域子系统

1. 调整需求：①用户需求或外部环境发生了变化；②分析员对问题域理解不够透彻或缺乏领域专家帮助
2. 重用已有的类
3. 把问题域类组合在一起：引入根类而吧问题域类组合在一起
4. 增添一般化类一建立协议
5. 调整继承层次：使用多重继承机制、使用单继承机制
6. ATM系统实例

11.6设计人机交互子系统

分类用户、描述用户、设计命令层次、设计人机交互类

11.7设计任务管理子系统

分析并发性、设计任务管理子系统

11.8设计数据管理子系统

11.8.1选择数据存储管理模式

文件管理系统、关系数据库管理系统、面向对象数据库管理系统

11.8.2设计数据管理子系统

11.8.3例子

11.9设计类中的服务

11.9.1确定类中应有的服务

11.9.2设计实现服务的方法

设计实现服务的算法、选择数据结构、算法与数据结构的关系、定义内部类和内部操作

11.10设计关联

关联的遍历、实现单向关联、实现双向关联、关联对象的实现

11.11设计优化

11.11.1确定优先级

11.11.2提高效率的几项技术

1. 增加冗余关联以提高访问的效率
2. 调整查询次序
3. 保留派生属性

11.11.3调整继承关系

1. 抽象与具体
2. 为提高继承程度而修改类定义
3. 利用委托实现行为共享

第十二章 面向对象实现

面向对象实现主要包括两项工作：①把面向对象设计结果翻译成用某种程序语言书写的面向对象程序②测试并调试面向对象的程序

12.1程序设计语言

12.1.1面向对象语言的优点

一致的表示方法；可重用性；可维护性

12.1.2面向对象语言的技术特点

1. 支持类与对象概念的机制
2. 实现整体-部分（即聚集）结构的机制
3. 实现一般-特殊（即泛化）结构的机制
4. 实现属性和服务的机制
5. 类型检查
6. 类库
7. 效率
8. 持久保存对象
9. 参数化类
10. 开发环境

12.1.3选择面向对象语言

1. 将来能否占主导地位
2. 可重用性
3. 类库和开发环境
4. 其他因素

12.2程序设计风格

12.2.1提高可重用性

1. 提高方法的内聚
2. 减小方法的规模
3. 保持方法的一致性
4. 把策略与实现分开
5. 全面覆盖
6. 尽量不使用全局信息
7. 利用继承机制

12.2.2提高可扩充性

1. 封装实现策略
2. 不要用一个方法遍历多条关键链
3. 避免使用多分支语句
4. 精心确定公有方法

12.2.3提高健壮性

1. 预防用户的操作错误
2. 检查参数的合法性
3. 不要预先确定限制条件
4. 先测试后优化

12.3测试策略

测试软件的经典策略是，从“小型测试”开始，逐步过渡到“大型测试”。

12.3.1面向对象的单元测试

不能再鼓励地测试单个操作，而应该吧操作作为类的一部分来测试

12.3.2面向对象的集成测试

相较于结构化测试，难度增加

两种不同的策略：①基于线程的测试 ②基于使用的测试

12.3.3面向对象的确认测试

可以用传统的黑盒测试方法也可用于设计确认测试用例，但主要还是根据动态模型和描述系统行为的脚本来设计确认测试用例。

12.4设计测试用例

12.4.1测试类的方法

1. 随机测试
2. 划分测试
3. 基于故障的测试

12.4.2集成测试方法

1. 多类测试
2. 从动态模型导出测试用例

第十三章 软件项目管理

先于任何技术开始之前并贯穿于整个生命周期

13.1估算软件规模

13.1.1代码行技术

优点：容易计算

缺点：①源代码仅是软件配置的一部分②不同语言书写同一程序所需代码不同③不适用于非过程语言

13.1.2功能点技术

克服了代码行的缺点

13.2工作量估算

13.2.1静态单变量模型

13.2.2动态多变量模型

13.2.3COCOMO2模型

13.3进度计划

13.3.1估算开发模型

Walston_Felix、COCOMO、COCOMO2、PUTNAM（动态多变量）

13.3.2Gantt图

历史悠久、应用广泛

缺点：
①不能显示地描绘各项作业彼此间的依赖关系
②进度计划的关键部分不明确
③计划中有潜力的部分及潜力的大小不明确

13.3.3工程网络

13.3.4估算工程进度

13.3.5关键路径

13.3.6机动时间

13.4人员组织

13.4.1民主制程序员组

小组成员完全平等，享有充分民主，通过协商作出技术决策

13.4.2主程序员组

主程序员既有技术又有行政管理能力

13.4.3现代程序员组

两种程序员组的综合

13.5质量保证

13.5.1软件质量

软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”

13.5.2软件质量保证

为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动

13.6软件配置管理

软件配置管理是在软件的整个生命期内管理变化的一组活动。

这组活动用来：①表示变化②控制变化③确保适当地实现了变化④想需要知道这类信息的人报告变化

13.6.1软件配置

1. 软件配置项：①计算机程序②描述计算机程序的文档③数据

2. 基数

   各开发阶段末尾的特定点

   已经通过正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制工程才能改变他。

13.6.2软件配置管理过程

软件配置管理主要有五项任务：标识、版本控制、变化控制、配置审计和报告

13.7能力成熟度模型

初始级、可重复级、已定义级、已管理级、优化级