前言

个人学习整理之用。

软件生命周期

软件生命周期一般分为八个阶段：
问题定义、可行性研究、需求分析、概要设计（总体设计）、详细设计、编码和单元测试、测试（综合测试）、软件维护。

问题定义

确定好要解决的问题是什么（what），通过对客户的访问调查，系统分析员扼要的写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。

可行性研究

确定该问题是否存在一个可行的解决方案，探索这个问题是否值得去解决。更进一步明确项目的规模与目标，从 技术可行性 、经济可行性 、操作可行性 、法律可行性 等方面进行研究，确定是否开发该项目。

需求分析

深入具体的了解用户的需求，确定目标系统必须具备哪些功能，用 《需求规格说明书》 记录对目标系统的需求。系统分析员在本阶段必须与用户密切配合，充分交流，得到经用户确认的系统逻辑模型，用 数据流图 、数据字典和简要的算法表示系统的逻辑模型。需求分析阶段所确定的系统逻辑模型是以后设计和实现目标系统的基础，必须准确、完整的体现用户的需求。

概要设计（总体设计）

概括的说，应该怎样实现目标系统，设计出实现目标系统的几种可能方案，设计程序的体系结构，也就是确定程序由哪些模块组成以及模块之间的关系。还应该考虑系统的开发和应用环境，如计算机系统的配置、计算机网络配置等。

详细设计

实现系统的具体工作，编写详细规格说明，程序员可以根据它们写出实际的程序代码。详细设计也称模块设计，在这个阶段将详细的设计每个模块，确定实现模块功能所需的算法和数据结构。

编码和单元测试

（编码占全部开发工作量的10%-20%）
本阶段主要是编写软件程序。程序员应根据目标系统的要求，选取合适的程序设计语言，把详细设计的结果编制成程序，并对每一个模块进行 单元测试 。

测试

（测试占全部开发工作量的40%-50%）
分为单元测试 、集成测试 、确认测试 和 系统测试。
本阶段的任务是通过各种测试以及相应的调试，使软件达到预定的要求。
应该把测试计划、测试方案、测试结果等以文档的形式保存下来，作为软件配置的一个组成部分。

软件维护

通过各种必要的维护活动使系统持久的满足用户的需求。主要分为改正性维护、适应性维护、完善性维护、预防性维护。
每一项维护活动都应该准确地记录下来，作为正式的文档保存。

软件交付

软件产品包括：程序、文档、数据

成本估算方法

成本估算方法就方法论而言，有两种基本的成本估算方法：自顶向下 和 自底向上。

自顶向下法

自顶向下法是对整个工程项目的总开发时间和总工作量做出估算，然后将它们按阶段、步骤和任务进行分配。

自顶向下的成本估计的方法主要有 COCOMO模型 估计方法。

自顶向下的成本估计方法的 优点：
工作量小、速度快。

自顶向下的成本估计方法的 缺点：
对开发某些局部问题或者特殊困难易低估甚至没有考虑；
如果所开发的软件缺乏可以借鉴的经验，则估计偏差可能较大。

自底向上法

自底向上法则正好相反，先分别估算各个任务所需要的工作量和开发时间，再相加，从而得到总的工作量和总的开发时间。

自底向上的成本估计方法主要有面向规模(LOC)的度量 和 面向功能点(FP)的度量。

自底向上的成本估计方法的 优点：
可以详细的描述项目工作量，便于项目进度的安排；
自底向上的成本估计方法的 缺点：
这种方法对涉及全局的话（如质量管理）可能估计不足甚至完全忽视，使得估计值可能偏低。

这两种方法都要求采用某种方法做出估算。有许多估算方法可以利用，大致划分为三类：专家估算法、类推估算法、算式估算法

其他估算方法

专家估算法

依靠一个或多个专家对项目做出估算，其精度主要取决于专家对估算项目的定性参数的了解和他们的经验。

类推估算法

在自顶向下法中，类推估算法将估算项目的总体参数与类似项目进行直接比较得到结果；
在自底向上法中，类推是在两个具有相似条件的工作单元之间进行。

算式估算法

前两种估算法的缺点在于：它们依靠的是带有主观猜测和盲目性的估算方法。
算式估算法则是企图避免主观因素影响的一种方法。
算式估算法有两种基本类型：由理论导出的算法和由经验得出的算法。

差别估算法

差别估算是与一个或多个已完成的类似项目进行比较，找出与某个相似项目的若干不同之处，并估算每个不同之处对成本的影响，导出软件项目的总成本。
优点：该方法可以提高估算的准确度
缺点：不容易明确差别的界限。

E-R图

E-R图中的1对多就是1:N,多对多就是N:M。
在E-R模型中，包括 实体 、联系 、属性 .

E-R图成分

在ER图中有如下四个成分：
矩形框：
　　表示实体，在框中记入实体名。
菱形框：
　　表示联系，在框中记入联系名。
椭圆形框：
　　表示实体或联系的属性，将属性名记入框中。对于主属性名，则在其名称下划一下划线。
连线：
　　实体与属性之间；
　　实体与联系之间；
　　联系与属性之间用直线相连，并在直线上标注联系的类型。

对于一对一联系，要在两个实体连线方向各写1；
对于一对多联系，要在一的一方写1，多的一方写N；
对于多对多关系，则要在两个实体连线方向各写N,M。

瀑布模型

瀑布模型是以文档驱动的软件生存周期模型，适合 需求明确 的软件系统开发。

瀑布模型有何特点？
瀑布模型特点：各阶段相互依赖；每阶段都进行评审；强调需求分析和设计。

瀑布模型是软件工程中应用最广泛的过程模型，试述采用瀑布模型进行软件开发的基本过程，该过程有何特点？

答：
瀑布模型规定了各项软件工程活动，包括需求分析、规格说明、设计、编码、测试和维护，并规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级而下。
瀑布模型的特点是：阶段间具有顺序性和依赖性；清楚区分逻辑设计和物理设计，尽可能推迟程序的物理实现；每个阶段都必须完成规定文档，且每阶段结束前需要对完成的文档进行评审。

瀑布模型的优缺点？
优点：
1、流水线生产比个人生产效率高，质量好。
2、将逻辑设计与物理实施分开，避免无用功。减少成本，能尽量推迟物理实施。
3、文档驱动使得开发过程可视化，便于管理和控制。
缺点：
1、当需求不明确时，流水线被阻塞。
2、得不到用户的反馈，开发过程得不到修正，导致有可能出现大的失误。
3、最后将产品一次提交给用户，用户感到不适应，成本增加，市场风险加大。

PAD图

PAD是问题分析图（Problem Analysis Diagram）的英文缩写，自1974年由日本的二村良彦等人提出的又一种主要用于描述软件详细设计的图形表示工具。与方框图一样，PAD图也只能描述结构化程序允许使用的几种基本结构。发明以来，已经得到一定程度的推广。它用二维树形结构的图表示程序的控制流，以PAD图为基础，遵循机械的走树（Tree Walk)规则就能方便地编写出程序，用这种图转换为程序代码比较容易。

面向对象分析

面向对象分析主要由对象模型、动态模型、功能模型组成，其中对象模型是最基本、最重要、最核心的；
面向对象建模得到的模型包含系统的三个要素：静态结构（对象模型）、交互次序（动态模型）、数据变换（功能模型）；
对象模型的五个层次：主题层、类与对象层、结构层、属性层、服务层。

常见知识点

软件包括 计算机程序、数据结构、文档 .
程序的三种基本控制结构 顺序 、选择 、 循环 .
软件生命周期中所花费最多的阶段是 软件维护 .
软件模块之间的耦合性越 弱 越好.
为了提高模块的独立性，模块之间最好是 数据耦合，模块内部最好是 功能内聚 .
辅助软件人员将某种形式表示的软件转换成更抽象形式表示的软件的工具是 逆向工程工具 .
IDEFO图主要元素的盒子和箭头，其中连到盒子四边的箭头所表示的活动所需或产生的数据约束包括 输入 、 输出 、 控制 .
UML图中的 顺序图 可以表示为了得到一个期望结果在多个角色之间进行的交互序列.
COCOMO模型 属于 成本估算方法.
结构化程序设计主要是强调的程序易读性 .

C语言中:
　　语句中，b = *a+1 – 指针a 指向的数值加1，
　　*a 是数值, b 等于那个数值加 1。
　　或把a看成数组元素 b = a[0] + 1;
　　*(a+1) – 指针 (a+1) 指向的数值
　　b = *(a+1) – 可以看成数组元素 b = a[1];

Hyman测试模型中，两人同时测试，甲发现a个错误，乙发现b个错误，其中有c个相同错误，则错误总数为 $S=\frac{a\bullet b}{c},$ 剩余错误数量 $n = S-(a+b-c).$

总结

可行性研究

1、软件工程项目 可行性研究 实质是一次 大大压缩和简化了的分析 和设计过程，主要在 较高层次上 以 较抽象的方式 进行，其目的是在尽可能短的时间内以 最小的代价 确定该项目 是否能够开发 ，是否值得开发 。

2、可行性研究 不是去开发一个软件项目，而是研究该项目能否在 给定的资源 和 给定的时间 开发，是否 能够开发 ，是否 值得开发 。

3、可行性研究的内容：

技术可行性 （相关技术分析、资源有效性分析、风险分析）
经济可行性 （成本估计、效益分析）
操作可行性 ，又称社会可行性和运行可行性（就政治意识形态、法律法规、社会道德、民族意识以及系统运行的组织机构或人员等，分析系统能否运行及运行好坏程度）

4、可行性研究的步骤：

对系统目标和范围的定义 $\Rightarrow$ 对现行系统进行分析研究 $\Rightarrow$ 导出新系统的逻辑模型 $\Rightarrow$ 设计新系统的物理方案 $\Rightarrow$ 推荐可行的方案

5、可行性研究阶段，成本估计 的方法：

① 基于已完成的类似项目进行估算；（自顶向下估计）
缺点:对开发中某些局部问题难以预估，导致考虑不周
② 使用简单的“分解技术”来进行成本及工作量的估算；（自底向上估计）
③ 使用经验模型进行成本及工作量的估算。（经验算法估计）

主要经验模型：静态单变量模型 、动态多变量模型 、COCOMO模型。

COCOMO模型：Boehm将软件成本估算分成3个由粗到细的层次：基本层 、中间层 和 详细层。每个层次又按 软件项目的应用领域和复杂程序 分成3种类型：组织型 、半独立型 和 嵌入型。

6、效益分析：
系统的效益有两部分：经济效益 和 社会效益。

经济效益 是指用使用新系统而增加的收入，包括使用新系统节省的运行费用，是一种有形的效益。
（经济效益度量指标：货币的时间价值、纯收入、投资回收期、投资回收率）；
社会效益 是一种无形的效益，主要从性质上、心理上进行衡量，很难直接量化，但在某些情况下，无效的效益能转化成有形的效益。

7、系统流程图
系统流程图是描绘 物理系统 的传统工具

可以采用系统流程图来描述项目的大概业务处理流程，其 基本思想 是用 图形符号以黑盒子形式描绘系统各部件（如程序、数据库、文档、人工过程等）。
系统流程图表达的是 信息在系统中各部件之间流动 的情况，而不是对信息进行 加工处理 的控制过程。（信息有流动无处理）

8、数据流图

数据流图描述的是 系统的逻辑模型，图中没有具体的物理元素，只是描绘信息在系统中的流动和处理情况。（数据流图是逻辑系统的图形表示）

软件项目计划

1、软件项目计划 的目标就是提供一个框架，使管理者有能够对资源、成本、风险及进度进行合理的估算分析和调度，为软件工程过程提供管理依据。

项目计划一般由软件项目的 管理员 、系统分析员 与用户经过 “可行性研究后” 共同制订，并在 “需求分析” 阶段确定软件系统的详细需求后定稿，随着项目的进展定期更新。

2、软件项目计划的 主要内容:

风险分析 、进度安排 和 项目组织。

3、风险分析活动：

风险标识（项目风险、技术风险和商业风险）、风险估计 、风险评价 和 风险管理与监控。

4、进度安排方法：

PERT 技术与 Gantt图 方法（看看书上的过程）。

小结：

由于经过风险分析，能够做到“知已知彼”（彼即风险），从而“百战不殆”，使得开发者能够战胜风险带来的损失，使项目成功。
进度安排的落空不仅会造成项目开发成本的提高，造成有形的经济损失，而且会使客户的不满意度、不信任度增加，造成无形的经济损失。
在软件开发过程中，人是最活跃的部分。

需求分析

1、需求分析是指开发人员通过细致的 调查分析，详细、准确和完整地理解 用户需要什么样的软件，将用户 非形式的需求 陈述转化为 完整的需求定义 ，再将需求定义转换到相应的 需求规格说明 的过程。

2、通常，把一整套的 需求分析方法 、技术和工具 等的集合称为 建模方法 。

3、需求收集的方式：

访谈（程式化的访谈和非程式化的访谈）
问卷调查
使用用例
用户资料收集
建立快速原型

4、需求分析主要任务：

问题分析
需求描述
需求评审

5、需求分析主要目的：确定用户需要系统 做什么。

6、需求规格说明：
需求分析的主要成果是得到 需求规格说明（SRS） 。

需求规格说明为用户、分析人员 、设计人员 和 测试人员 之间的理解和交流提供了方便，是系统设计、测试和验收的依据。

大量统计数字表明，软件系统中 15%的错误 起源于需求的错误。一个有效的需求规格说明应具有如下特征：

正确性
无歧义性
完整性
一致性
可验证性
可理解性
可修改性
可追踪性和注释 等。

需求分析说明书的作用：

① 用户与开发人员之间的合同
② 概要设计的依据
③ 软件验收测试的依据。

数据流建模（功能建模）

7、数据流建模：
数据流建模方法是一种 结构化分析方法（SA）；
自顶向下 、逐层分解地定义系统需求；
主要是利用 数据流图（DFD） 来对用户需求进行分析。

8、数据流图：
数据流图描述的是 系统的逻辑模型，图中没有具体的物理元素，只是描绘信息在系统中的流动和处理情况。（数据流图是逻辑系统的图形表示）

9、数据流图的四种基本符号：

数据流 （用箭头表示）
加工（加工一般用一个 圆圈或圆角方框 来表示）
数据存储 （一般用 开口的矩形框 或 双划线 来表示）
数据的源点和终点（一般用正方形或立方体来表示）

10、分层数据流图：
将数据流图分为 顶层数据流图，中间层数据流图 以及 底层数据流图，可以避免一次引入过多的细节，有利于控制问题的 复杂度，从而便于对 大型系统 描述的实现。

① 顶层数据流图:主要描述整个系统的 作用范围，说明系统的边界，反映 系统和外部环境之间的关系，即系统的 输入和输出数据流 。 **顶层数据流图只有一张**。
② 中间层数据流图：通过分解高层加工得到的，其中有些加工还需进一步分解。
③ 底层数据流图：底层数据流图由一些不必再进行分解的加工组成。

11、数据流建模步骤:
原则上是由外向里、自顶向下去模拟问题的处理过程.

画顶层数据流图；
画分层数据流图；
用数据词典定义数据流图中的所有数据；
用加工说明描述数据流图中的基本加工。

12、数据词典：
又称 数据字典，是关于 数据信息 的集合，是对 数据流图 中的每个数据，包括 数据流 和 数据存储，进行严格定义的场所，以保持数据在系统中的 一致性。
数据字典的作用：

① 为用户与开发人员之间统一认识
② 作为概要设计的依据
③ 便于需求分析阶段定义各类条目

13、加工说明：
数据流图中的 “基本加工” 由于没有进一步分解得到子图，因而需要加工说明来对其进行描述。

加工说明 是描述基本加工如何把输入数据流变换成 输出数据流 的加工规则，是描述实现加工的策略而不是实现加工的细节。

IPO图、结构化语言（PDL，伪代码，是一种介于自然语言和形式语言之间的一种半形式语言）、判定表 、判定树 等均可作为加工说明的工具。

IDEF0图（功能建模）

14、IDEF0功能建模:
IDEF方法是一套用来对 复杂系统进行建模分析和设计的系统方法：

IDEF0进行 功能建模，IDEF1X用来建立数据模型，IDEF4方法则用于面向对象设计，等等。

15、IDEF0方法用严格的自顶向下 、逐层分解 的方式来构造系统的 功能模型，用 IDEF0图 来描述。

IDEF0图：只能反映系统做什么，系统功能由谁做，但不能反映系统如何做，因为盒子内部的结构如何无从得知。

16、IDEF0图:
也称为 活动图形 。

主要元素是简单的盒子及箭头。
盒子代表系统的 功能（活动） 。
箭头表示系统处理的 数据约束，可以是具体的事物，也可以是抽象的信息。

IDEF0功能建模方法要求一张IDEF0图中的盒子最多只能有 6个（子图形还要求不少于3个）。

17、IDEF0建模步骤：
IDEF0方法在详细的功能需求调研基础上，用严格的自顶向下、逐层分解的方式来进行；

确定建模的范围、观点及目的
建立系统的内外关系图，即 A-0图
建立A0图的一系列子图；书写文字说明。（P49）

IDEF1X（数据建模）

18、IDEF1X数据建模：
IDEF1X方法 是IDEF1方法的扩展版本。

IDEF1 用来表示系统的 信息结构和语义。
IDEF1X方法增强了图形的表达能力，丰富了语义和简化了开发过程。

19、IDEF1X图：
实体是具有相同属性或特征的现实或抽象事物的集合，这个集合中的一个元素便称为实体的一个实例。

在一张IDEF1X图中，一个实体只能在图中出现一次。
属性：表示现实或抽象的事物一种特性或性质。

IDEF1X建模步骤：

0 阶段——确定建模目标和计划；
1 阶段——定义实体
2 阶段——定义联系
3 阶段——定义键
4 阶段——定义属性

面向对象方法

1、UML建模语言：是一种可以应用于任面向对象软件开发方法的 标记法 和 语义语言 。

2、UML各种图：
**动态模型图(反映系统行为)**：

用例图、顺序图、协作图、状态图、活动图。

静态模型图（反映系统结构）：

类图、包图、组件图、部署图、对象图。

3、UML特点 ：
统一了面向对象方法 的基本概念（UML融合了 Booch方法 、OMT方法 和 OOSE方法 中的有关概念）；
具有更强的建模能力（正如G. Booch在他的一本书中所说：“如果你有好的思想，那它也是我们的。” ）；

独立于特定的开发语言和开发过程。

4、UML应用：
需求分析

用例图—功能的需求；
类图—静态结构；
状态图、顺序图和协作图等—类之间所需的协作，实现用例。

设计

定义软件系统中的技术细节用到的类，如引入处理用户交互的类、处理数据的类、处理通信和并行性的类等。

实现

组件图—代码组件的物理结构以及组件之间的关系；
部署图—硬件的拓扑结构和组件的分布。

测试

类图—单元测试；
组件图、协作图—集成测试；
用例图 —确认测试

概要设计

1、软件设计：

需求分析：软件系统必须“做什么”
软件设计：“如何做”才可以满足需求规格说明中规定的各项需求。

2、从工程管理的角度来看，软件设计通常分为两步，即 概要设计 和 详细设计。

3、概要设计的基本目的 是回答 “概括地说，软件系统应如实现” 这一问题。
因此，概要设计有时称为 初步设计 或 总体设计 。

概要设计的 主要任务 是确定 软件的总体结构 ，即确定软件系统的组成成份（子系统或模块）以及各组成成份之间的相互关系。

方法：结构化方法、面向对象方法。

详细设计 是对概要设计结果的进一步细化，其 主要任务 是 确定软件系统各组成成份内部的数据结构和算法过程 。

4、抽象与求精：
抽象，即过程抽象、数据抽象和控制抽象。

抽象使得设计人员能够避开过早地陷入细节之中刻画过程和数据。
求精能够帮助设计人员随着设计过程的深入而不断呈现更低层次的信息。

5、模块化和信息隐藏：
软件应该分解成可单独命名的且可访问的部件，这些部件称为模块。
由Parnas倡导的“信息隐藏”是指 模块中所包含的信息（包括数据和过程）对不需要这些信息的其它模块是不可访问的。

抽象有助于定义组成软件的 过程（或信息）实体；
隐藏定义并加强了对 模块内部访问的约束，有助于分离模块的实现者和使用者。

6、模块独立性：
模块独立性是 模块化 、抽象和 信息隐藏 的直接产物。
模块的功能独立性 可以使得模块既 容易开发又容易维护 。

模块独立性有两个定性的度量标准： 内聚度 和 耦合度 。

7、内聚度：模块内部各成分联系紧密的程度。
内聚度越高，模块的独立性就越强。
内聚程度 从高到低 的顺序是：

功能内聚
信息内聚
通信内聚（数据相关—数据或标记耦合）
过程内聚（程序流程图；过程相关—控制耦合）
时间内聚（初始化模块）
逻辑内聚 和 偶然内聚

设计模块时，应该尽可能避免使用 偶然内聚 等 低级内聚 的模块，争取高级内聚的模块，以提高模块的独立性。

8、耦合度：
模块之间相互关联紧密的程度。
模块的耦合度越低，模块的独立性越强。
耦合程度 从低到高 也可分为七种：

非直接耦合
数据耦合
标记耦合
控制耦合
外部耦合
公共耦合
内容耦合

在设计模块时，应该尽量使用 数据耦合，必要时使用 标记耦合，少用 控制耦合，限制使用 公共耦合，最好不要使用 内容耦合。

结构化设计方法

面向数据流图的软件结构设计

面向数据流图的设计方法是一种 结构化设计方法。

过程：

首先，研究、分析和审查数据流图，确保数据流图符合实际，必要时还要进一步精化数据流图；
然后，确定数据流图的类型，即 变换型数据流或事务型数据流；
再依据数据流图的类型采用 变换分析法 或 事务分析法 导出系统初始的软件结构；
最后，依据软件设计原理和一些优化策略改进系统初始的软件结构，形成最终的软件结构。

1、在结构化设计方法中，软件结构是 软件系统模块层次结构，反映了整个 系统功能及其之间 的关系。

软件结构图的主要内容有：模块、模块间的调用关系 和 模块之间传递的信息。

2、模块：
在软件系统的软件结构图中，有6种类型的模块：

传入模块 、传出模块 、变换模块 、协调模块 、源模块 和 漏模块。

在软件结构图中，模块用方框来表示，并用 名字标识 该方框。

3、调用关系：
在软件结构图中，模块间的调用关系主要有三种：

顺序调用 、选择调用 和 循环调用。

方框之间的箭头表示模块之间的 调用与被调用 关系。
模块间调用的次序，习惯上是从左至右。

4、数据或控制信息：
在软件结构中，模块传递的信息用带 名称的短线箭头 来表示。

箭头方向代表信息传递的方向。若箭头线尾是带 空心圆圈，则表示该箭头线代表的是数据；
若箭头线尾是带 实心圆圈，则表示该箭头线代表的是控制。

5、数据流变换分析法：
一种将 变换型数据流图 映射为 变换型软件结构图 的软件系统设计方法。（P101）

6、数据流事务分析法：
是将 事务型数据流图 映射为 事务型软件结构图 的软件系统设计方法。（P103）

7、软件结构图的改进：

模块大小适中、模块扇入扇出合理、模块的作用域应在控制域内。

模块的扇出 是指模块直接调用多少其它模块。
模块的扇入 是指共有多个模块直接调用本模块。

良好的软件结构图，上层模快（主要是控制模块）往往具有较高的扇出，底层的模块（主要是功能型模块）具有较高的扇入，呈 两头小、中间大 的清真寺状。

模块的作用域 是指模块中判定的作用范围，它是指所有受这个判定影响的模块。
模块的控制域 是指模块本身及其直接或间接调用的模块。

如果模块的作用域不在控制域之内，则会增加模块间数据的传递量，使模块之间出现 控制耦合 。

面向IDEF0图的软件结构设计

8、面向IDEF0图的软件结构设计是一种 结构化设计方法，它以系统的 功能模型和信息结构（数据） 为基础设计系统的软件结构。

9、概要设计时，一般可按照IDEF0图的分解层次，逐层将其转换成软件结构。

面向对象设计模式

1、对象建模：

主要任务是了解某个特定应用问题域内所涉及的对象，以及各种各样的结构和通信关系。
介绍Coad/Yourdon 面向对象分析方法来进行对象建模，在表示符号上采用UML建模语言提供的标记法。

2、确定对象&类的方法 ：三视图模型法（实体一关系模型、数据流模型、状态—迁移模型）。

3、面向对象设计是在 对象建模 的基础进行逐渐扩充的过程。
在对象建模中，是以 问题域 为中心，而面向对象设计要在软件系统环境，即 解空间，解决对象建模中要完成的事情。

对象建模是以问题域为中心确定“做什么”，面向对象设计则以软件系统实现环境为中心确定“如何做”。

4、面向对象设计主要设计内容：

问题域部分设计 、人机交互部分设计 、任务管理部分设计 、数据管理部分设计 、系统交互部件的设计 。（P110）

5、面向对象设计模式是 普通面向对象设计问题 的解决方案，这类问题以一组 交互类 的形式出现，用户根据需要定制这些交互类以形成专门的设计。

作用：设计模式不仅使人们可以更加 方便地复用 成功设计方案，提高软件的灵活性和可复用性，也能提高已有系统的文档管理和系统维护的有效性。

6、创建型模式：
创建型模式帮助系统独立于 对象的产生 、组合和表示。

作用：一方面均将关于系统使用哪些具体的类的信息封装起来；另一方面隐蔽了这些具体类的实例是如何被创建和放在一起的。

因此，创建型模式在“什么”被创建、“怎样”被创建、“谁”创建它以及“何时”创建等方面带来了很大的灵活性，有利于设计可复用的软件成分。

主要有两种：工厂方法模式 、抽象工厂模式。
结构型模式：结构型模式涉及如何组合类和对象构成更大的结构。

一种方法是采用 继承机制 来组合接口或实现来形成更大的结构；
另一种方法通过 对象组合方式 对一些对象进行组合来形成。

由于对象组合可以在运行时刻改变，而继承机制为静态类组合，因而对象组合方式具有更大的灵活性。

主要有两种：适配器模式、组合模式。

行为型模式：行为型模式不仅描述 对象或类 的模式，还描述它们之间的 通信模式 。这些模式刻划了在运行时难以跟踪的复杂的控制流。行为型模式使设计者的注意力从 控制流 转移到 对象间 的联系方式上。

主要有两种：迭代器模式、观察者模式。

7、MVC框架中类的交互：

当用户进行一些输入动作后，控制器接收用户事件，并根据事件的类型来改变模型；
视图事先会在模型中登记，当模型数据发生改变时，马上通知已向此模型登记的每个视图，视图从模型中取得最新的数据并刷新自己。

概要设计文档

1、概要设计说明 包括软件系统的基本处理流程、软件结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等。

概要设计说明为软件的详细设计提供了基础，也是 系统集成测试 的主要依据。

2、概要设计文档复审：

目的：较早期地发现设计中存在的错误和缺陷。
参与者：除开发人员外，必须要有用户代表参加，必要时还应邀请有关领域的专家参加。
内容：重点在软件系统的总体结构、模块划分、内外接口以及人机界面上。
方式：正式复审和非正式复审。

小结

① 概要设计 是由 软件结构设计 、内外接口设计 、数据逻辑结构设计 和 用户界面设计 等活动组成，是将用户需求转化为计算机可实现的系统的一个重要步骤。
② 面向 数据流图 的设计方法和面向 IDEF0图 的设计方法是两种常用的结构化设计方法，其特点是 自顶向下，逐层细化 。
③ Coad/Yourdon方法 在面向对象设计方法中比较系统的一种方法，其四个部分的设计实际是对面向对象分析模型在五个层次上扩充，扩充的内容实质也就是 用户界面设计 、内外接口设计 、数据逻辑结构设计 等方面的内容。

详细设计

1、详细设计的目标与任务：
概要设计确定了软件系统的 总体结构，详细设计则对概要设计结果进一步细化，给出目标系统的精确描述，以便在编码阶段直接翻译成计算机上能够运行的程序代码。

（主要任务：确定软件系统各组成成份内部数据结构和算法过程）

详细设计的任务：

算法过程的设计
数据结构的设计
数据库物理设计
信息编码设计
测试用例的设计
编写“详细设计说明书”

2、详细设计图形描述工具：
详细设计中用于过程设计的图形工具，包括程序流程图、盒图、问题分析图和协作图。

3、Jackson程序设计方法 是一种 面向数据结构 的结构化程序设计方法。通过分析问题的输入、输出数据结构（用Jackson图表示）的对应关系，按一定的映射规则将其映射成软件的过程描述，用Jackson伪代码表示。（P134）

4、Warnier程序设计方法：LCP（逻辑构造程序）程序设计方法。

5、程序规格说明文档及复审：又称详细设计说明，与概要设计说明相比，程序规格说明着重描述 模块的细节，包括算法过程和数据结构 。
如果软件系统比较简单，则可将程序规格说明并入概要设计说明中。
程序规格说明的复审 类似于概要设计说明的复审，但重点在于各个模块的 具体设计 上。

小结

详细设计是 进行逻辑系统开发 的最后一个阶段，其质量的好坏将直接影响到 系统的编码实现 。
合理选择和正确使用有关工具、深入理解和掌握有关设计思想和方法，对搞好详细设计是非常重要的。
结构化程序的详细设计与面向对象程序的详细设计有许多共性。

软件测试

1、软件验证：是通过检查和提供客观证据表明软件已经满足规定的需求，是确保软件质量和降低软件成本的重要手段，涉及软件的整个生存周期。
进行软件验证的方式大体有两种：测试和证明 。
测试又分 静态测试 和 动态测试 两种。

静态测试 又称评审，是对软件进行的一种分析和检查活动。
动态测试 是通过运行软件来检验其动态行为和运行结果的正确性。

证明是一种通过形式化的数学方法来确保软件正确性的活动。

2、软件测试：
软件测试是在软件投入运行前，对软件需求分析、设计规格说明和编码的复审，是为了 发现错误，通过检查和提供客观证据 表明软件已经满足规定的需求 。
软件测试 是 确保软件质量 和 降低软件成本 的重要手段，涉及软件的 整个生存周期。

软件测试 就是试图以 最少的代价 发现软件分析、设计和编码 中存在的各种不同类型的错误，从而 提高软件质量，降低软件成本 。

一般的软件开发组织要将 30%~40% 的项目精力投入到测试之中，一些人命悠关的软件（如航空器的飞行控制软件）其测试费用往往更高。

3、软件测试对象：软件生存周期各阶段文档和代码。

4、测试与调试：
测试是查找错误症状的过程，调试则是查找错误症状原因并改正错误的过程。
针对测试中发现的错误进行改正，这便是调试的工作。测试和调试往往交替进行。

5、软件测试的根本任务 就是 发现软件中存在的错误。
由于软件错误往往出现在软件的分析和设计中，而且错误发现越晚，改正错误的工作量也越大，因而在**开发前期利用静态测试非常重要，而且发现错误的效率也往往比较高。

6、测试只能说明软件中存在错误，不能表明程序没有错误，因而任何软件经过测试后不能保证软件中不再存在错误。

白盒测试

白盒测试 是一种 以程序的内部逻辑结构为依据 设计测试用例的方法，因而又称 结构测试或玻璃盒测试。
合理的白盒测试就是要选取足够的测试用例，对源代码实行比较充分的覆盖，以便尽可能多地发现程序中的错误。（原因：穷举测试不合理）。
主要有两种方法：一种称为 逻辑覆盖法，另一种称为 路径覆盖法 。除此外，对循环的测试，可采用 循环覆盖法 。

① 逻辑覆盖：
　　语句覆盖，测试用例能使被测程序的每条执行语句至少执行一次
　　判定覆盖：测试用例能使被测程序中的每个判定至少取得一次“真”和一次“假”。又称分支覆盖
　　条件覆盖：测试用例能使被测程序中每个判定的每个条件至少取得一次“真”和一次“假”。如果判定中只有一个条件，则条件覆盖便满足判定覆盖，否则，不一定。
　　判定/条件覆盖：测试用例既满足判定覆盖，又满足条件覆盖
　　条件组合覆盖：测试用例使每个判定中所有可能的条件取值组合至少执行一次。
　　其中 语句覆盖 最弱。
② 基本路径覆盖法：是在程序图的基础上，通过分析环形复杂性，导出基本路径集，然后设计测试用例使基本路径集中的每条路径至少经过一次。
　　独立路径：包含一组以前从未被处理的语句或条件的一条路径。
③ 循环覆盖法： 逻辑覆盖法和基本路径覆盖法对于循环只进行了循环一次的测试，显然是不充分的。 而循环是大多数软件实现算法的关键部分，因此对循环的测试是十分重要的。对于结构化程序而言，循环主要有三种： 简单循环 、嵌套循环 和 串接循环。

黑盒测试

黑盒测试 ：又称 功能测试 、数据驱动测试 等，它将待测试对象看成是一个黑盒子，不考虑程序内部的逻辑结构和特性，只依据 规格说明书 检查程序的功能是否能正常使用。

通常，白盒测试用于测试的早期，而黑盒测试由于不需了解程序内部情况，因而被许多 后期测试（如确认测试、系统测试）采用。

测试用例设计方法：用黑盒测试发现程序中的错误，主要根据 输入条件 和 输出条件 确定测试数据，来检查程序是否能产生正确的输出。
进行黑盒测试，主要有下述几种方法：等价分类法 、边界值分析法 、猜错法 、因果图法 。
等价分类法 和 边界值分析法 通过选择有代表性的测试数据来暴露程序错误。但不同类型不同特点的程序通常又有一些特殊的容易出错的情况。并且，有时分别使用某些测试用例测试时程序工作正常，但其组合可能会使程序出错；
猜错法 是根据经验和直觉设计测试用例，尽管能考虑到输入组合的情况，但显得不充分；
因果图法 借助图形来设计测试用例，特别适用于被测程序具有多种输入条件，程序的输出又依赖于输入条件的各种组合的情况。

黑盒法综合策略：

首先用边界值分析法设计测试用例
必要时用等价分类法补充测试用例
必要时再用猜错法补充测试用例
如果在程序的说明中含有输入条件的组合，宜在一开始末就采用因果法，然后再按上述步骤进行。

动态测试

动态测试：通过运行软件来检验其动态行为与运行结果的正确性。
（1）单元测试：又称 模块测试或分调，是动态测试中的第一步，通常在 编码阶段 进行。单元测试集中检查软件设计的 最小单元——模块 ，即程序中最小的独立编译单位。

单元测试 一般总是把 白盒法和黑盒法 结合运用。先用黑盒法设计出一组基本的测试用例，然后用白盒法，根据覆盖标准要求补充新的测试用例满足覆盖标准。在一般情况下，单元测试应以白盒法为主 。

单元测试在于考察 模块的接口和内部结构 ，检查是否符合程序规格说明（即详细设计说明书）的要求。

单元测试的重点在以下几个方面：

模块的接口
局部数据结构
重要的执行通路
出错处理路径
影响以上各项的边界条件。

测试软件：一般地，驱动模块 应完成接收测试数据，并把数据传给被测模块，然后打印有关结果等任务；桩模块 应该模拟实际模块完成少量数据处理，并检验和打印入口处的信息，然后将控制返回给被测模块。

面向对象单元测试：最小的可测试单元是类，包含一组不同操作。对面向对象软件的类测试等价于结构化软件的 单元测试。类测试方法：基于故障的测试、随机测试和划分测试。

（2）集成测试：集成测试，又称组装测试、综合测试或联调，是在单元测试完成之后，将所有模块按概要设计要求组装成系统的时候进行的测试。

主要目标 是发现与接口有关的问题。主要检查 模块接口 和 全局数据 。

集成测试有组装和检验 两重意义，一方面将各经过单元测试的模块拼装起来形成完整可运行的系统；另一方面要检验每一步拼装过程是否正确。

测试策略：集成测试一般应由 独立的测试小组 进行，由测试小组提出测试用例，记录测试结果，并编制测试报告。

测试用例的设计 通常采用 黑盒法，其实施策略又分为 非渐增式和渐增式两种 。
非渐增式测试：采用非渐增式测试，一般应先经过单元测试，然后再把所有模块一次性组装在一起进行测试，最终得到要求的软件系统。

将模块一次性组装在一起运行成功的可能性并不大。其结果往往是发现有错误，但由于程序中模块一次性引入过多，难于进行错误定位。同时，一旦修正错误之后，新的错误很可能马上会出现。

除规模很小的程序，一般很少采用此种测试策略。

渐增式测试：渐增式测试采用逐步加入 模块或功能簇 的方式进行，在加入过程中边连接边测试，比较容易定位和修正错误，且接口也可以更容易进行彻底地测试。
按照 添加模块 的方式，又可分为 自顶向下 的渐增测试和 自底向上 渐增测试。

自顶向下的渐增式测试：首先集成 主控模块，然后按照 软件结构 的控制层次 自上而下 进行集成，把主控模块的直接（或间接）调用模块按 深度优先 或 广度优先 的方式集成到整个软件结构中。

特点：

① 能较早地显示整个程序的轮廓，对增强开发人员的信心，取得用户的支持，有重要的作用；
② 只需编写桩模块供测试用，驱动模块可以利用实际模块；
③ 能尽早发现主要控制中的问题，减少以后的返工；
④ 可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误，为其后对主加工分支的组装和测试提供了保证；
⑤ 由于每添加一个新模块，就进行一次测试，这样虽然耗费一些时间，但却使被测程序测试更彻底，尤其是上层模块。

自底向上的渐增式测试：
A 、把低层模块组合成实现某个特定的子功能的模块簇，并用编写的驱动模块控制它进行测试；可以对若干功能簇并行进行测试；
B 、用实际模块换掉驱动模块，沿软件结构自下而上移动，把子功能簇组合起来形成更大的子功能簇，并进行测试；
C 、重复步骤B 直到所有模块组装完毕。

特点：

① 不能在测试的早期显示出程序的轮廓。程序的总体结构，要等到加入最后一个模块时才能最终形成；
② 测试软件只需要驱动模块，不需要桩模块，而且随着组装层次的上移，驱动模块将大为减少（在多数情况下，编写驱动模块要比桩模块容易）；
③ 由于从低层模块开始组合，所以较易产生测试用例。

在模块组装起来后，新的数据流路径建立起来了，新的控制逻辑可能激活了等等。这些改变可能会使原本工作正常的功能产生错误，因此，应对某些已经进行过的测试的测试用例再重新执行一遍，以保证上述改变不会传播意外的副作用，称之为 回归测试 。

（3）确认测试：就是验证所开发软件的 功能和性能 及其他特性是否符合 软件需求规格说明书 的要求。所以，确认测试 又称之为 有效性测试 。

内容：

功能测试
性能测试
强度测试
配置复审

确认测试是由软件开发单位组织进行的最后一次测试，也是把软件交给用户，进行正式的安装和验收之前所作的一次重要的准备。
为了确保测试质量，一方面应组织 独立的测试小组 进行测试，另一方面吸收任务委托单位及用户代表参加测试，以提高测试的可信度。
同时，应将测试中发现的错误填入问题清单，交开发者处理。

（4）系统测试：是在 更大范围内 进行的测试，它将经过确认测试的软件作为整个基于计算机的系统的一个元素，与计算机硬件、外设、支持软件、数据和人员等其他系统元素结合在一起，在 实际运行环境 下，对系统进行的一系列集成和确认测试 。
系统测试通常由任务委托单位或用户组织的 验收小组 负责，一般应根据 需求分析说明书 来设计测试用例，在实际使用环境中运行。

系统测试的内容对不同的系统各不相同。

软件维护

1、所谓 软件维护 是指软件交付使用之后，为了 改正错误 或 满足新的需求 等而修改软件以达到 延长软件寿命 为目的的过程。
软件维护阶段的长短决定了软件寿命的长短；
软件维护阶段的费用占软件总成本的大部分。

2、软件维护不同于硬件维护，主要原因 是软件维护不是因为使用时软件磨损或老化引起，而是由于软件设计不正确、不完善或使用环境的变化等引起。

3、软件维护类型：

改正性维护，识别和纠正软件错误，改正性能上的缺陷，排除实施中的误使用而进行的诊断和改正错误的活动。约占整个维护的20%
适应性维护，使软件适应处理环境或数据要求的变化而修改软件的活动。约占整个维护的25%
完善性维护，修改或再开发软件，以扩充软件功能，增强软件性能等。约占整个维护的50%
预防性维护或再工程，采用先进的软件工程方法对需要维护的软件或软件的某一部分（重新）进行设计、编码和测试。连同其它维护约占整个维护的5%。

4、软件维护成本：软件维护活动所花费的工作量占软件整个生存期工作量的 70%以上 。

影响软件维护工作量的因素有很多，就软件系本身而言，有以下几个主要方面：

系统的大小；程序设计语言；系统年龄；数据库技术的应用；软件开发新技术的运用。

5、软件维护相关的模型：Boehm模型；Belady与Lehman模型。

6、软件维护过程本质 上是 修改和压缩了的软件定义和软件开发 过程。

7、软件可维护性 是指纠正软件系统中出现的错误或缺陷，以及为满足新的要求进行 修改、扩充和压缩软件 的容易程度。

软件可维护性的7个度量指标：

可理解性，可测试性，可修改性，可靠性，可移植性，可使用性及效率。

8、影响软件可维护性的软件属性：

可理解性，表现为人们通过阅读源代码和相关文档，理解软件的结构、接口、功能和内部过程的容易程度；
可测试性，一个软件容易被测试的程度；
可修改性，程序容易修改的程度。

9、软件再工程技术：是一类软件工程活动，通过对旧软件(遗留系统)实施处理，以增进对软件的理解，同时又提高了软件自身的可维护性、可复用性等。
逆向工程：软件逆向工程，通过对程序的分析，导出更高抽象层次的表示，如从现存的程序中抽取数据、体系结构、过程的设计信息等，是一个设计恢复过程。
软件重构 是对源代码和/或数据进行修改，使其易于理解或维护，以适应将来的变更。
软件重构要求关注模块细节 。
正向工程 也称为改造，用从现存软件恢复设计中得到的信息去重构现存系统，以改善其整体质量。

10、软件维护的副作用：因修改软件而造成的错误（编码副作用 、数据副作用 、文档副作用）

小结

软件工程学 的一个主要目的便是提高软件的可维护性，降低软件维护的代价
软件维护 是软件生存周期的最后一个阶段，也是成本最高的阶段
软件维护 大多要涉及到软件设计内容的修改，从而要重视软件维护的副作用，对软件维护要有正式的组织，制定规范化的过程，实行严格的维护评价。

软件质量

1、软件质量度量的两个方面：软件复杂性分析 、软件可靠性分析 。

2、软件质量控制：ISO9000认证 、软件配置管理 SCM 、CMM 。

3、评价软件质量可从三个方面进行，即产品或中间产品、过程（即软件生产所需的资源和活动）和项目。

4、复杂性度量方法：McCabe 环形计数法

程序环形复杂度 $V(G)$
　　　　　　　　　　= 程序流程图中的 “判定数” $+1$
　　　　　　　　　　= 程序图中的“环形数”。
　　　　　　　　　　$=m-n+2$

其中 $m$ 对应于程序图中的弧数，$n$ 对应于程序图中的节点数

5、软件可靠性：软件在给定的时间间隔及规定的使用环境条件下，按分析和设计规定的要求成功地运行程序的概率；
是与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性。

软件可靠性三要素：

失效，是指最后执行结果与有关规格不相符或用户在软件系统边界觉察到不期望的软件出错行为
时间，即软件失效的时间
环境，软件运行时所需要的支持系统及有关的因素。

软件可靠性 、硬件可靠性 和 操作可靠性三者综合起来反映整个计算机系统的可靠性。

软件可靠性测试：

① Gilb 植错模型
假设：
　　$N$ 表示软件中原有残留的错误数；
　　$S$ 表示植入软件中的错误数；
　　$n$ 表示测试中发现的原有错误数；
　　$s$ 表示测试中发现的植入错误数。
则： $N=(\frac{n}{s})\bullet S$

② Hyman分别测试模型
假定：
　　$B_0$ 表示软件中原有的残留错误数；
　　$B_1$ 表示甲测试员在某一时间内发现的错误数；
　　$B_2$ 表示乙测试员在同一时间内发现的错误数；
　　$B_c$ 表示甲乙两人发现的相同错误数。
则：$B_0=\frac{(B_1 \bullet B_2)}{B_c}.$