学业辅导精编版-4软件工程复习

软件工程软件工程导论第一章软件工程学概述§1.2软件工程§1.2.1软件工程发展历史“软件工程”术语首次出现：1968年NATO会议软件工程方法:是采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。软件危机的主要特征软件开发周期大大超过规定日期;软件系统开发成本高，周期长，质量差，满足不了市场需求;

软件质量无保证软件系统开发人员数量少，质量低．软件系统维护难度大．软件开发缺乏合适的工具和方法软件工程

(softwareengineering)

软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴传统工程的原则、方法，以提高质量，降低成本为目的。软件工程为了经济地获得可靠的和能在实际机器上高效运行的软件而建立合使用的好的工程原则。

软件工程是一门交叉学科软件开发模型软件开发方法软件立项到终止的全过程软件开发工具软件开发环境计算机辅助软件工程（CASE）软件工程管理软件工程经济学？软件工程的主要研究内容软件工程技术主要强调：

规范化文档化§1.3软件生存周期软件生存周期

(SoftwareLifeCycle)软件产品或软件系统从提出、设计、投入使用到被淘汰的全过程。软件系统开发方法结构化开发方法（瀑布模型）快速原型方法面向对象开发方法ＣＡＳＥ方法(UML)1软件工程和软件生命周期

2

软

件

生

存

期

的

步

骤(1)制定计划(2)需求分析和定义(3)软件设计(概要、详细）(4)程序编写(5)软件测试(6)运行/维护软件生存期的阶段划分(国标《计算机软件开发规范》)(1)可行性研究与计划(2)需求分析(3)总体设计上游(4)详细设计(5)实现(6)集成测试(7)确认测试下游(8)使用和维护软件生存期模型可归结为三大类

瀑布模型原型模型

OO模型1.瀑布模型(线形顺序模型)可行性研究与计划需求分析设计编码运行维护测试定义阶段开发阶段维护阶段原型化软件生存期模型系统需求分析定义生成原型系统设计程序设计编码测试

运行和维护原型化含原型化的软件生存期分析增量模型设计编码测试分析设计编码测试分析设计编码测试分析设计编码测试增量1增量2增量3增量4交付的增量1交付的增量2交付的增量3交付的增量4日历时间第二章系统分析

§2.1问题定义

弄清用户需要计算机解决的问题根本所在，及项目所需的资源和经费。第三章软件需求分析§3.1需求分析的任务

准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用<需求规格说明书>规范的形式准确地表达用户的需求。§3.4分析建摸结构化分析（传统建模方法）面向对象分析§3.4.1结构化分析方法(StructuredAnalisys,SA)

基于数据流技术的分析方法

需求分析应遵循的二条基本原则：

分解抽象需求分析模型的元素数据流图(DFD)

指明数据在系统中移动时如何被变换;描述对数据流进行变换的功能;DFD中每个功能的描述包含在加工规约

(小说明)。数据字典(DD)：模型核心(中心库)E-R图(ERD)：状态变迁图(STD)

指明作为外部事件的结果,系统将如何动作。S2132.22.12.33.13.2

顶层（不编号）0层1层(基本系统模型)(系统的子功能)DFD的层次分解

数据字典

(DD，DataDictionary)DFD中的数据流、数据存储表示某个有组织的数据集合，它们要由SA的其他描述工具-需求字典（数据字典）来描述。

数据字典的作用词条描述数据结构描述加工逻辑说明定义式中使用的符

操作符含义描述

＝定义为＋与(顺序结构)

｛...｝重复(循环结构)〔..｜..〕或(选择结构)〔..,..〕(...)任选

m..n界域＊...,＊注释符限制重复次数举例:｛35或53｛｝表示允许重复3-5次｛｝33或33｛｝表示恰好重复3次｛｝｛｝｛｝1表示至少出现1次表示允许重复0至任意次第四章软件设计§4.1软件设计的目标和任务

软件需求：解决“做什么”软件设计：解决“怎么做”1软件设计的任务问题结构(软件需求)软件结构从软件需求规格说明书出发，形成软件的具体设计方案。映射5.软件设计分为两个阶段(1)概要设计(总体设计)

确定软件的结构以及各组成成分

(子系统或模块)之间的相互关系。(2)详细设计

确定模块内部的算法和数据结构，产生描述各模块程序过程的详细文档。4.软件设计方法结构化设计方法(SD)面向数据结构的设计方法(JSD方法)面向对象的设计方法(OOD)§4.2软件设计基础

1.软件结构

2.软件过程

3.分解

4.抽象

5.模块化

6.信息隐蔽

7.信息局部化控制结构(程序结构)深度宽度扇出扇入(模块的层数)(同一层最大模块数)(一个模块直接调用的模块数)(调用一个给定模块的模块个数)软件质量因素：

可理解性

可维护性可靠性效率信息隐蔽的目的：

提高模块的独立性，减少修改或维护时的影响面。§4.3模块的独立性4.3.1模块独立性的概念模块独立的含义：模块完成独立的功能符合信息隐蔽和信息局部化原则模块间关连和依赖程度尽量小4.3.2模块独立性的度量

模块独立性取决于模块的内部和外部特征。SD方法提出的定性的度量标准：

模块之间的耦合性模块自身的内聚性1.模块独立性的度量之一：

耦合性是模块间相互依赖程度的度量，耦合的强弱取决于模块间接口的复杂程度，进入或访问一个模块的入口点，以及通过接口的数据。耦合性越高，模块独立性越弱

耦合强度依赖的因素：一模块对另一模块的引用一模块向另一模块传递的数据量一模块施加到另一模块的控制的数量模块间接口的复杂程度模块间耦合的类型：

低非直接耦合耦数据耦合合标志耦合性控制耦合外部耦合公共耦合

高内容耦合模块独立性弱(低耦合)强(中耦合)(较强耦合)(强耦合)模块的内聚性类型：低巧合内聚内逻辑内聚聚时间内聚性过程内聚通信内聚信息内聚高功能内聚模块独立性弱(功能分散)强(功能单一)4.4.1层次图和HIPO图IBM公司发明的HIPO图：层次图

+输入/处理/输出图

(H图)+(IPO图)(HierachyInputProcessOutput)§4.4结构化设计中的图形工具层次图、HIPO图、结构图4.4.2结构图SC(StructureChart)SD方法在概要设计中的主要表达工具约定编辑学生记录读学生记录学生数据无此学生学号不加区分的数据数据信息控制信息SC中的四种模块传入模块(a)(b)AA传出模块BB变换模块(c)CD协调模块E(d)EFFSC中的选择调用ACBDA根据内部判断决定是否调用BA按另一判定结果选择调用C或DSC中的循环调用ABCA根据内在的循环重复调用B、C等模块§4.5概要设计的方法结构化设计方法(SD)国际上应用最广，技术上比较完善的系统设计方法。结构化设计方法(SD)是以数据流图为基础的，它定义了把数据流图变换成软件结构的不同映射方法，所以这种方法也称为面向数据流的设计方法。4.5.1面向数据流的设计方法1.面向数据流设计方法的基本概念面向数据流的设计要解决的任务：

映射

DFD软件系统的结构软件系统软件结构的逻辑模型初始结构描述系统结构特征可归纳为两种典型形式变换型结构事物型结构(1)变换型结构由输入、变换中心和输出三部分组成。基本模型：变换中心输入路径输出路径变换型数据流图输入信息物理输入格式检查处理显示正确信息结果物理输出数据变换中心输出逻辑输入逻辑输出输入具有明确的输入、变换(或称主加工)和输出界面的DFD(2)事务型结构特征：具有在多种事物中选择执行某类事物的能力基本模型：事务中心接受路径动作路径大型系统DFD中,变换型和事务型结构往往共存:T事务中心传入变换传出AFBCEMDG模块的作用范围和控制范围:条件判定模块A的作用范围:

A、

B、C、

D、E、F作用范围/控制范围原则:把一个条件判定的作用范围限制在判定所在模块的控制范围之内。(作用域是控制域的子集)(1)将包含条件判定的模块合并到它的调用模块中，使判定处于较高位置。(2)将接受判定影响的模块下移到控制范围内。(3)增加模块的重用性(4)减少高扇出，争取高扇入修改模块结构方法：4.6详细设计的描述方法详细设计工具：(1)图形工具(2)表格工具(3)语言工具

程序设计工具程序流程图盒图(N-S图)问题分析图(PAD)4.过程设计语言(PDL)(伪码)5.判定表结构程序设计的特点：

①自顶向下逐步求精；②具有单入、单出的控制结构（取消GOTO语句）§1.工具

1、程序流程图(ProgramFlowChart)5种基本控制结构为：(1)顺序结构(sequentialstructure)(2)选择结构(selectivestructure)ABPBAFT(3)先判定型循环结构(while-loopstructure)(4)后判定型循环结构(until-loopstructure)TPSFFSTP(5)多情况选择(casestructure)TA1FP=1TA2FP=2…TAnFP=n用户友好性的标志可操作性健壮性易学习性可扩展性§6.8程序编码

程序的特点及对软件质量影响：1)一致性：表示语言所使用符号的兼容性2)无二义性：设计对程序的正确理解。3)简洁性：体现程序员掌握语言必须记忆的代码的信息总量。4）局部性：语言的联想特性5）线性：涉及对程序的理解

程序风格应遵循的规则：简洁化、模块化、简单化、结构化、文档化、格式化

程序设计风格1.代码文件选择有意义的标识符安排注释（绪言性、功能性、标题、作者、调用形式、参数说明….）2.视觉形式数据说明说明次序要规范化利用数据类型对数据值进行防范3.语句语句应当简明和直接了当，不要追求奇技怪巧使用标准的控制语句尽量不用测试条件的”非”不要利用复杂的算符优先级，用括号更清晰对递归定义的数据结构使用递归过程避免不必要的goto语句不要修修补补不好的程序，要重新写4.输入和输出逻辑地组织输入，有效的出错检查有提示的输入方式，自由格式输入对产生重大后果的输入，给出醒目的提示，待用户确认后在执行合理，整齐，有层次，美观的输出形式7.1.1测试的目的与地位G.J.Myers在<软件测试技巧>中认为:“程序测试是为了发现错误而执行程序的过程.”

E.W.Dijkstra指出:“程序测试能证明错误的存在,但不能证明错误不存在.”

测试的目的是发现程序中的错误,是为了证明程序有错,而不是证明程序无错.测试与开发前期工作的关系决定软件与系统的配合关系需求分析概要设计详细设计

编码单元测试集成测试确认测试系统测试测试阶段工作步骤单元测试:检验每个模块能否单独工作.集成测试:检验概要设计中模块接口设计问题确认测试:以需求规格说明书为检验尺度系统测试:综合检验测试可视为分析、设计、编码三个阶段的最终复审,以保证软件质量.7.1.4测试的方法与技术软件测试的策略和方法静态测试方法动态测试方法人工测试方法计算机辅助静态分析方法白盒测试方法黑盒测试方法穷举测试方法逻辑覆盖准则: (1)语句覆盖(2)判定覆盖(3)条件覆盖(4)判定/条件覆盖(5)条件组合覆盖(6)路径覆盖(7)点覆盖(8)边覆盖§7.4黑盒测试的测试用例设计7.4.1等价类划分法把所有可能的输入数据(有效的和无效的)划分成若干个等价的子集(称为等价类)；使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同.可从每个子集中选取一组数据来测试程序。被测试子域测试内点测试外点7.4.2边界值分析法边界值分析法与等价类划分法区别(1)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。(2)边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况7.4.3错误推测法

(错误推测法errorguessing)

根据经验来设计测试用例的方法例举出程序中可能有的错误和容易发生错误的特殊情况，根据它门选择测试方案用因果图法生成测试用例的步骤(1)分析哪些是原因，哪些是结果，给每个原因、结果一个标识。(2)分析语义，找出原因与结果、原因与原因之间的关系，画出因果图。(3)在因果图上标明约束或限制条件。(4)把因果图转化为判定表。(5)根据判定表每一列设计测试用例。软件测试的过程被测模块单元测试设计信息集成测试被测模块单元测试被测模块单元测试测试过的模块确认测试系统测试软件需求其它系统元素装配好的软件

确认的软件可运行的软件§7.6软件测试的步骤模块错误处理模块接口局部数据结构

重要的执行路径边界条件7.6.1单元测试一.单元测试的内容主要对模块的五个基本特性进行评价二.单元测试的方法单元测试一般为编码步骤的附属部分.模块不是独立的程序,自己不能运行,要靠其它部分来调用和驱动,要为每个单元测试开发两个软件:(1)驱动模块(驱动程序):相当于主模块(2)桩模块(连接程序):代替所测模块调用的子模块深度优先广度优先自顶向下结合自底向上结合集成测试方法通常采用黑盒测试技术实施策略:非渐增式测试渐增式测试

一.非渐增式集成方式一次就把所有通过了单元测试的模块组合在一起进行全程序的测试.缺点:发现错误难以诊断定位.

二.渐增式集成方式

从一个模块开始,测一次添加一个模块，边组装边测试，以发现与接口相联系的问题。1.自顶向下结合

步骤:(1)主控模块为驱动模块,所有直属主模块的下属模块全用桩模块代替,测试主模块.(2)根据所选结合方法(先深度或先广度),

每次用一实际模块替换相应桩模块.(3)模块结合一个,测试一个.(4)完成一组测试后,用实际模块替换另一个桩模块.(5)为保证不引入新错误,进行回归测试2.自底向上结合步骤:(1)对叶模块配以驱动模块对其测试，也可把最底层模块组合成实现某一特定软件功能的簇，由驱动模块对它测试。(2)用实际模块代替驱动模块,与它已测试的直属模块组装成子系统。(3)为子系统配备驱动模块,进行新的测试。(3)判断是否已组装到达主模块是则结束，否则执行(2）.对源程序进行静态分析的方法：(1)桌前检查检查变量、标号的交叉引用检查子程序、宏、函数、常量检查标准、风格检查(2)代码会审(3)走查四.确认测试结果测试完成后可能出现两种情况:(1)测试与预期相符,可接受.(2)不相符,列出软件缺陷表,与用户协商解决.五.α测试和β测试α测试(Alpha)

在开发者的场所由用户进行,在开发者关注和控制的环境下进行.β测试(Beta)

最终用户在自己的场所进行.7.6.4系统测试软件只是计算机系统的一个元素软件最终要与其他系统元素（如新硬件、信息等)相结合，进行各种集成测试和确认测试.用于系统测试的测试类型:(1)恢复测试(2)安全性测试(3)强度测试(4)性能测试§7.6调试(纠错技术)

测试是找出软件错误的过程，调试是确定错误的位置、性质并纠正。调试的困难在于错误的定位.7.7.1排错策略方法一.强行（蛮力）排错(bruteforce)常见形式:(1)打印出所有存储内容、代码(2)程序中设打印语句效率最低(3)用自动纠错工具（sdb）二.消去原因(causelimination)列出可能原因,逐个排除,找出问题(1)试探法(2)归纳法(3)演绎法(4)回溯法(5)对分查找法7.7.2修改错误原则注意错误的群集现象，在错误近邻检查。找到错误的本质并修改采用回归测试，避免因修改引起的新错误。修改源程序。维护的定义在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。维护的种类A:①诊断和改正错误——改正性维护(correctivemaintenance；②为了和变化了的环境（如软\硬件升级、新数据库等）适当地配合而修改软件——适应性维护(adaptivemaintenance)；第八章维护(Maintenance)③为了增加新功能，修改已有功能，改造界面，增加HELP等，而修改软件——完善性维护（perfectivemaintenance),；④为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件——预防性维护(preventivemaintenance)。§1.定义注：①一般维护的工作量占生存周期70%以上，维护成本约为开发成本的4倍(80-20Rule)；②文档维护与代码维护同样重要。

§4.可维护性(Maintainability)的度量

软件可维护性可定性地定义为：维护人员理解、改正、改动和改进这个软件的难易程度。1、用于衡量可维护性的软件特性：⑴可理解性(Understandability)

是指由文档代码理解功能运行的容易程度。对外又称

userfriendliness.

好程序的特征：模块化、结构化、代码与设计风格一致，高级语言实现。⑵可测试性(Testability)

是指论证程序正确性的容易程度。好程序的特征：可理解、可靠、简单。度量方法：程序复杂度§4.可维护性⑶可修改性(Reparability)

是指程序容易修改的程度。好程序的特征：可理解、简单、通用。度量方法：§4.可维护性⑸可移植性(Portability)

是指程序被移到一个新环境的容易程度。好程序的特征：结构好，不特别依赖于某一具体的计算机或操作系统。其中：D=修改难度；A

=要修改的模块的复杂度；

C

=所有模块的平均复杂度。

D

1表示修改很困难。⑷可靠性（reliability）⑹可使用性（workability）⑺效率(Efficiency)

是指程序能执行预定功能，而又不浪费机器资源（包括内存、外存、通道容量、执行时间等等）的程度。2、文档——影响可维护性的决定因素，比代码更重要。⑴用户文档：①功能描述——说明系统能做什么；§4.可维护性②安装文档——说明安装系统的方法及适应特定的硬件配置的方法；③使用手册——说明使用方法以及错误挽救方法；④参考手册——详尽描述用户可使用的所有系统设施以及它们的使用方法；给出错误信息注解表；⑤操作员指南（如果需要有系统操作员的话）——说明操作员处理使用中出现的各种情况的方法。⑵系统文档：即软件生产过程中每一步产生的文档。

什么是UML？UML:统一建模语言（UnifiedModelingLanguage）UML是用于描绘软件蓝图的标准语言.它可用于对软件密集型系统进行视化（visualize）说明(specify)建造(construct)建档(document)这也是对软件系统进行建模的四个目的UML模型的分类静态结构(Staticstructure):描述模型的组成元素及其之间的关系用例图--UseCaseDiagram类图--ClassDiagram对象图--ObjectDiagram组件图ponentDiagram部署图--DeploymentDiagram动态行为(Dynamicbehavior):描述模型元素的生命周期和他们之间的相互协作的方式时序图--SequenceDiagram协作图--CollaborationDiagram状态图--StatechartDiagram活动图--ActivityDiagramUML模型详解UML中的关系关联关系Association依赖关系Dependency泛化关系Generalization实现关系RealizationUML模型详解UML中的关系关联关系Association关联是一种结构化的关系，只一种对象和另一种对象有联系关联用一条实线表示关联可以有方向，表示该关联在某个方向上被使用；单向关联、双向关联UML模型详解UML中的关系依赖关系Dependency对于两个对象X、Y，如果X发生变化，引起对另一个对象Y的变化，则称Y依赖于X。依赖用一条带箭头的虚线表示UML模型详解UML中的关系泛化关系–Generalization描述一般事物与特殊事物之间的关系对于类，可以理解为继承关系多态UML模型详解UML中的关系实现关系–Realization描述‘规格说明’及其实现之间的关系常用来规定接口和实现它的类或组件之间的关系UML模型详解UML中的图DiagramsUML中的图有9种，主要分为两类静态图用例图Usecase、类图Class

、对象图object、组件图Component、部署图