软 件 工 程 笔 记

第一章

² 一个软件产品必须由一个完整的配置组成，软件配置主要包括：程序，数据及相关文档。程序是能够完成预定功能和性能的可执行的指令序列；数据是使程序能够适当的处理信息的数据结构；文档是开发使用和维护程序所需要的图文资料。

² 软件危机的定义：软件危机是指在计算机软件开发、使用、维护过程中遇到的一系列严重问题和难题。它包括两方面：1.如何开发软件以满足对软件日益增长的要求 2.如何维护数量不断膨胀的已有软件

² 软件危机的具体表现：1. 对软件开发成本和进度的估计往往很不准确

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

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

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

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

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

7. 软件开发生产率提高的速度往往跟不上计算机应用迅速普及的深入的速度

² 软件危机出现的原因：1. 来自软件自身的特点。是逻辑部件缺乏可见性；规

模庞复杂，修改维护困难

2. 软件开发与维护的方法不当。忽视需求分析；认为软件开发等于程序编写；轻视软件维护

3. 供求矛盾将是一个永恒的主题。面对日益增长的软件需求，人们显得力不从心

² 软件工程的定义：软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理。、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理技术和当前能够的到的最好的技术方法结合起来，以经济的开发出高质量的软件并有效的维护它，这就是软件工程。

² IEEE对软件工程的定义：软件工程是1把系统的，规范的，可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；2研究1中所提到的途径。

² 软件工程的本质特征：1. 软件工程关注于大型程序的构造

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

3. 软件经常变化

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

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

6. 软件必须有效的支持他的用户

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

² 消除软件危机的途径：1. 对计算机软件有一个正确的认识（软件！=程序）

2. 必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、结构严密、各类人员协同配合、共同完成的工程项目

3. 推广使用在实践中总结出来的开发软件的成功技术和方法

4. 开发和使用良好的软件工具

² 软件工程的基本原理：1. 用分阶段的生命周期计划严格管理

2. 坚持进行阶段评审

3. 实行严格的产品控制

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

5. 结果应该清楚的审查

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

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

² 软件工程包括（管理）和（技术）两方面的内容

² 软件工程方法学定义：通常把在软件生命周期全过程中使用的一整套技术方法的集合称为软件工程方法学。

² 软件工程方法学包含三个因素：方法、工具和过程

² 软件工程方法学分为传统方法学（生命周期方法学或结构化范型）和面向对象方法学（面向对象范型）

² 面向对象范型的要点：1. 把对象作为融合了数据及在数据上的操作行为的统

一的软件构件

2. 把所有的对象都划分成类

3. 按照父类（或称为基类）与子类（或称为派生类）的关系把若干个相关类组成一个层次结构的系统（也称为类等级）

4. 对象彼此间仅能通过发送消息互相联系

² 结构化范型的优点：把软件生命周期划分为若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员的分工协作，从而降低了整个软件开发过程的困难程度

² 结构化范型的缺点：当软件规模庞大时，或者对软件的需求是模糊的或会因为时间而变化时，开发出的软件往往不成功，而且维护起来依然很困难

² 面向对象范型的优点：降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作，促进了软件重用

² 软件工程与软件工程方法学有何关系：软件工程是为了开发出高质量的软件产品所需完成的一系列任务的框架，他规定了完成各项任务的工作步骤。而后者，通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称范型。  软件工程是软件工程方法学的三个重要组成部分之一。

² 什么是软件生命周期模型：软件生命周期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。

² 软件生命周期模型由：软件定义（问题定义，可行性研究，需求分析）；软件开发（总体设计，详细设计，编码与单元设计，综合测试）；运行维护

² 软件定义阶段要回答的关键问题是“要解决的问题是什么”可行性研究阶段要回答的关键问题是“对于上一个阶段所确定的问题有行得通的解决办法吗”需求分析阶段的任务仍不是解决问题而是准确的确定“为了解决这个问题，目标系统必须做什么”总体设计阶段回答的关键问题是“概括的说应该怎样实现目标系统”详细设计阶段把解法具体化回答“应该怎样具体的实现这个系统呢”编码和单元测试的关键任务时写出正确的容易理解、容易维护的程序模块综合测试的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求

² 运行维护的实质（对比可行性研究实质）：一次压缩和简化了的定义和开发过程。维护时期不在进一步划分阶段

² 瀑布模型的优点：它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。虽然有不少缺陷，但比在软件开发过程中随意的状态要好的多

² 瀑布模型的缺点：1. 实际的项目大部分情况难以按照该模型给出的顺序执行

，而且这种模型的迭代是间接的，这很容易由微小的变化

而造成大的混乱

2. 经常情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不欢迎二义性存在的

3. 客户要等到开发的晚期才能看到程序运行的测试版本，而在这是发现大的错误时，可能引起客户的惊慌，而后果也可能是灾难性的

² 瀑布模型的特点：1. 阶段间具有顺序性与依赖性

2. 推迟实现的观点

3. 质量保证的观点（1>每个阶段都必须完成规定的文档2每个阶段结束前都应该对所完成的文档进行评审，以便尽早发现问题，改正错误）

² 快速原型模型优点：使用户能够感受到实际的系统，使开发者能够快速的构造出系统的框架

² 快速原型模型的缺点：产品的先天性不足，因为开发者常常需要做实现上的折中，可能采用不合适的操作系统或程序设计语言，以使原型能够尽快工作

² 增量模型的优点：1. 人员分配灵活，刚开始不用投入大量的人力资源，当核

心产品很受欢迎时，可增加人力实现下一个增量

2. 当配备的人员不能在设定的期限内完成产品时，他提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇定剂的作用。

² 增量模型的缺点：自始至终开发者和客户纠缠在一起，知道完全版本出来，适用于软件需求不明确，设计方案有一定风险的软件项目

² 增量模型最佳分解的方法因软件产品特点和开发人员的习惯而异。分解时唯一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的

² 螺旋模型的基本思想：使用原型及其他方法来尽量降低风险

² 螺旋模型的优点：对于大型系统及软件的开发，这种模型是一个很好的方法，开发者和客户能够较好的对待和理解每一个演化级别上的风险

² 螺旋模型的缺点：1 需要相当的风险分析评估的专门技术，且成功依赖于这

种技术。

2 很明显，一个大的没有被发现的风险问题将会导致问题的发生，可能导致演化的方法失去控制

3 这种模型相对比较新，应用不广泛，其功效需要进一步验证

适用于内部开发的大规模软件项目

² 需求分析阶段应该用正式的文档准确地记录对目标系统的需求，这份文档通常称为“规格说明书”

² 螺旋模型=瀑布模型+增量模型

² 螺旋模型由风险驱动

² 为什么说喷泉模型较好的体现了面向对象软件开发过程无缝和迭代的特性？

因为使用面向对象方法学开发软件时，各个阶段都使用统一的概念和表示符号，因此，整个开发过程都是吻合一致的，或者说是无缝连接的，这自然就很容易实现各个开发步骤的反复多次迭代，达到认识的逐步深化，而喷泉模型则很好的体现了面向对象软件开发过程迭代和无缝的特性。

² Rational统一过程的优点：提高团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则。模板和工具指导，并确保全体成员共享相同的知识基础。他建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。

² Rational统一过程的缺点：RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容，此外，他没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。

² Rational统一过程主要适用于“大型的需求不断变化的复杂软件系统项目”

² 敏捷过程适用于“商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束”

² 微软过程适用于“商业环境下具有有限资源和有限开发时间约束的项目的软件过程模式”

第二章

v 可行性研究的必要性（原因）：开发一个软件时，需要判断原定的系统模型和目标是否实现，系统完成后所能带来的效益是否大到值得开发投资这个系统的程度，如果做不到这些，那么花费在这个工程上的任何时间、人力、软硬件资源和经费都是无谓的浪费。可行新研究的实质是在较高层次上以较抽象的方式进行的系统分析和设计的过程，可行性研究的目的是用最小的代价在尽可能短的时间内确定问题是否能够解决。

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

v 可行性研究的目的（不是）解决问题

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

v 可行性研究的内容：1. 技术可行性（对要开发项目的功能、性能和限制条件进行分析，确定在现有的资源条件下，技术风险有多大，项目能否实现）

2. 经济可行性（进行开发成本的估算以及了解取得效益的评估，确定要开发的项目是否值得投资开发）

3. 操作可行性（系统的操作方式在这个用户组织内是否行得通）

4. 社会可行性

5. 社会效益

6. 法律

v 可行性研究的任务：对以后的行动方针提出建议。

v 可行性研究时间的长短取决于（工程的规模）

v 可行性研究的成本是预计的工程总成本的（5%~10%）

v 可行性研究的过程：1. 复查系统规模与目标（确保分析员正在解决的问题时要求他

解决的问题）

2. 研究正在使用的系统

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

4. 进一步定义问题（根据逻辑模型 与用户一起发现和改正错误）

前四步构成了一个循环

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

6. 推荐行动方针

7. 草拟开发计划（给出需求分析阶段的进度表）

8. 书写文档提交审查

v 逻辑模型包括：数据流图和数据字典

v （拟定开发计划）阶段拟定需求分析进度表

系统流程图

v 数据流图（DFD）是一种图形化技术，他描述信息流和数据从输入移动到输出的过程中经受的变化

v 设计数据流图时只需要考虑系统必须完成的基本逻辑功能

v 数据流图中应该描绘出（所有可能的数据流向），而（不应该）描绘出现某个数据流的条件

v 数据流图中忽略出错处理

v 星号（*）表示“与”的关系  加号（+）表示“或”的关系  圆圈加表示互斥的关系

v 数据流图有四个成分：源点或终点  处理 数据存储  数据流

v 数据流图命名是先为（数据流）命名再为（处理）命名 如果对数据流命名是遇到了困难 可能是对数据流图分解的不恰当

v 数据流图中的处理应不超过（9）个  超过时就不易理解 应分层或画分图

v 数据流图的作用：1. 交流信息的工具。分析员把他对现有系统或对目标系统的设想用数据流图描绘出来，供有关人员审查确认

2. 作为分析和设计的工具

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

v 数据字典的作用：作为分析阶段的工具，在软件分析和设计的过程中给人提供关于数据的描述的信息

v 逻辑模型包括：数据流图  数据字典

v 数据字典的内容：1.数据流 2.数据流分量 3.数据存储 4.处理(对比数据流图四成分)

v 数据字典主要由对数据的定义组成，因为对数据的处理用其他工具（IPO图或PDL）描述更方便

v 数据字典中对数据的定义主要包括：一般信息，定义，使用特点，控制信息，分组信息

v 数据字典中数据定义的实质是：对数据进行一次自顶向下的分解

v 数据元素组成数据的方式有四种：顺序  重复  选择  可选

v =  等价于/定义为

v +  和/连接两个分量

v [  ]  选择一个  通常用‘|’隔开供选择的分量

v {  }  重复 重复花括号内的分量  有上下界 表示重复次数的上下界

v (  )  可选 即圆括号内的分量可有可无

v 成本效益分析的目的是：从经济角度分析开发一个新系统是否划算，从而帮助客户组织的负责人正解的做出是否投资于这项开发工程的决定

v 成本估计技术：代码行技术  任务分解技术  自动估计成本技术

v 数据流图与数据字典的关系：数据流图与数据字典共同构成系统的逻辑模型，没有数据字典，数据流图就不严格，没有数据流图，数据字典也难以发挥作用

第三章

ü 需求分析的目的/意义/必要性：为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发者带来烦恼。

ü 需求分析的任务：确定对系统的综合要求： 1. 功能需求

2. 性能需求

3. 可靠性和可用性需求

4. 出错处理需求

5. 接口需求

6. 约束

7. 逆向需求

8. 将来可能提出的要求

分析系统的数据要求（分析系统的数据结构，图形工具描

述数据结构[层次方框图和Warnier图]，数据结构规范化）

导出系统的逻辑模型（数据流图，实体联系图，状态转换

图，数据字典和主要的处理算法描述）

修正系统开发计划

ü 与用户沟通获取真实需求的的方式：1. 访谈

2. 面向数据流自顶向下求精

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

4. 快速建立软件原型

ü 需求分许是软件定义的最后一个阶段，他的主要任务时准确回答“系统必须做什么”这个问题，不是确定系统怎样完成他的工作

ü 需求分析结束之前应出具软件需求规格说明书，书面形式准确描述软件的需求

ü 需求分析方法准则：1. 必须理解并描述问题的信息域，根据这条准则应该建

立数据模型

2. 必须定义软件应完成的功能，这条准则要求建立功能模型

3. 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型

4. 必须对描述信息、功能、行为的模型进行分解，用层次的方式展示细节

ü 出错处理的定义：在某些情况下，出错处理指的是当应用系统发现它自己犯下一个错误时所采取的行动。有时也指系统对环境错误的响应

ü 对应用系统本身的检测应该仅限于系统的关键部分，并且应该尽可能的少

ü 接口需求定义：描述应用程序与它的环境通信的格式

ü 环境：即使用该系统的外界因素

ü 约束：设计约束或实现约束描述在设计或实现应用系统是应遵守的限制条件

ü 情景分析：情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行进行分析

ü 情景分析的用处（好处，意义）：1. 他能在某种程度上演示目标系统的行为，

从而便于用户理解，而且还可能进一步揭示

出一些分析员目前还不知道的需求

2. 由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色

ü 分析系统的数据要求通常采用建立数据模型的方式

ü 辅助描述数据结构，常用的图形工具有层次方框图和Warnier图

ü 需求分析的目标之一就是把数据流和数据存储定义到元素级

ü IPO图简明的描述了算法

ü 通过功能分解可以完成对数据流图的细化

ü 简易的需求规格说明技术是一个面向团队的需求收集法

ü 简明的需求规格说明技术的优点是：开发者和用户不分彼此，齐心协力，密切合作，计时讨论并求精，有能导出规格说明的具体步骤

ü 快速建立软件原型是最有效最强大的需求分析技术

ü 快速原型的定义：快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序

ü 快速原型的特点：1. 快速

2 容易修改

ü 建立快速原型的目的：尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快的达成共识

ü 快速的构建和修改原型通常使用下述3种方法和工具：

1. 第四代技术

2 可重用的软件构件

3 形式化规格说明和原型环境

（形式化说明技术第四章讲）

ü 模型的定义：为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成

ü 需求分析阶段应该建立三种模型：根据需求分析方法准则

1. 数据模型（实体联系模型）

2. 功能模型（数据流图）

3. 行为模型（状态图即状态转换图）

ü 形式化方法的必要性：1. 为了消除用自然语言书写的软件规格说明书中可能

存在的不一致性、歧义、含糊、不完整及抽象层次混

乱等问题。

2 在需求验证阶段，对于规模庞大的系统，方便人工

审查需求一致性

ü 数据对象是：对软件必须理解的复合信息的抽象，仅有单个值的事物不是数据对象

ü 复合信息：具有一系列不同性质或属性的事物

ü 数据对象只封装了数据而没有对施加于数据上的操作的引用。区别于面向对象范型是将数据与操作封装在一起

ü ER图中包含了“实体，关系和属性”3种基本成分。矩形框代表实体，圆弧矩形代表属性

ü ER模型的优点：1. ER模型比较接近人的习惯思维方式

2 ER模型使用简单的图形符号表达系统分析员对问题域的

理解，不熟悉计算机技术的用户也能理解它

3 ER模型可以作为用户与分析员之间有效的交流工具

ü 数据规范化的目的：减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程

ü 范式级别越高随之而来的一些列问题：1. 存储同样的数据就需要分解成更多

的表，因此“存储自身”的过程也

就越复杂

2 数据的存储结构与基于问题域的结

构件间的匹配程度也随之下降，因

此需求变化时数据源的稳定性较差

3 范式级别提高需要访问的表增多，因此性能将下降

ü 实用角度来看大多数场合实用第三范式

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

ü 状态：状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式

ü 事件：在某个特定时刻发生的事情，他是引起系统做动作或从一个状态转换到另一个状态的外界事物的抽象，简言之就是引起系统做动作或装换状态的控制信息

ü 状态图三部分，上面是状态的名称，中间是状态变量的名字和值，下面是活动表

ü Warnier图与层次方框图的区别：前者可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件的出现的。

ü IPO图的好处：方便的描述输入数据，对数据的处理和输出数据之间的关系；软件设计阶段可以进一步补充修正这些图，作为设计阶段的文档

ü 软件需求验证的四方面：1 一致性。所有需求必须是一致的，任何一条需求

不能和其他需求相互矛盾

2 完整性。需求必须是完整的，需求规格说明是必须包含用户需要的每一个功能

3 现实性。制定的需求必须是在现有的硬件技术和软件技术基本上可以实现的

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

ü 需求验证的方法：1 一致性。人工技术审查

2 现实性。仿真或性能模拟技术

3 完整性和有效性。请用户试用（成本高）；使用原型系统

ü 需求分析软件工具的要求：1. 必须有形式化的语法或表

2 使用这个软件工具能够导出详细的文档

3 必须提供分析（测试）规格说明书的不一致性

性和冗余性的手段，并且能够产生一组报告指明

对完整性分析的结果

4 能够改进通信状况

ü FSL/PSA系统的主要优点：它改进了文档质量，能保证文档具有完整性、一致性和无二义性，从而可以减少管理和维护的费用。数据存放在数据库中。便于增加、删除和更改，这也是他的一个优点。

第五章

² 总体设计的必要性：可以站在全局高度上，花较少成本，从较抽象的层次上分析对比多种可能的系统实现方案和软件结构，从中选出最佳方案和最合理的软件结构，从而用较低成本开发出较高质量的软件系统。

² 总体设计的过程：（主要由两个阶段组成：系统设计阶段，确定系统的具体实现方案；

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

1. 设想供选择的方案（从数据流图出发）

2. 选取合理的方案（低成本，中成本，高成本）（对于每一种方案应准备系统流程图，组成系统的物理元素清单，成本效益分析，实现这个系统的进度计划）

3. 推荐最佳方案（第一阶段至此完成）

4. 功能分解

5. 设计软件结构

6. 设计数据库

7. 制定测试计划

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

9. 审查和复查

² 软件设计过程中应该遵循的基本原理：1. 模块化。模块是由边界元素限定的相邻程序

元素（例如，数据说明，可执行的语句）的序列，而且有一个总体标识符代表它。模块是构成程序的基本构件。模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求

2. 抽象。抽象出事物的本质特征而暂时不考虑他们的细节，一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解，这些高级的概念又可以用一些低级的概念构造和理解。

3. 逐步求精。为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。事实上可以把逐步求精看作是一项把一个时期内必须解决的种种问题按优先级排序的技术

4. 信息隐藏和局部化。所谓局部化是指把一些关系密切的软件元素物理的放的彼此靠近。所谓隐藏不是隐藏关于模块的一切信息而是模块的实现细节

5. 模块独立开发具有独立功能而且和其他模块之间没有过多的交互作用的模块就可以做到模块独立

² 模块化的优点：1. 可以使软件结构清晰，不仅容易设计也容易阅读和理解 2. 使软件容易测试和调试，因而有助于提高软件的可靠性 3. 能够提高软件的可修改性 4. 有助于软件开发工程的组织管理

² 抽象与求精的联系与区别：抽象与求精是一对互补的概念。抽象使得设计者能够说明过程和数据，同时却忽略了底层细节。事实上可以把抽象看做是一种通过忽略多余的细节同时强调有关的细节而实现逐步求精的方法。求精则帮助设计者在设计过程中揭示出底层细节。

² 模块独立的好处（重要性）：第一，有效的模块化(即具有独立的模块)的软件比较容易开发出来。这是由于能够分割功能而且接口可以简化，当许多人分工合作开发同一个软件时，这个优点尤其重要。第二，独立的模块比较容易测试和维护。这是因为相对说来，修改设计和程序需要的工作量比较小，错误传播范围小，需要扩充功能时能够“插入”模块。

² 耦合和内聚的区别与联系：是模块独立程度的两个标准度量。耦合衡量不同模块彼此间互相依赖(连接)的紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。内聚和耦合是紧密相关的，模块内的高内聚往往意味着模块间的松耦合

² 设计时应该力求做到低耦合和高内聚

² 耦合的概念：耦合衡量不同模块彼此间互相依赖(连接)的紧密程度。

² 数据耦合：两个模块彼此间通过参数交换信息而且交换的信息仅仅是数据

² 控制耦合：两个模块间传递的信息中有控制信息出现时，这种耦合称为控制耦合

² 控制耦合一般可以通过适当分解用数据耦合代替它

² 特征耦合：当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时，就出现了特征耦合

² 公共环境耦合：当两个或多个模块通过一个公共数据环境相互作用时，他们之间的耦合称为公共环境耦合

² 内容耦合:一个模块可以直接调用另一模块中的数据，或者允许一个模块直接转移到另一个模块中去。

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

² 内聚的概念：内聚衡量一个模块内部各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。

² 偶然内聚：一个模块完成一组任务，这些任务间彼此即使有关系，关系也是很松散的，就叫做偶然内聚。（低内聚）  出现错误的概率最高

² 如果一个模块完成的任务在逻辑上属于相同或相似的一类，则称为逻辑内聚（低内聚）。 修改较困难

² 时间内聚：一个模块包含的任务必须在同一段时间内执行（低内聚）

² 过程内聚：一个模块内的处理元素是相关的，而且必须以特定次序执行，则称为过程内聚（中内聚）

² 通信内聚：模块中所有元素都使用同一个输入数据和产生同一个输出数据，则称为通信内聚（中内聚）

² 顺序内聚：一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，则称为顺序内聚。（高内聚）

² 功能内聚：模块内所有处理元素属于一个整体，完成一个单一功能，则称为功能内聚（最高程度的内聚）

² 软件设计的启发式规则：1. 改进软件结构提高模块独立性

2. 模块规模应该适中

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

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

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

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

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

² 一个设计的好的点醒系统的平均扇出应该是3~4  上限应该是5~9

² 启发式规则只是经验之谈，既不是总体设计的目标也不是应该遵循的普遍原理

² 在结构图中，箭头表示传递的信息，尾部是空心圆表示传递的是数据，实心圆表示传递的是控制信息

² 面向数据流的设计方法的目标是给出设计软件结构的一个系统化的途径

² 面向数据流的设计方法：把信息流映射成软件结构，信息流的类型决定了映射的方法

² 变换流：信息沿输入通路进入系统，同时由外部形势变换成内部形势，进入系统的信息通过变换中心，经加工处理之后再沿输出通路变换成外部形势离开软件系统

² 事务流完成的任务：1. 接收输入数据（输入数据又称为事务）

2. 分析每个事务以确定它的类型

3. 根据事务类型选取一条活动通路

² 变换分析的步骤：（把具有变换流特点的数据流图按预先确定的模式映射成软件结构）

1. 复查基本数据模型

2. 复查并精化数据流图

3. 确定数据流图具有变换特性还是事务特性

4. 确定输入流和输出流的边界，从而孤立出变换中心

5. 完成第一级分解

6. 完成第二级分解

7. 使用设计度量和启发式规则对第一次分割得到的软件结构进一步精化

² 变换分析与事务分析的选择：如果数据流不具有显著的事务特点，最好使用变换分析；反之，如果具有明显的事务中心，则应该采用事务分析技术。但是，机械地遵循变换分析或事务分析的映射规则，很可能会得到一些不必要的控制模块，如果它们确实用处不大，那么可以而且应该把它们合并。反之，如果一个控制模块功能过分复杂，则应该分解为两个或多个控制模块，或者增加中间层次的控制模块。

第六章

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

v 衡量程序的质量不仅要看他的逻辑是否正确，性能是否满足要求，更主要的是看他是否容易阅读和理解（结构程序设计技术）

v 只用三种基本的控制结构就可以实现任何单入口单出口的程序（顺序）（选择）（循环）

v 结构程序设计的定义：结构程序设计是尽可能少用GO TO语句的程序设计方法。最好仅在检测出错误时才使用GO TO语句，而且应该总是使用前向GO TO语句。

v 经典的结构程序设计：顺序、选择、循环

扩展的结构程序设计：并且允许do-case、do-until

修正的结构程序设计：并且允许leave、break

v 人机界面设计遇到的问题：1. 系统响应时间

2. 用户帮助设施

3. 出错信息处理

4. 命令交互

v 响应时间：从用户完成某个控制动作到软件给出某个预期的响应之间的这段时间

v 响应时间的两个基本属性：长度和易变性

v 过程设计工具可以分为（图像）（表格）（语言）

v 程序流程图的主要缺点：1. 程序流程图本质上不是逐步求精的好工具，它诱使程序员

过早地考虑程序的控制流程，而不去考虑程序的全局结构。

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

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

v 盒图的特点：1. 功能域(即一个特定控制结构的作用域)明确，可以从盒图上一眼就看出

来

2. 不可能任意转移控制

3. 很容易确定局部和全程数据的作用域

4. 很容易表现嵌套关系，也可以表示模块的层次结构

v PAD图的优点：1. 使用表示结构化控制结构的PAD符号所设计出来的程序必然是结构

化程序。

2. PAD图所描绘的程序结构十分清晰。图中最左面的竖线是程序的主线，即第一层结构。随着程序层次的增加，PAD图逐渐向右延伸，每增加一个层次，图形向右扩展一条竖线。PAD图中竖线的总条数就是程序的层次数。

3. 用PAD图表现程序逻辑，易读、易懂、易记。PAD图是二维树形结构的图形，程序从图中最左竖线上端的结点开始执行，自上而下，从左向右顺序执行，遍历所有结点。

4. 容易将PAD图转换成高级语言源程序，这种转换可用软件工具自动完成，从而可省去人工编码的工作，有利于提高软件可靠性和软件生产率。

v 判定表的优点：清晰的表示复杂的条件组合与应做的动作之间的对应关系

v 判定表的缺点：不适合作为一种通用的设计工具，没有一种简单的方法使它能同时清晰的表示顺序和重复等处理特性

v 以上为图或表的形式来描述过程设计，语言描述过程设计的是“过程设计语言”

v 过程设计语言（PDL）的特点：1. 关键字的固定语法，它提供了结构化控制结构、数据

说明和模块化的特点。

2. 自然语言的自由语法，它描述处理特点。

3. 数据说明的手段。应该既包括简单的数据结构(例如纯量和数组)，又包括复杂的数据结构(例如，链表或层次的数据结构)。

4. 模块定义和调用的技术，应该提供各种接口描述模式。

v 过程设计语言的优点：1. 可以作为注释直接插在源程序中间。这样做能促使维护人员

在修改程序代码的同时也相应地修改PDL注释，因此有助于保持

文档和程序的一致性，提高了文档的质量。

2. 可以使用普通的正文编辑程序或文字处理系统，很方便地完

成PDL的书写和编辑工作。

3. 已经有自动处理程序存在，而且可以自动由PDL生成程序代

码。

v PDL的缺点是不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时，不如判定表清晰简单。

v 面向数据结构设计方法的最终目标是得出对程序处理过程的描述

v Jackson图（面向数据结构的设计方法）（选择）（顺序）（循环）

v Jackson程序设计方法的步骤：1. 分析并确定输入数据与输出数据的逻辑结构，并用Jackson图描绘这些数据结构2. 找出输入数据结构与输出数据结构中有对应关系的数据单元3. 从描绘数据结构的Jackson图导出描绘程序结构的Jackson图4. 列出所有操作和条件，并且把他们分配到程序结构图的适当位置5. 用伪码表示程序

v 程序复杂程度定量度量的必要性：把程序的复杂程度乘以适当常数即可估算出软件中错误的数量以及软件开发需要用的工作量，定量度量的结果可以用来比较两个不同的设计或两个不同算法的优劣；程序的定量的复杂程度可以作为模块规模的精确限度

v McCabe计算环形复杂度：V(g) = E-N+2    E是边数 N是点数

v ***   环形复杂度的上限是10

v Halstead预测程序长度 H = n1*log2(n1)+n2*log2(n2)

预测程序中包含错误个数  E = N*log2(n1+n2)/3000

其中n1表示不同运算符的个数 n2表示不同操作数的个数

N1表示运算符出现的总次数  N2表示操作数出现的总次数  N=N1+N2

第七章

n 实现包括编码和测试

n 程序的质量主要取决于（软件设计的质量）

n 测试的必要性：如果在软件投入生产性运行之前没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那是，不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果

n 测试的目的：尽可能多的发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用

n 判断题：测试阶段的任务是发现错误 x  并改正错误

n 选择程序设计语言的主要实用标准：1. 系统用户的要求

2. 可以是使用的编译程序

3. 可以得到的软件工具

4. 工程规模

5. 程序员的知识

6. 软件可移植性要求

7. 软件的应用领域

n 源代码编写规则：1. 程序内部的文档。程序内部应包含必要的标识符、适当的注释、

和程序的视觉组织等

2. 良好的数据说明风格。数据说明的次序应该标准化

3. 简单而直接的语句构造

4. 输入输出具有规则

5. 具有较高的效率。效率主要是指处理机时间和存储器容量两个方面

n 软件应该像对他要求的那样有效，而不应该如同人类可以做到的那样有效

n 效率是靠好设计来提高的，不要牺牲程序的清晰性和可读性来提高效率

n 软件测试的准则：1. 所有测试都应该能追溯到用户需求

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

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

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

5. 穷举测试是不可能的

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

7. 程序修改后要回归测试

8. 应长期保留测试用例，直至系统废弃

n 测试分为静态测试和动态测试，区别在于是否实际运行软件，静态分为人为和计算机辅助，动态分为黑盒白盒

n 黑盒测试的又称功能测试

n 白盒测试又称结构测试

n 测试的步骤：1. 模块测试。把每个模块当做一个单独的实体来测试

2. 子系统测试。把经过单元测试的模块当做一个子系统来测试，主要测试模块间的协调和通信，因此这个阶段着重测试接口

3. 系统测试。发现软件设计中的错误或需求说明中的错误

4. 验收测试。需要用户参与，往往发现的是需求说明书中的错误

5. 平行运行。同时运行新旧系统

n 模块测试是对每个单独的模块，分别采用黑盒和白盒测试技术，测试他的功能是否正确，检查模块控制结构中的特定路径并发现最大数量的错误

n 模块测试的特点是主要应用白盒测试技术，并且多个模块可以并发的进行

n 验收测试又称确认测试，目的是：验证系统确实能满足用户的需要

n 平行运行的目的：1. 可以在准生产环境下运行新系统而又不冒风险

2. 用户能有一段熟悉新系统的时间

3. 可以验证用户指南和使用手册之类的文档

4. 能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标

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

n 集成测试是测试和组装软件的系统化技术，其主要目标是发现与接口有关的问题。其特点是可能发生接口问题

n 集成测试的方法：1. 非渐增式测试方法：先分别测试每个模块，再将所有的模块结合

在一起

2. 渐增式测试方法：一次增加进来一个待测试的模块（自底向上，自顶向下）

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

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

n 回归测试：重新执行已经做过的测试的某个子集，以保证增加进的新的模块没有带来非预期的副作用

n 回归测试的内容：1.检验软件功能的代表性测试用例 2. 专门针对可能受影响的软件功能的附加测试 3. 针对被修改过的软件成分的测试

n 确认与验证的区别：验证指的是保证软件正确的实现了某个特定要求的一系列活动；确认指的是为了保证软件确实满足了用户需求而进行的一系列活动

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

n 确认测试的内容：1.复查软件配置 2. 检验使用手册的完整性与正确性 3. 检测软件是否与需求一致 4. 保证软件能满足所有功能要求 5. 文档资料是准确完整的 6. 软件能满足其他预定的要求（安全性、可移植性、兼容性。可维护性）

n 确认测试基本使用黑盒测试法

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

n 白盒测试技术：逻辑覆盖技术与控制结构测试技术（基本路径测试、条件测试和循环测试）

n 逻辑覆盖技术：1. 语句覆盖。每个语句应该执行一次

2 判定覆盖。不仅每个语句至少执行一次，而且每个判定的每种可能结

果也应该至少执行一次

3 条件覆盖。不仅每个语句至少执行一次，判定表达中每个条件都取到各种可能得结果

4 判定/条件覆盖。同时满足两种覆盖

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

6 点覆盖 7 边覆盖 8 路径覆盖

n 基本路径测试的步骤：1.根据过程结构画出相应的流图

2.计算流图的环形复杂度

3.确定线性独立路径的基本集合

4.设计可强制执行基本集合中的每条路径的测试用例

n 条件测试错误的类型:1.布尔算符错 2.布尔变量错 3.布尔括弧错 4.关系算符错 5.算数表达式错

n 条件测试策略的优点：1.容易度量条件的测试覆盖率 2.程序内条件的测试覆盖率可指导附加测试的设计

n 条件测试的目的：不仅是检验程序条件中的错误，而且是检验程序中的其他错误

n 循环测试的三种办法：1. 简单循环 2. 嵌套循环  3. 串接循环

n 黑盒测试法：把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程。黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息(如，数据库或文件)的完整性。

n 黑盒测试主要用于测试的后期 白盒测试主要用于早期

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

①功能不正确或遗漏了功能；

②界面错误；

③数据结构错误或外部数据库访问错误；

④性能错误；

⑤初始化和终止错误。

n 黑盒测试法技术：1.等价划分 2. 边界值分析 3.错误推测

n 等价类划分：等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。

n 等价类划分先要划分等价类，接下来一次测试有效等价类与无效等价类

n 错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试方案。

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

n 调试途径：1. 蛮干法 2. 回溯法 3. 原因排除法

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

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

n 可靠性与可用性的区别：可靠性是指一段时间间隔内程序没有失效，可用性意味着这段时间内程序正确运行

n MYTTF = 平均无故障时间  Et 测试之前程序中错误总量  Ir程序长度 Ec x时间内改正的错误

n MTTF = 1/K*(Et/Ir-Ec/Ir)  **是减号

第八章

ü 软件维护的基本任务（作用）是保证软件在一个相当长的时期能够正常运行

ü 软件维护：在软件已经交付使用之后为了改正错误或者满足新的需要而修改软件的过程

ü 软件维护的本质：修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作就已经开始了

ü 软件维护的分类：1. 改正性维护。诊断和改正错误

2. 适应性维护。为了和变化了的环境适当的配合而进行的修改软件

的活动

3. 完善性维护。增加新功能或修改已有功能

4. 预防性维护。给未来的改进奠定良好的基础

ü 软件维护的特点：1. 结构化维护与非结构化维护差别巨大

2. 维护的代价高昂

3. 维护的问题很多

ü 维护过程的问题：1. 理解别人写的程序通常非常困难

2. 需要维护的软件往往没有合格的文档，或者文档资料显著不足

3. 当要求对软件进行维护时，不能指望由开发人员给人们自习说明软件

4. 绝大多数软件在设计时没有考虑将来的修改

5. 软件维护不是一项吸引人的工作

ü 软件维护的过程：1. 维护组织

2. 维护报告

3. 维护的事务流

4. 保存维护记录

5. 评价维护活动

ü 决定软件可维护性的因素：1. 可理解性

2. 可测试性

3. 可修改性

4. 可移植性

5. 可重用性

ü 提高可维护行的方法：建立明确的软件质量目标和优先级

使用提高软件质量的技术和工具

进行明确的质量保证审查

选择可维护的程序设计语言

改进程序的文档

ü 软件文档分为系统文档与用户文档

ü 软件文档的要求：1. 必须描述如何使用这个系统

2. 必须描述怎样安装和管理这个系统

3. 必须描述系统需求和设计

4. 必须描述系统的实现与测试，以便使系统成为可维护的

ü 用户文档五方面内容：1. 功能描述 2. 安装文档 3. 使用手册 4. 参考手册 5. 操作员指南

ü 开发与维护的关系：

许多软件的维护十分困难，原因在于这些软件的文档不全、质量差、开发过程不注意采用好的方法，忽视程序设计风格等。

ü 软件维护与软件工程的关系：软件维护时软件工程的最后一个阶段，软件工程的主要目的就是提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的成本。软件维护决定了未来软件工程的可靠性与可维护性。

ü 在软件开发过程中应该采取哪些措施来提高软件的可维护性

在每个阶段结束前的技术复审和管理复查中，应该着重对可维护性进行复审，应该对将来要改进的部分和可能要改的部分加以注意指明，应该讨论软件的可移植性问题，考虑可能影响软件维护的系统界面。在设计和编码过程中应该尽量使用可重用的软件构件，每个测试步骤都可以暗示在软件正式交付使用之前，程序中可能需要做预防性维护的部分。在完成每项维护工作之后，都应该对软件维护本身仔细认真的复审。

ü 需求分析的目的/意义/必要性：为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发者带来烦恼。

ü 需求分析的任务：确定对系统的综合要求： 1. 功能需求

2. 性能需求

3. 可靠性和可用性需求

4. 出错处理需求

5. 接口需求

6. 约束

7. 逆向需求

8. 将来可能提出的要求

分析系统的数据要求（分析系统的数据结构，图形工具描

述数据结构[层次方框图和Warnier图]，数据结构规范化）

导出系统的逻辑模型（数据流图，实体联系图，状态转换

图，数据字典和主要的处理算法描述）

修正系统开发计划

ü 与用户沟通获取真实需求的的方式：1. 访谈

2. 面向数据流自顶向下求精

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

4. 快速建立软件原型

ü 需求分许是软件定义的最后一个阶段，他的主要任务时准确回答“系统必须做什么”这个问题，不是确定系统怎样完成他的工作

ü 需求分析结束之前应出具软件需求规格说明书，书面形式准确描述软件的需求