软件工程导论概念

第1章 软件工程学概述

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

软件危机的典型表现：

1. 对软件开发成本和进度的估计常常很不准确；

2. 用户对完成的软件系统不满意的现象经常发生；

3. 软件产品的质量往往靠不住；

4. 软件常常是不可维护的；

5. 软件通常没有适当的文档资料；

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

7. 软件开发生产率提高的速度跟不上计算机应用的发展趋势。

产生软件危机的原因

1. 软件本身特点造成；对于计算机系统来说，软件是逻辑部件，软件开发过程没有统一的、公认的方法论和规范指导，造成软件维护困难。

2. 软件开发与维护的方法不正确。对软件产品缺乏正确认识，没有真正理解软件产品是一个完整的配置组成。造成开发中制定计划盲目、编程草率，不考虑维护工作的必要性。

主要表现：

1. 忽视软件需求分析；

2. 认为软件开发就是写程序并使之运行；

3. 轻视软件维护；

解决软件危机的途径

1. 推广使用在实践中总结出来的开发软件的成功技术和方法，并研究探索更有效的技术和方法；

2. 开发和使用更好的软件工具；

3. 良好的组织管理措施。

软件工程的介绍

早期：软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。

1993年IEEE：软件工程是

1. 把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程；
2. 研究（1）中提到的途径。

软件工程的本质特性：

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

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

3. 软件经常变化；

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

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

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

7. 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品。

软件工程的基本原理

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

2. 坚持进行阶段评审；

3. 实行严格的产品控制；

4. 采用现代程序设计技术；

5. 结果能清楚地审查；

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

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

软件工程方法学

概念：通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学（Methodology），也称为范型（Paradigm）。

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

1. 传统方法学

也称为生命周期方法学或结构化范型。

结构化方法（Structure Method）有：

1. 结构化设计方法（SD）；

2. 结构化分析方法（SA）；

3. 结构化分析与设计技术（SADT）

4. JACKSON方法

5. WARNIER方法

2. 面向对象方法学

把数据和对数据的操作紧密结合起来的方法，模拟人类认识世界解决问题的方法和过程。

面向对象的方法=对象（属性与服务的封装）+分类+继承+用消息通信

软件生命周期

指软件从提出到最终被淘汰的这个存在期。

1. 软件定义；

​ A.问题定义 B.可行性研究 C.需求分析

2. 软件开发；

​ D.总体设计 E.详细设计

​ F.编码和单元测试 G.综合测试

3. 运行维护。

软件生命周期各个阶段：

1.问题定义；

2.可行性研究；

3.需求分析；

4.总体设计（概要设计）；

5.详细设计；

6.编码与单元测试；

7.综合测试；

8.维护。

问题定义报告的内容包括：

1. 软件项目标题；

2. 软件目标；

3. 软件用户对象；

4. 软件规模。

软件过程

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

使用资源将输入转化为输出的活动所构成的系统。

瀑布模型:

1. 阶段间具有顺序性和依赖性

2. 推迟实现的观点

3. 质量保证的观点

优点：采用规范的方法；严格规定每个阶段提交的文档；要求每个阶段交出的产品必须经过验证。

快速原型模型:

优点：不带反馈环，基本上是线性顺序进行。

增量模型:

优点：能较短时间内提交可完成部分工作的产品；可以使用户有充裕的时间学习和适应新产品。

第2章 可行性研究

可行性研究的目的是：用最小的代价在尽可能短的时间内确定问题是否有解，以及是否值得去解。

可行性研究的内容：

1. 技术可行性:使用现有的技术能否实现这个系统

2. 经济可行性:系统的经济效益能否超过它的开发成本

3. 操作可行性:操作可行性评价系统运行后会引起的各方面变化

4. 社会可行性

可行性研究的步骤

1. 复查系统规模和目标；

2. 研究目前正在使用的系统；

3. 导出新系统的高层逻辑模型（数据流图、数据字典）；

4. 重新定义问题；

5. 导出和评价供选择的解法（物理解决方案）；

6. 推荐行动方案；

7. 草拟开发计划；

8. 书写文档提交审查。

数据字典

数据字典：对数据流图中包含的所有元素的定义的集合；

可行性研究阶段，数据流图与数据字典共同构成系统的逻辑模型。

数据字典应该对下列元素进行定义：

1. 数据流；

2. 数据元素（数据流分量）；

3. 数据存储；

4. 处理。

成本估计

1. 代码行技术:软件成本 = 每行代码的平均成本×估计的源代码总行数

2. 任务分解技术

3. 自动估计成本技术

第3章 需求分析

需求分析的任务

确定对系统的综合要求

1. 功能需求

2. 性能需求

3. 可靠性和可用性需求

4. 出错处理需求

5. 接口需求

6. 约束

7. 逆向需求

8. 将来可能提出的要求

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

访谈:

1. 正式访谈：系统分析员提出事先准备好的问题。

2. 非正式访谈：提出一些用户可以自由回答的开放性问题，鼓励被访者说出自己的想法。

面向数据流自顶向下求精

简易的应用规格说明技术

快速建立软件原型

分析建模与规格说明

分析建模

1. 实体联系图
2. 数据流图
3. 状态转换图

数据规范化

1. 第一范式
2. 第二范式
3. 第三范式

第5章 总体设计

设计过程

1. 设想供选择的方案

2. 选择合理的方案

​ 对每个合理的方案要提供：

  A．系统流程图
  
  B．组成系统的物理元素清单
  
   C．成本/效益分析
  
  D．实现这个系统的进度计划

3. 推荐最佳方案

4. 功能分解

5. 设计软件结构

6. 数据库设计

7. 制定测试计划

8. 书写文档

   A．系统说明

   B. 用户手册

   C．测试计划

   D．详细的实现计划

​ E．数据库设计结果

9. 审查和复审

设计原理

模块化

抽象

逐步求精

信息隐蔽和局部化

模块独立：

模块的独立性很重要，因为：

1. 有效的模块化的软件比较容易开发出来;

2. 独立的模块比较容易测试和维护。

模块独立程度可以由两个定性标准度量：耦合与内聚。

耦合

耦合：指软件结构内不同模块彼此之间相互依赖（连接）的紧密程度。

模块的偶合分四类：

1. 数据耦合

​ 两个模块之间只是通过参数交换信息，而且交换的信息仅仅是数据。

 数据耦合是**最低程度**的耦合。 

2. 控制耦合

​ 两个模块之间所交换的信息包含控制信息。

 控制耦合是中等程度的耦合。

3. 公用耦合

​ 两个或多个模块通过一个公共区相互作用时的耦合。

​ 公共区可以是：全程数据区、共享通信区、内存公共覆盖区、任何介质上的文件、物理设备等。

​ 软件结构中存在大量的公用耦合时会给诊断错误带来困难。

4. 内容耦合

​ 一个模块与另一个模块的内容直接发生联系。

​ 内容耦合对维护会带来严重的困难。

​ 内容耦合是最高程度的耦合，应该避免采用。

应追求尽可能松散耦合，这样模块间的联系就越小，模块的独立性就越强，对模块的测试、维护就越容易。

尽量使用数据耦合，少用控制耦合，限制公用耦合，完全不用内容偶合。

内聚

内聚：一个模块内部各个元素彼此结合的紧密程度。

1. 功能内聚 ：功能内聚是最高程度的内聚。

2. 顺序内聚

   高内聚

   ---

3. 通信内聚

4. 过程内聚

   中内聚

   ---

5. 时间内聚

6. 逻辑内聚

7. 偶然内聚：偶然内聚是最差的一种内聚。

   地内聚

力求做到高内聚，尽量少用中内聚，不用低内聚。

启发式规则

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

2. 模块规模应该适中

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

   深度：软件结构中控制的层数；

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

   扇出：一个模块直接控制（调用）其它模块的数目；

   扇入：一个模块被其它模块调用的数目

4. 模块的作用域应该在控制域之内

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

​ 控制域：模块本身以及所有从属于它的模块的集合

5. 力争降低模块接口的复杂度

6. 设计单入口、单出口的模块

7. 模块功能应该可以预测

面向数据流的设计方法

数据流可以分为两种类型：

1. 变换型数据流
2. 事务型数据流

第6章 详细设计

目标：确定如何具体实现所要求的系统。

结构程序设计

结构程序设计： 一种设计程序的技术，它采用自顶向下逐步求精的设计方法和单入口单出口的控制结构。 一种设计程序的技术，它采用自顶向下逐步求精的设计方法和单入口单出口的控制结构。

使用结构程序设计技术的好处：

1. 提高软件开发工程的成功率和生产率；

2. 系统有清晰的层次结构，容易阅读理解；

3. 单入口单出口的控制结构，容易诊断纠正；

4. 模块化可以使得软件可以重用；

5. 程序逻辑结构清晰，有利于程序正确性证明。

经典的结构程序设计：只允许使用顺序、IF_THEN_ELSE选择和DO_WHILE循环；

扩展的结构程序设计：除了三种基本控制结构，还使用DO_CASE和DO_UNTIL循环；

修正的结构程序设计：除了三种基本控制结构和两种扩充结构，还使用BREAK等结构。

人机界面设计

设计问题

1. 系统响应时间；

2. 用户帮助；

3. 出错信息处理；

4. 命令交互

人机界面设计指南

1. 一般交互指南；

2. 信息显示指南；

3. 数据输入指南

过程设计的工具

程序流程图

程序流程图的缺点：

1. 程序流程图本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构。

2. 程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制。

3. 程序流程图不易表示数据结构。

盒图（N-S图）

PAD图

判定表

判定树

过程设计语言

面向数据结构的设计方法

Jackson图

改进的Jackson图

程序复杂度的定量度量

McCabe方法:

1. 流图:仅描绘程序的控制流程

2. 计算环形复杂度的方法

   a.环形复杂度 V（G）等于流图中的区域数；

   b.环形复杂度 V（G）＝E－N+2，其中E是流图中边的条数，N是结点数；

   c.环形复杂度 V（G）＝P＋1，其中P为流图中判定结点的数目。

3. 环形复杂度的用途

   对测试难度的一种定量度量，也能对软件最终的可靠性给出某种预测。

Halstead方法:

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

​ N = N1 + N2

其中：N定义为程序长度；

​ N1为程序中运算符出现的总次数；

​ N2为操作数出现的总次数。

Halstead给出预测程序长度的公式为：

​ H = n1log2n1 + n2log2n2

其中：H定义为程序预测长度；

​ n1为程序中使用的不同运算符（包括关键字）的个数；

​ n2为程序中使用的不同操作数（变量和常量）的个数。

程序的预测长度H和实际程序长度N非常接近。

Halstead还给出了预测程序中包含错误的个数的公式：

​ E = N log2(n1+n2) / 3000

第7章 实现

编码和测试统称为实现。

编码：把软件设计结果翻译成程序。

测试：检测程序并改正错误的过程。

编码

选择程序设计语言

1. 汇编语言;

2. 高级语言。

从应用特点看，高级语言可分为：

1. 基础语言
2. 结构化语言
3. 专用语言

选择一种编程语言的理论标准：

1. 有理想的模块化机制；

2. 可读性好的控制结构和数据结构；

3. 便于调试和提高软件可靠性；

4. 编译程序发现程序错误的能力强；

5. 有良好的独立编译机制。

主要的实用标准：

1. 系统用户要求

2. 可以使用的编译程序

3. 可以得到的软件工具

4. 工程规模

5. 程序员知识

6. 软件可移植性要求

7. 软件的应用领域

编码风格：

1.程序内部的文档

2.数据说明

3.语句构造

4.输入/输出

5.效率

​ A程序运行时间

​ B．存储器效率

​ C．输入/输出效率

软件测试基础

软件测试的目标

有关测试的一些规则：

1. 测试是为了发现程序中的错误而执行程序的过程；

2. 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

3. 成功的测试是发现了至今为止尚未发现的错误的测试。

软件测试准则

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

2. 应该远在测试前就制定出测试计划；

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

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

5. 穷举测试是不可能的；

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

测试方法

黑盒测试：如果已经知道软件应该具有的功能，可以通过测试来检验是否每个功能都能正常使用，这种测试称黑盒测试。也称功能测试。

白盒测试：也称结构测试。如果知道软件内部工作过程，可以通过测试来检验软件内部动作是否按照规格说明书的规定正常进行，这种测试称为白盒测试。

软件测试的步骤

1. 模块测试

2. 子系统测试

3. 系统测试

4. 验收测试

5. 平行运行

单元测试

最小的单元-模块

测试重点

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

代码审查

审查小组：

1. 组长；

2. 程序的设计者；

3. 程序的编写者；

4. 程序的测试者。

计算机测试

1. 驱动程序:相当于一个“主程序”，用来把测试数据传送给被测试的模块，并打印有关结果。

2. 存根程序:用来代替被测试模块所调用的模块，相当于“虚拟子程序”。

集成测试

集成测试是组装软件的系统化技术，它将经过单元测试的模块联系在一起进行测试。

由模块组装成程序时有两种方法：

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

2. 渐增式测试方法:每次增加一个待测试模块，把它同已经测试好的那些模块结合起来进行测试，反复进行直到完成所有模块测试的方法。

使用渐增式测试方法把模块结合到软件系统中去时，有自顶向下和自底向上两种集成方法。

一、自顶向下集成

自顶向下集成是一种递增的装配软件结构的方法，这种方法应用非常广泛。它需要存根程序，但是不需要驱动程序。

这种方法的思想是：从主控模块（主程序）开始，沿软件的控制层次向下移动，逐渐把各个模块结合起来。

在自顶向下结合方法中，如何将所有模块组装到软件结构中，又有两种方法：

1. 深度优先策略

2. 宽度优先策略

二、自底向上集成

自底向上集成方法是从软件结构最底层模块开始进行组装和测试，它与自顶向下结合方法相反，需要驱动程序，不需要存根程序。

改进：

1. 改进的自顶向下测试方法；

2. 混合法。

回归测试

指重新执行已经做过的部分测试。

回归测试用于保证由于调试或其他原因引起的程序变化，不会导致额外错误的测试活动。

---

确认测试

确认测试的范围：

1. 也称为验收测试，目标是验证软件的有效性。
2. 如果软件的功能和性能符合用户的期待，软件就是有效的。
3. 软件规格说明书是进行确认测试的基础。

确认测试的主要特点及内容有：

1. 某些已经测试过的纯粹技术性的测试项可能不需要再次测试，而对用户特别感兴趣的功能或性能，可能需要增加一些测试；

2. 通常确认测试主要使用实际生产中的数据来进行测试；

3. 确认测试必须有用户的积极参与，甚至以用户为主，可能需要进行一些与用户使用步骤有关的测试。

确认测试一般使用黑盒测试法。

软件配置复查:

目的：保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，而且已经编好目录。

Alpha和Beta测试

Alpha测试：用户在开发者的场所进行测试，并且在开发者的指导下进行，测试在受控环境中进行，开发者记录发现的错误和问题；

Beta测试：用户在一个或多个客户场所进行测试，不受开发者控制，测试者记录发现的问题和错误，定期将问题报告发送给开发者。

---

白盒测试技术

逻辑覆盖

1. 语句覆盖:设计的测试用例能使程序中每条语句至少执行一次。

2. 判定覆盖:选取足够的测试用例，使得程序中每个判断的可能结果都至少执行一次，也就是说使程序的每个判断分支至少通过一次。

3. 条件覆盖:选择足够的测试用例，使得程序中每个判定表达式的每个条件都取到各种可能的结果。

4. 判定/条件覆盖:选取足够的测试用例使得同时满足判定覆盖和条件覆盖的要求。

5. 条件组合覆盖:选取足够的测试用例，使得每个判定表达式中条件的各种可能的组合都至少出现一次。

6. 点覆盖:选取足够多的测试用例，使得程序执行路径至少经过程序图中每个节点一次。

7. 边覆盖:选取足够多的测试用例，使得程序执行路径至少经过程序图中每条边一次。

8. 路径覆盖:选取足够多的测试用例，使得程序的每条可能路径都至少执行一次。

---

黑盒测试技术

等价类划分是一种黑盒测试技术。

用等价类划分设计测试用例时，主要分两步：划分等价类、确定测试用例。

边界值分析测试法属黑盒测试。

错误推测法在很大程度上靠直觉和经验进行。

---

调试

调试是在测试发现错误之后排除错误的过程。

调试途径:

1. 蛮干法

2. 回溯法

3. 原因排除法

---

软件可靠性

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

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

可靠性和可用性的区别：可靠性是在0到t时间间隔内，系统没有失效的概率。而可用性是在t时刻，系统是正常运行的概率。

平均维修时间MTTR是修复一个故障平均需要用的时间，取决于维护人员的技术水平和对系统熟悉程度。

平均无故障时间MTTF是系统按照规格说明书规定成功地运行的平均时间，取决于系统中潜伏的错误数量。

估计错误总数ET的方法

1. 植入故障法

2. 分别测试法

---

第8章 维护

软件维护是软件生命周期的最后一个阶段。

任务：维护软件的正常运行，不断改进软件的性能和质量，为软件的进一步推广应用和更新替换做积极工作。

软件交付使用 :

1. 软件验收测试以后，就标志着软件设计开发阶段的结束。
2. 而软件交付用户使用，才真正标志漫长的维护阶段的开始。

软件交付使用的方式

1. 直接方式

​ 优点：转换简单，费用最省。

​ 缺点：风险大

2. 并行方式

​ 优点：

  A. 可以对系统进行全面测试，减少了新系统失灵带来的风险，因为旧系统也仍然存在；
  
  B．用户也能够有一段熟悉新系统的时间。

​ 缺点：

 所需费用较高，双系统要投入更多的人力财力。

3. 逐步方式

软件维护的定义:在软件已经交付使用后，为了改正错误或满足新的需要而进行修改的过程。

软件维护的原因

1. 改正在特定使用条件下暴露出来的一些潜在程序错误或设计缺陷；

2. 因在软件使用过程中数据环境发生变化（如所要处理的数据发生变化）或处理环境发生变化（如硬件或软件操作系统等发生变化），需要修改软件，以适应这种变化；

3. 用户和数据处理人员在使用时常提出改进现有功能、增加新功能、以及改善总体性能的要求，为满足这些要求，需要修改软件。

软件维护的类型

1. 改正性维护

2. 适应性维护

3. 完善性维护

4. 预防性维护

完善性维护占软件维护工作的大部分。

---

软件维护的特点

结构化维护与非结构化维护的差别:

1. 非结构化维护

​ 软件配置的唯一成分是代码，维护从评价程序代码开始，对软件结构、数据结构、系统接口、设计约束等常产生误解，不能进行回归 测试，维护代价大。

2. 结构化维护

   有完整的软件配置，维护从评价设计文档开始，确定软件结构、性能和接口特点，现修改设计，接着修改代码，再进行回归测试。

软件维护的典型问题:

1. 如果维护时只有程序代码而没有注释说明，维护起来就相当困难；

2. 由于软件维护阶段时间长，软件开发人员经常流动，所以在维护时，不可能所有的维护工作都依靠原来的开发人员。这会使得维护工作量增加；

3. 软件没有足够的文档资料，或者程序修改后与文档资料不一致；

4. 绝大多数软件在设计时没有考虑将来的修改，所以建议采用功能独立的模块化设计原则，增加软件的可维护性；

5. 软件维护被许多人视为一种毫无吸引力的工作，因为维护工作常常受到挫折。

---

软件维护过程

1. 维护组织

2. 维护报告

​ 根据软件问题报告（维护要求），作出的软件修改报告包含的信息主要有：

​ 1）满足维护要求表中提出的要求所需要的工作量；

​ 2）维护要求的性质；

​ 3）这项要求的优先次序；

​ 4）与修改有关的事后数据（如测试数据等）。

3. 维护的事件流

4. 保存维护记录

​ 程序标识源语句数；机器指令数；使用的程序设计语言；程序安装的日期；自安装以来程序运行次数；

5. 评价维护活动

​ 1）每次程序运行平均失效的次数；

​ 2）用于每一类维护活动的总人时数；

​ 3）平均每个程序、每种维护类型所做的程序变动数；

​ 4）维护过程中增加或删除一个源语句平均花费的人时数；

​ 5）维护每种语言平均花费的人时数；

​ 6）一张维护要求表的平均周转时间；

​ 7）不同维护类型所占的百分比。

---

软件的可维护性

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

1. 可理解性

2. 可测试性

3. 可修改性

4. 可移植性

5. 可重用性

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

1. 用户文档：主要描述系统功能和使用方法，并不关心这些功能是怎样实现的。

2. 系统文档：描述系统设计、实现和测试等各方法的内容。

3. 用户文档

​ 1）功能描述；

​ 2）安装文档；

​ 3）使用手册；

​ 4）参考手册；

​ 5）操作员指南；

2. 系统文档

可维护性复审

测试结束时进行正式的可维护性复审，称为配置复审，目的是：保证软件配置的所有成分是完整的、一致的和可理解的。

---

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

面向对象方法学概述

面向对象方法的优点:

1. 与人们习惯的思维方法一致；

2. 稳定性好；

3. 可重用性好；

4. 较易开发大型软件产品；

5. 可维护性好。

对象的特点:

1. 以数据为中心；

2. 对象是主动的；

3. 实现了数据封装；

4. 本质上具有并行性；

5. 模块独立性好。

对象是具有相同状态的一组操作的集合。

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

方法，是对象所能执行的操作。

消息就是用来请求对象执行某个处理或回答某些信息的要求。

属性，是类中定义的数据。

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

继承，是指能够直接获得已有的性质和特征，而不必重复定义它们。

多态性，指子类对象可以象父类对象那样使用，同样的消息既可以发送给父类对象，也可以发送给子类对象。

重载：1. 函数重载 2. 运算符重载

---

面向对象建模

1. 对象模型：描述系统的数据结构；

2. 动态模型：描述系统的控制结构；

3. 功能模型：描述系统的功能。

对象模型是最基本、最重要的。

泛化（继承）:

1）普通泛化

---

第11章 面向对象设计

面向对象设计的准则：

1. 模块化：对象就是模块。它把数据结构和操作（方法）紧密地结合在一起构成模块。

2. 抽象：类实际上是一种抽象数据类型

3. 信息隐蔽：信息隐蔽通过对象的封装性实现

4. 弱耦合

​ 对象间的耦合有两大类：a.交互耦合 b.继承偶合

5. 强内聚

6. 可重用

---

启发规则

1. 设计结果应该清晰易懂；

​ 影响的主要因素：1.用词一致；2.使用已有的协议；3.减少消息模式的数目；4.避免模糊的定义。

2.一般—特殊结构的深度应适当

3. 设计简单的类：设计小而简单的类，便于开发和管理；

​ 注意几点：

​ 1.避免包含过多的属性；

​ 2.有明确的定义；

​ 3.尽量简化对象之间的合作关系；

​ 4.不要提供太多服务。

4.使用简单的协议

5.使用简单的服务

6.把设计变动减至最小

---

软件重用

重用的三个层次：

​ 1）知识重用；

​ 2）方法和标准的重用；

​ 3）软件成分的重用。

软件成分的重用级别：

1）代码重用

​ a. 源代码剪贴；

​ b. 源代码包含；

​ c. 继承；

2）设计结果重用

3）分析结果重用

典型的可重用软件成分

1）项目计划； 2）成本计划；

3）体系结构； 4）需求模型和规格说明；

5）设计； 6）源代码；

7）用户文档和技术文档；8）用户界面；

9）数据； 10）测试用例。

---

设计问题域子系统

1. 调整需求

2. 重用已有的类

3. 组合问题域的类

4. 增添基类以定义公共函数集合

5. 调整继承层次

---

设计人机交互子系统

设计人机交互子系统的策略：

1. 分类用户；

2. 描述用户；

3. 设计命令层次；

4. 设计人机交互类。

---

设计数据管理子系统

选择数据存储管理模式

1. 文件管理系统

2. 关系数据库管理系统

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

---

面向对象语言的优点：

1. 一致的表示方法
2. 可重用性
3. 可维护性

选择面向对象语言时应考虑的技术特点：

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

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

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

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

5. 类型检查

6. 类库

7. 效率

8. 持久保存对象

9. 参数化类

10. 开发环境

选择面向对象语言应考虑的因素：

1. 将来能否占主导地位

2. 可重用性

3. 类库和开发环境

4. 其他因素

---

程序设计风格

1. 提高可重用性
2. 提高可扩充性
3. 提高健壮性

---

面向对象的集成测试：

两种不同的测试策略：

1. 基于线程的测试:将响应系统的一个输入或一个事件所需要的哪些类集成起来测试。

2. 基于使用的测试先测试独立类，再测试使用独立类的下一层次的类（依赖类），重复直至完毕。

测试类的方法:

1. 随机测试

2. 划分测试

3. 基于故障的测试

集成测试方法:

1. 多类测试

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