治白癫疯办法 http://baidianfeng.39.net/a_bdfnzhm/130903/4249431.html

第一章：绪论

软件危机：

20世纪60年代以来，随着计算机的广泛应用，软件生产率、软件质量远远满足不了社会发展的需求，成为社会、经济发展的制约因素，人们通常把这一现象称为“软件危机”。

软件工程的概念、发展、目的：

概念：软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。

发展：软件工程的发展可分为两个时期：20世纪60年代末到80年代初、20世纪80年代以来。前期主要围绕系统实现技术、软件质量和软件工程管理；后期主要表现为软件复用技术、软件生产管理的研究和实践。

目的：倡导以工程的原理、原则和方法进行软件开发，以期解决出现的“软件危机”。

软件：

计算机软件一般是指计算机系统中的程序及其文档。其中，程序是计算机任务的处理对象和处理规则的描述；文档是为了理解程序所需要的阐述性资料。

软件开发的本质：

实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。可概括为：不同抽象层术语之间的映射，以及不同抽象层处理逻辑之间的映射。

软件开发所涉及的两大问题：

一是如何实现这样的映射，这是技术层面的问题；二是如何管理这样的映射，以保障映射的有效性和正确性，这是管理层面的问题。

软件开发所涉及的两大技术：

一是过程方向，即求解软件的开发逻辑；二是过程途径，即求解软件的开发手段。

软件开发的基本途径：

基本途径是系统建模，所谓系统建模是指运用所掌握的知识，通过抽象，给出该系统的一个结构。

系统模型及分类：

概念：模型是对待建系统的任意抽象。该抽象是在特定意图下所确定的角度和抽象层次上对物理系统的描述，描述其中的成分和成分之间所具有的特定语义关系，还包括对该系统边界的描述。

分类：在软件开发领域，系统模型分为两大类：一类称为概念模型，描述了系统是什么；另一类统称为软件模型，描述了实现概念模型的软件解决方案。软件模型又可进一步分为设计模型、实现模型、部署模型等。

重要填空题：

正确认识软件开发，是从事软件开发实践和软件工程项目管理的思想基础。

第二章：软件需求与软件需求规约

需求及性质：

概念：一个需求是有关一个“要予构造”的陈述，描述了待开发产品/系统功能上的能力、性能参数或其他性质。

性质：（必无三可）

1.必要的：该需求是用户所要求的。

2.无歧义的：该需求只能用一种方式解释。

3.可测的：该需求是可进行测试的。

4.可跟踪的：该需求可从一个开发阶段跟踪到另一个开发阶段。

5.可测量的：该需求是可测量的。

需求分类及关系：

分类：

1.功能需求：是系统或系统构件必须执行的功能。

2.非功能需求。非功能需求可分为：性能、外部接口、设计约束、质量属性。

关系：

1.一般来说，功能需求是整个需求的主体，即没有功能需求，就没有派生的其他功能需求，就没有性能、外部接口、设计约束、质量属性等非功能需求。

2.非功能需求可以作用于一个或者多个功能需求。

初始需求发现技术：（自交观小D）

1.自悟：需求人员把自己作为系统最终用户，审视系统并提出问题。

2.交谈：为了确定系统应该提供的功能，需求人员通过提出问题/用户回答这一方式，直接询问用户需要的是一个什么样的系统。

3.观察：通过观察用户执行其现行的任务和过程，或通过观察他们如何操作与所期望的新系统有关的现有系统，了解系统运行的环境，特别是了解要建立的新系统与现存系统、过程以及工作方法之间存在的交互。

4.小组会：举行客户开发人员的联席会议，与客户组织的一些代表共同开发需求。

5.提炼：复审技术文档，并提取相关的信息。

需求规约、性质、表达形式、作用：

概念：需求规约是对一个软件/产品/系统所有需求陈述的正式文档，表达了一个软件/产品/系统的概念模型。

性质：（重重的吻可玩一会儿）

1.重要性与稳定性程度：按需求的重要性和稳定性，对需求进行分级。

2.可修改的：在不过多地影响其他需求的前提下，可以容易的修改一个单一需求。

3.完整的：没有被遗漏的需求。

4.一致的：不存在互斥的需求。

表达形式：

1.非形式化：以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章。

2.半形式化：以半形式化符号体系来表达需求规约。

3.形式化：以一种基于良构数学概念的符号体系来编制需求规约。

作用：

1.需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。

2.对于项目的其余大多数工作，需求规约是一个控制管理点。

3.对于产品/系统的设计，需求规约是一个正式的、受控的起始点。

4.需求规约是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档--初始测试计划和用户系统操作描述。

重要填空题：

软件需求是任何软件工程的基础。

验证需求是不是歧义的，一般可采用需求复审。

需求规约的技术核心是特定需求。

第三章：结构化方法

需求分析：

针对一个问题，系统化地使用信息对该问题的一个估算。需求分析其目标是给出

“系统必须做什么”的一个估算。

数据流图：

表达功能模型的工具，简单的说数据流图是一种描述数据变化的图形化工具，其中

包含的元素可以是数据流、数据存储、加工、数据源、数据谭等。

结构化分析建模步骤：

1.建立系统环境图，确定系统语境。

2.自顶向下，逐步求精，建立层次数据流图。

3.定义数据字典。

4.描述加工。

系统功能模型部分组成及其作用：

数据流：是数据的流动，用于表达在分析中所要使用的，用于表达“客体”的信息。

加工：数据变换单元，即接收输入的数据，对其进行处理，并产生输出。

数据存储：数据的静态结构，用于表达在分析中所使用的，表达“结构化客体”的信息。

数据源：数据流的起点。

数据潭：数据流的归宿地。

软件设计：

在需求分析的基础上，定义满足需求所需要的结构，即针对给定的问题，给出该问

题的软件解决方案，确定“怎么做”的问题。

总体设计任务、目标、步骤、模式、阶段：

任务：把系统的功能需求分解到一个特定的软件体系结构中。

目标：将数据流图转换成系统的模块结构图。

步骤：首先将系统的DFD图转化为初始的模块结构图，再基于“高内聚低耦合”这一软件设计原理，通过模块化，将初始的模块结构图转化为最终的、可供详细设计使用的模块结构图(MSD)。

模式：变换设计和事物设计。

阶段：初始设计、精化设计、复审阶段。

将DFD转换为MSD的基本思路：

在分类DFD的基础上，基于自顶向下、功能分解的设计原则，定义了两种不同的“映射”，即变换设计和事务设计。其基本步骤是，首先将系统的DFD图转化为初始的模块结构图，再基于“高内聚低耦合”这一软件设计原理，通过模块化，将初始的模块结构图转化为最终的、可供详细设计使用的模块结构图(MSD)。

变换型数据流图：

具有较明显的输入部分和变换部分，变换部分和输出部分之间的界面的数据流图。

事务型数据流图：

事务到达一个加工T,加工T根据输入数据的值，在其后的若干动作序列中选出一个来执行。

变换设计的步骤：

1.设计准备--复审并精化系统模型。

2.确定输入、变换、输出这三部分之间的边界。

3.第一级分解--系统模块结构图顶层和第一层的设计。

4.第二级分解--自顶向下，逐步求精。

事物设计的步骤：

1.设计准备--复审并精化系统模型。

2.确定事物中心。

3.第一级分解--系统模块结构图顶层和第一层的设计。

4.第二级分解--自顶向下，逐步求精。

针对具有变换型和事物型数据流图的总体设计步骤：

在软件总体设计中，通常以变换设计为主，事物设计为辅进行结构设计。

即首先利用变换设计，把软件系统分为输入、中心变换和输出3部分，设计上层模块；

然后根据各部分数据流图的结构特点，适当地利用变换设计和事物设计进行细化，得到初始的模块结构图；

再按照“高内聚低耦合”的原则，对初始的模块结构图进行精化，得到最终的模块结构图。

变换设计和事物设计区别和联系：

1.变换设计的目的是将变换型数据流图映射为模块结构图，它由三部分组成：输入、变换、输出，其中变换是核心。为了协调这些模块的有序工作，还应设计一个主控模块来协调和控制其他模块。

2.事物设计的目的是将事务型数据流图映射为模块结构图，事物设计都有一个事务中心，事务中心需要完成三个任务：接受输入数据、分析并确定对应的事物和选取与该事物对应的一条活动路径。

3.在软件总体设计中，通常以变换设计为主，事物设计为辅进行结构设计。

模块：

执行一个特殊任务的一个过程以及相关的数据结构。模块通常由两部分组成。一部分是接口；另一部分是模块体，是接口的实现。

模块化：

把一个待开发的软件分解若干简单的具有高内聚低耦合的模块，这一过程称为模块化。

耦合的概念、分类、原则：

概念：不同模块之间相互依赖程度的度量。

分类：（内容是公共的，大家可以控制标记其中的数据）

1.内容耦合：当一个模块直接修改或操作另一个模块的数据，或一个模块不通过正常入口而转入到另一个模块时，这样的耦合被称为内容耦合。内容耦合是最高程度的耦合。

2.公共耦合：两个或两个以上的模块共同引用一个全局数据项，这种耦合被称为公共耦合。

3.控制耦合：一个模块通过接口向另一个模块传递控制信号，接收信号的模块根据信号值进行适当的动作，这种耦合被称为控制耦合。

4.标记耦合：若一个模块A通过接口向两个模块B和C传递一个公共参数，那么称模块B和C之间存在一种标记耦合。

5.数据耦合：模块之间通过参数来传递数据，则称为数据耦合。

原则：如果模块间必须存在耦合，就尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，尽量避免使用内容耦合。

内聚的概念、分类：

概念：一个模块内部各成分之间相互关联程度的度量。

分类：（偶然并没有逻辑的时间过程，它们是通过通信顺序组成的功能模型）

1.偶然内聚：如果一个模块的各成分之间基本不存在任何关系，则称为偶然内聚。

2.逻辑内聚：几个逻辑上相关的功能被放在同一个模块中，则称为逻辑内聚。

3.时间内聚：如果一个模块完成的功能必须在同一个时间内执行，但这些功能只是因为时间因素关联在一起，则称为时间内聚。

4.过程内聚：如果一个模块内部的处理成分是相关的，而且这些处理必须以特定的次序执行，则称为过程内聚。

5.通信内聚：如果一个模块的所有成分都操作同一个数据集或生成同一数据集，则称为通信内聚。

6.顺序内聚：如果一个模块的各成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入，则称为顺序内聚。

7.功能内聚：最理想的内聚是功能内聚，模块的所有成分对于完成单一的功能都是基本的。功能内聚的模块对于完成其功能而言是充分必要的。

启发式规则：

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

2.力求模块规模适中。

3.力求深度、宽度、扇入、扇出适中。

4.尽力使模块的作用域在控制域之内。

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

6.力求模块的功能可预测。

模块的控制域和作用域：

控制域：模块本身以及直接或间接从属于它的模块集合。

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

详细设计的任务、目标：

任务：具体描述模块结构图中的每一个模块，即给出实现模块功能的实施机制，包括一组例程和数据结构，从而精准地定义了满足需求所规约的结构。提供实现模块过程或功能的具体算法。

目标：将总体设计阶段所产生的系统高层结构映射为这些术语所表达的低层结构，也是系统的最终结构。

详细设计的工具：

1.程序流程图

2.盒图(N-S图)

3.问题分析图(PAD图)

4.类程序设计语言(PDL)

程序流程图的优缺点：

优点：对控制流程的描绘很直观，便于初学者掌握。

缺点：

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

2.所表达的控制流，往往不受任何约束可随意转移，从而会影响甚至破坏好的系统结构。

3.不易表示数据结构。

系统功能模型和系统模型的主要区别：

系统功能模型：是以获取系统功能需求为目的，从系统行为的角度，在由“数据流”、“加

工”、“数据存储”、“数据源”和“数据潭”等术语所定义的需求层上，对待开发系统的描述，

包括系统环境的描述。

系统模型：