软件工程主要内容.docx

软件工程主要内容.docx

《软件工程主要内容.docx》由会员分享，可在线阅读，更多相关《软件工程主要内容.docx（40页珍藏版）》请在冰豆网上搜索。

软件工程主要内容

第一章软件工程学概述

1．软件危机

（1）软件危机的介绍

1）软件危机：

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

2）软件危机的两个主要问题：

如何开发软件，以满足对软件日益增长的需求；

如何维护数量不断膨胀的已有软件。

3）软件危机的典型表现：

（1）对软件开发成本和进度的估计常常很不准确。

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

（3）软件产品的质量往往靠不住。

（4）软件常常是不可维护的。

（5）软件通常没有适当的文档资料。

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

（7）软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

（2）产生软件危机的原因

软件本身特点：

1）缺乏可见性，在运行之前往往难以衡量，质量也难以评价

2）不会因为长期使用而用坏，软件维护通常意味着修正或修改原来的设计，较难维护。

3）规模庞大，需分工合作，如何保证每个人的工作合在一起是极端复杂的问题。

软件开发与维护的方法不正确

产生软件危机的原因可归结为两个重要的方面：

软件生产本身存在的复杂性；

软件开发所使用的方法和技术。

软件生命周期：

一个软件从定义、开发、使用和维护直到最早被废弃。

软件产品必须由一个完整的配置组成（程序、文档、数据）

（3）消除软件危机的途径

1）正确认识计算机软件

2）认识到软件开发是一个协同配合、共同完成的工程项目并吸取经验。

3）推广使用已总结的开发软件成功的技术和方法

4）开发使用更好的软件工具

2．软件工程

（1）软件工程的介绍

软件工程是指导计算机软件开发和维护的一门工程学科。

采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地、高效的开发出高质量的软件并有效地维护它，这就是软件工程。

本质特性：

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

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

3）软件经常变化

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

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

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

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

（2）软件工程的基本原理

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

2）坚持进行阶段评审

3）实行严格的产品控制

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

5）结果应能清楚地审查

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

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

（3）软件工程方法学

在软件生命周期全过程中使用的一整套技术方法的集合称为方法学。

软件工程方法学，三要素：

方法、工具和过程。

1）传统方法学

2）面向对象方法学

3．软件生命周期：

定义、开发、维护

（1）问题定义

（2）可行性研究

（3）需求分析

（4）总体设计

（5）详细设计

（6）编码和单元测试

（7）综合测试

（8）软件维护

4．软件过程：

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

通常使用生命周期模型简洁的描述软件过程。

（1）瀑布模型

1）各个阶段的顺序性和依赖性；

　　　2）划分逻辑设计与物理设计，尽可能推迟程序的物理实现；

　　　3）每个阶段必须完成规定的文档，对其中问题通过复审及早发现，及早解决。

（2）快速还原模型

（3）增量模型

（1）从部分需求出发，先建立一个不完全的系统，通过测试运行该系统取得经验和信息反馈，加深对软件需求的理解，进一步使系统扩充和完善。

如此反复，直至软件人员和用户对所设计完成的软件系统满意为止。

（2）在渐增型开发下的软件是随软件开发的过程而逐渐形成的。

　　　（3）渐增型开发方法适合于知识型软件的开发，设计系统时对用户需求的认识开始不是很清楚的，需要在开发过程中不断认识、不断获得新的知识去丰富和完善系统。

多数研究性质的试验软件，一般采用此方法。

（4）螺旋模型

（5）喷泉模型

（6）Rational统一过程

（7）敏捷过程与极限编程

（8）微软过程

第二章可行性研究

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

问题定义的任务：

将用户提出的要求具体化、定量化；确定研制系统的范围，明确研制的边界。

问题定义阶段的工作：

1）通过调查研究，了解系统需求；

2）确定系统的功能需求、性能需求、可靠性需求、安全及保密性、资源、开发费用及开发进度等的需求；

3）问题定义阶段的产品--系统目标与范围说明书。

1.可行性研究的任务

（1）技术可行性

（2）经济可行性

（3）操作可行性

2.可行性研究的过程

（1）复查系统规模和目标

（2）研究目前正在使用的系统

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

（4）进一步定义问题

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

（6）推荐行动方针

（7）草拟开发计划

（8）书写文档提交审查

3.系统流程图

系统流程图是描述物理系统的传统工具。

它的基本思想是用图形符号以黑盒子形式描绘系统里的每个部件（程序、文件、数据库、表格、人工过程等）。

系统流程图表达的是部件的信息流程，而不表示对信息进行加工处理的控制过程。

4.数据流图

DFD是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。

与程序流程图不同，DFD不表示程序的控制结构，只描述数据的流动

DFD分成多层（子图、父图概念）表示,从而逐步展开数据流和功能的细节。

绘制数据流图步骤

（1）确定所开发的系统的外部项（外部实体），即系统的数据来源和去处。

（2）确定整个系统的输出数据流和输入数据流，把系统作为一个加工环节，画出关联图。

 （3）确定系统的主要信息处理功能，按此将整个系统分解成几个加工环节（子系统）确定每个加工的输出与输入数据流以及与这些加工有关的数据存储。

（4）根据自顶向下，逐层分解的原则，对上层图中全部或部分加工环节进行分解。

（5）重复步骤（4），直到逐层分解结束。

（6）对图进行检查和合理布局，主要检查分解是否恰当、彻底，DFD中各层是否有遗漏、重复、冲突之处，各层DFD及同层DFD之间关系是否争取及命名、编号是否确切、合理等，对错误与不当之处进行修改。

（7）和用户进行交流，在用户完全理解数据图的内容的基础上征求用户的意见。

注意事项：

（1）不要把控制流作为数据流

（2）不要标出激发条件

（3）数据流必须要么从某个加工流出、要么流入某个加工，而不能直接从外部项流向数据存储等等。

5.数据字典（对数据的定义）

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

（1）数据字典的内容

数据流、数据流分量（数据元素）、数据存储、处理

数据字典要对数据流图中出现的所有名字（数据流，加工，文件）进行定义。

数据字典的条目由三大类组成，分别是：

数据流条目、数据项条目、文件条目、加工条目（小说明）。

（2）定义数据的方法

+：

和，连接两个分量

=：

等价于

[]：

或，用|隔开分量

{}：

重复花括号内的分量0{字母或数字}7表示8位字符串

（）：

可选，即可有可无

（3）数据字典的用途

（4）数据字典的实现

6.成本/效益分析

（1）成本估计

1）代码行技术

2）任务分解技术

3）自动估计成本技术

（2）成本/效益分析方法

1）货币时间价值

F=P（1+i）n次方

2）投资回收期

3）纯收入

4）投资回收率

第三章需求分析

1.

1）需求分析目的：

可行性分析研究阶段已经粗略的描述了用户的需求，甚至还提出了一些可行的方案，但是，许多细节被忽略了，在最终目标系统中是不能忽略、遗漏任何一个微小细节的，所以，可行性研究不能代替需求分析。

需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标提出完整、准确、清晰、具体的要求。

通过需求分析，明确用户对目标软件系统在功能、性能、行为、设计约束等方面的期望，回答软件系统“必须做什么”。

开发人员准确的理解用户的要求，进行细致的调查分析，讲用户形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的需求规格说明的过程。

2）需求分析的方法：

需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成，它定义了表示系统逻辑视图和物理视图的方式，大多数的需求分析方法是由数据驱动的，也就是说，这些方法提供了一种表示数据域的机制，分析员根据这种表示，确定软件功能及其特性，最终建立一个待开发软件的抽象模型，即目标系统的逻辑模型。

2.需求分析的任务

问题识别、分析与综合导出软件逻辑模型、编写文档

它的基本任务是准确地回答“系统必须做什么？

”这个问题。

需求分析所要做的工作是深入描述软件的共能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。

需求分析的任务不是确定系统如何完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

其实现步骤如下图所示：

（1）确定对系统的综合要求

系统功能需求

系统性能需求

可靠性和可用性需求、

错处理需求

接口需求、

约束

逆向需求

将来可能提出的需求

（2）分析系统的数据需求

就是在理解当前系统“怎样做”的基础上，抽取其“做什么”的本质，明确目标系统要“做什么”，可以导出系统的详细的逻辑模型。

具体做法：

首先确定目标系统与当前系统的逻辑差别；然后将变化部分看作是新的处理步骤，对功能图（一般为数据流图）及对象图进行调整；最后有外及里对变化的部分进行分析，推断其结构，获得目标系统的逻辑模型。

通常用数据流图、数字字典和主要的处理算法描述这个逻辑模型。

分析系统的数据要求通常采用建立数据模型的方法，常常利用图形工具辅助描绘数据结构。

（3）导出系统的逻辑模型

（4）修正系统开发计划

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

（1）访谈

正式和非正式访谈、发调查表、情景分析

（2）面向数据流自顶向下求精

结构化分析:

使用数据流程图、数据字典、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档-需求规格说明书。

　结构化分析法就是面向数据流自顶向下逐步求精进行需求分析的方法，把数据流和数据存储定义到元素级

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

（4）快速建立软件原型

4．分析建模与规格说明

（1）分析建模

数据模型（ER图）、功能模型（数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能）、行为模型（状态图，指明了作为外部事件结果的系统行为）

（3）软件需求规格说明书

为了消除用自然语言书写的软件需求规格说明书中可能存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题，用形式化方法描述用户对软件系统的需求。

5.实体—联系图（数据对象及数据对象之间的关系）

（1）数据对象

一系列不同性质或属性的事务

（4）属性

数据对象的性质

（5）联系

数据对象彼此之间相互连接的方式称为联系，也称为关系

6.数据规范化

为了减少数据冗余，避免出现插入或删除异常，简化修改数据的过程，通常需要把数据结构规范化。

第一范式

第二范式

第三范式

7.状态转换图

通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

状态图还指明了作为特定事件的结果系统将做哪些动作。

（1）状态

（2）事件

（3）符号

8.其他图

（1）层次方框图:

用树形结构的一系列多层次的矩形描绘数据的层次结构。

（2）wanrnier图

（3）IPO图：

输入、处理、输出图的简称。

9.软件需求的验证：

需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。

为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。

（1）应该从下述4个方面进行验证：

1）一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。

2）完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。

3）现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。

对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。

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

（2）验证软件需求的方法

（3）用于需求分析的软件工具

RSL（需求陈述语言）

PSL/PSA（问题陈述语言/问题陈述分析程序）

第四章形式化说明技术

用自然语言描述需求规格说明，是典型的非形式化方法。

用数据流图或实体-联系图建立模型，是典型的半形式化方法。

所谓形式化方法，是描述系统性质的基于数学的技术，也就是说，如果一种方法有坚实的数学基础，那么它就是形式化的。

1.概述

（1）非形式化方法的缺点：

用自然语言书写的系统规格说明书，可能存在矛盾、二义性、含糊性、不完整性及抽象层次混乱等问题。

（2）形式化方法的优点

（3）应用形式化方法的准则

2.有穷状态机

当前状态+事件+谓词→下个状态

3.Petri网

4.Z语言

形式化的规格说明可以用数学方法研究、验证（例如，一个正确的程序可以被证明满足其规格说明，两个规格说明可以被证明是等价的，规格说明中存在的某些形式的不完整性和不一致性可以被自动地检测出来）。

此外，形式化的规格说明消除了二义性，而且它鼓励软件开发者在软件工程过程的早期阶段使用更严格的方法，从而可以减少差错。

当然，形式化方法也有缺点：

大多数形式化的规格说明主要关注于系统的功能和数据，而问题的时序、控制和行为等方面的需求却更难于表示。

此外，形式化方法比欠形式化方法更难学习，不仅在培训阶段要花大量的投资，而且对某些软件工程师来说，它代表了一种“文化冲击”。

第五章总体设计

总体设计的基本目的就是回答“概括地说，系统应该如何实现?

”这个问题，因此，总体设计又称为概要设计或初步设计。

总体设计过程两个主要阶段：

（1）系统设计阶段，确定系统的具体实现方案

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

1.设计过程

（1）设想供选择的方案

（2）选取合理的方案

（3）推荐最佳方案

（4）功能分解（结构设计及由哪些模块组成和过程设计-确定每个模块的处理过程）

（5）设计软件结构（层次图或结构图）

（6）设计数据库

（7）制定测试计划

（8）书写文档：

系统说明、用户手册、测试计划、详细的实现计划、数据库设计结果；

（9）审查和复审

2.设计原理

（1）模块化

就是把程序划分成独立命名且可独立访问的模块,每个模块完成一个子功能,把这些模块集成起来构成一个整体,可以完成指定的功能满足用户的需求.把复杂的问题分解成许多容易解决的小问题,原来的问题也就容易解决了.

模块化和软件成本关系:

根据总成本曲线,每个程序都相应地有一个最适当的模块数目M,,使得系统的开发成本最小.

（2）抽象

抽出事务的本质特性而暂时不考虑它们的细节.

（3）逐步求精

（4）信息隐藏和局部化

模块中所包括的信息不允许其它不需这些信息的模块调用

信息局部化：

是把一些关系密切的软件元素物理地放得彼此靠近

（5）模块独立

是软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中的其它的模块接口是简单的。

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

1）耦合

也称块间联系。

指软件系统结构中各模块间相互联系紧密程度的一种度量。

模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。

模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。

（a）数据耦合：

如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据。

（b）控制耦合：

模块传递的信息中有控制信息，就称作控制耦合。

（c）特征耦合：

把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素。

（d）公共耦合：

一组模块通过同一个公共数据环境相互作用，则它们之间的耦合称为公共耦合。

（e）内容耦合：

如果发生下列情形之一，两个模块之间就发生了内容耦合。

一个模块直接访问另一个模块的内部数据

一个模块不能通过正常入口转到另一模块的内部

两个模块有一部分程序代码重叠（只可能出现在汇编语言中）

一个模块有多个入口

2）内聚

又称块内联系。

指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。

若一个模块内各元素（语句之间、程序段之间）联系得越紧密，则它的内聚性就越高。

（a）偶然内聚：

如果一个模块各部分之间没有关系，或者即使有关系，这种关系也是很松散的，则称作偶然内聚。

（低内聚）

（b）时间内聚：

如果一个模块所包含的任务必须在同一时间内执行，称作时间内聚。

（低内聚）

（c）逻辑内聚：

一个模块完成的任务在逻辑上属于相同或相似的一类（低内聚）

（d）过程内聚：

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

（中内聚）

（e）通信内聚：

如果一个模块中的所有元素都使用了相同的输入数据，或产生了相同的输出数据，则称为通信内聚。

（中内聚）

（f）顺序内聚：

如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行（通常一个处理元素的输出数据作为下一个处理元素的输入数据），则称为顺序内聚。

（高内聚）

（g）功能内聚：

如果一个模块内所有处理元素属于一个整体，完成一个单一的功能，则称作功能内聚。

（高内聚）

耦合性与内聚性是模块独立性的两个定性标准，将软件系统划分模块时，尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。

模块的高内聚、低耦合的原则称为模块独立原则，也称为模块设计的原则。

3.启发规则

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

（2）模块规模应该适中

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

深度表示软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。

宽度是软件结构内同一个层次上的模块总数的最大值；一般来说，宽度越大系统越复杂。

宽度影响最大的因素是模块的扇出。

一个模块的扇入是指直接调用该模块的上级模块的个数。

一个模块的扇出是指该模块直接调用的下级模块的个数。

设计原则：

低扇出、高扇入。

（4）模块的作用域应该在控制域内

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

模块的控制域是这个模块本身以及所有直接或间接从属于它的模块的集合。

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

（6）设计单入口和单出口的模块

（7）模块功能应该可以预测

4.描绘软件结构的图形工具

（1）层次图和HIPO（层次图加输入/处理/输出图）

层次图是用来描述软件的层次结构的。

层次图

HIPO图

（2）结构图

结构图和层次图类似，都是描述软件结构的图形工具

5.面向数据流的设计方法

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

面向数据流的设计要解决的任务，就是上述需求分析的基础上，将DFD图映射为软件系统的结构。

（1）概念

变换流

事务流

数据流图的类型：

交换型结构和事务型结构

交换型结构：

由3部分组成，传入路径，变换中心，输出路径。

系统的传入流经过变换中心的处理，变换为系统的传出流。

事务型结构：

有至少一条接受路径，一个事务中心与若干条动作路径组成。

当外部信息沿着接受路径进入系统后，经过事务中心获得某个特定值，就能据此启动某一条动作路径的操作。

（2）变换分析

变换分析是一系列设计步骤的总称，经过这些步骤把具有变换流特点的数据流图按预先确定的模式映射成软件结构。

（3）事务分析

（4）设计优化

第六章详细设计

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

1．结构程序设计

2．人机界面设计

（1）设计问题

系统响应时间

用户帮助设施

出错信息处理

命令交互

（2）设计过程

（3）人机界面设计指南

一般交互指南

信息显示指南

数据输入指南

3．过程设计的工具

（1）程序流程图

（2）盒图（N-S图）

（3）PAD（问题分析图）图

（4）判定表

（5）判定树

（6）过程设计语言（PDL）

它是正文形式表示数据和处理过程的设计工具

4．面向数据结构的设计方法

（1）Jackson图

（2）改进的Jackson图

（3）Jackson方法

Jackson方法是最著名的面向数据结构的设计方法,而不是面向数据流的设计方法。

它是以信息驱动的，是将信息转换成软件的程序结构

Jackson方法的基本步骤是：

1）分析并确定输入数据和输出数据的逻辑结果，并用Jackson图描绘这些数据结构.

2）找出输入数据结构和输出数据结构中有对应关系的数据单元。

3）从描绘数据结构的Jackson图导出描绘程序结构的Jackson图

4）列出所有操作和条件（包括分支条件和循环结束条件），并且把他们分配到程序结构图的适当位置

5）用伪代码表示程序

5．程序复杂程度的定量度量

（1）McCabe方法

根据程序控制流的复杂程度定量度量程序的复杂程度，称为程序的环形复杂度。

程序的环形复杂度取决于程序控制流的复杂程度，即取决于程序结构的复杂难度。

（2）Halstead方法

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

第七章实现

通常把编码和测试统称为实现

1.编码

（1）选择程序设计语言

（2）编码风格

1）程序内部文档：

符号名的命名、程序的注释、标准的书写格式

2）数据说明:

数据说明的次序应当规范化。

使数据属性容易查找，也有利于测试，排错和维护

3）语句构造:

语句结构力求简单、直接，不能为了片面追求效率而使语句复杂化，可以从以下几点注意：

使用标准的控制结构、尽可能使用库函数、程序编写首先应该考虑清晰性、注意使用goto语句

4）输入输出:

输入/输出地方式和格式应当尽可能做到对用户友善，尽可能方便用户的使用。

5）效率：

程序效率：

程序效率是指程序的执行速度及程序占用的存储空间。

影响程序效率的因素是多方面的。

2.软件测试基础

（1）软件测试的目标：

为了发现程序中的错误而执行程序的过程

（2）软件测试的准则

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

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

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

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

5）穷举测试是不可能的。

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

（3）测试方法

1）黑盒测试：

把程序看成一个黑盒子，完全不考虑程序内部结构和处理过程

，黑盒测试是在程序接口进行的测试，它只检查程序功能能否按照规格说明书的规定正常使用，程序能否适当地接收输入数据并产生正确的输出信息。

2）白盒测试：

结构测试，把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。

（4）测试步骤

1）单元测试（模块测试）：

保证每个模块正常运行，发现编码和详细设计的错误。

2）子系统测试：

把经过单元测试的模块放在一起形成一个子系统测试。

3）系统测试：

经过测试的子系统装配成一个完整的系统来测试。

4）验收测试（确认测试