《软件工程》第一章软件工程学概述.docx
《《软件工程》第一章软件工程学概述.docx》由会员分享,可在线阅读,更多相关《《软件工程》第一章软件工程学概述.docx(16页珍藏版)》请在冰豆网上搜索。
《软件工程》第一章软件工程学概述
第一章软件工程学概述
1.1软件危机
1.1.1软件的定义
——定义:
软件=“完成特定功能的程序+数据结构+文档”
——特征:
(3个)软件是开发的,而不是制造的;软件不磨损,但退化;自定义。
——发展问题
1.1.2软件危机的表现
——定义:
在计算机软件的开发和维护过程中所遇到的一系列严重的问题。
——表现:
(6个)
(1)对软件开发成本和进度的估计常常很不准确。
(2)软件产品质量较差,可靠性低。
(3)用户对开发出来的软件产品不满意。
(4)软件常常是不可维护的。
(5)软件产品缺少应有的文档资料。
(6)软件产品的供不应求。
1.1.3软件危机的原因
——客观原因
——主观原因
1.2软件工程
1.2.1软件工程的概念
——定义:
指导软件开发与维护的工程科学。
采用工程的概念、原理、技术和方法来开发和维护软件,综合运用正确的管理技术和最好的技术方法,以经济地开发出高质量的软件并有效维护它。
IEEE的定义:
①软件工程是把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程,也就是把工程应用于软件;②对这些途径加以研究。
1.2.2软件工程的基本原理(7个)
——
(1)用分阶段的生命周期计划严格管理
(2)坚持进行阶段评审
(3)实行严格的产品控制
(4)采用现代程序设计技术
(5)结果可以清楚地审查
(6)开发小组成员少而精
(7)承认不断改进软件工程实践的必要性
1.2.3软件工程方法学:
3个要素(方法、工具和过程)
——传统方法学:
结构化技术,软件生命周期
——面向对象方法学:
类+对象+继承+消息,软件开发过程更接近人类认知模式
1.3软件生命周期
1.3.1软件生命周期的概念
——定义:
一个软件从定义、开发、使用和维护,直至最终被废弃,要经历的漫长的时期称为软件生命周期。
——构成:
3个时期,8个阶段
软件定义:
问题定义,可行性研究,需求分析
软件开发:
总体设计,详细设计,编码和单元测试,综合测试;
运行维护:
软件维护
1.3.2各阶段的基本任务(8个阶段)
——问题定义:
需要解决的问题是什么?
书面报告
——可行性研究:
确定软件系统是否值得去解《可行性研究报告》
——需求分析:
解决这些问题需要系统做什么?
《软件需求规格说明书》
——总体设计:
应该怎样实现目标系统?
《概要设计说明书》
——详细设计:
如何具体地实现这个系统?
——编码和单元:
写代码,测试每个模块!
——测试、综合测试:
通过各类测试和调试来完善软件《测试计划/方案》
——软件维护:
通过各种必须的维护活动使系统持久地满足用户的需要。
(改正性维护,适应性维护,完善性维护,预防性维护)
1.3.3软件生命周期的模型
——瀑布模型:
广泛采用,顺序严格,文档驱动,执行困难
——原型模型:
快速开发原型后,评价反馈、再细化改进,忽略整体设计,
——增量模型:
渐进开发,逐步完善,第一个增量很关键
——喷泉模型:
面向对象软件开发过程迭代和无缝
——螺旋模型:
有效降低风险的渐进式开发模型
第二章可行性研究
2.1可行性研究的目标与任务
2.1.1目标:
用最小的代价和尽可能短的时间判断问题是否值得去解?
2.1.1任务:
——技术可行性
——经济可行性
——操作可行性
——社会可行性
2.2可行性研究过程
(1)复查系统规模与目标
(2)研究目前正在使用的系统
(3)导出新系统的高层逻辑模型
(4)导出与评价各种方案
(5)推荐行动方针
(6)草拟开发计划
(7)书写文档提交审查——《可行性研究报告》
2.3可行性研究工具
——系统流程图:
用来描述物理系统概貌
系统流程图:
表达数据在系统各部件之间流动的情况
程序流程图:
对数据进行加工处理的控制过程
——数据流图DFD:
描绘数据在软件中流动和被处理的逻辑过程
2.4成本/效益分析:
从经济角度评价开发一个新的软件工程项目是否可行
——成本估计
……代码行技术
……任务分解技术
……自动估计成本技术
——效益分析:
有形效益,无形效益
——常用的效益度量方法
……货币的时间价值
……投资回收期
……纯收入
第三章需求分析
3.1需求分析的任务和步骤
——需求分析的任务
……确定对系统的综合要求
……分析系统的数据要求
……建立软件的逻辑模型
——确定对系统的综合要求
……功能性需求
……非功能性需求:
可用性,可靠性……
——分析系统的数据要求
……数据字典——定义数据
……层次方框图——定义数据结构
——建立软件的逻辑模型:
数据流图、数据字典、实体-联系图、主要算法
——编写软件需求规格说明书
——需求分析评审
3.2需求获取的常用方法(5个)
——访谈
——问卷调查
——观察用户工作流程
——建立联合分析小组
——快速原型法
3.3需求分析的方法(4个)
——功能分解法:
软件需求当做一棵倒置的功能树
——结构化开发方法:
结构化分析、结构化设计和结构化程序设计
——信息建模方法:
实体-联系图
——面向对象的分析
3.4结构化分析技术
——思路:
基于数据流图自顶向下逐层分解
3.5需求分析图形工具
——实体-联系图(Entity-RelationshipDiagram)
……实体定义:
对软件必须理解的复合信息的抽象
……属性定义:
数据对象的性质
……联系定义:
数据对象彼此之间相互连接的方式
——数据字典
……定义:
数据字典是关于数据的信息的集合,也就是对数据流图中包含的所有元素的定义的集合。
……四类元素:
数据流,数据流分量(即数据元素),数据存储,处理
——层次方框图
……定义:
用树型结构的一系列多层次的矩形框描绘数据的层次结构。
——IPO图(InputProcessOutput)
第4章总体设计
4.1总体设计的目标及任务
——基本目的:
解决“系统应该如何实现”的问题
——系统设计阶段:
确定系统的具体实现方案
——结构设计阶段:
确定系统的软件结构
……任务1.设计软件结构
……任务2.数据结构及数据库设计
……任务3.确定测试要求并制定测试计划
……任务4.编写总体设计文档《概要设计说明书》
……任务5.评审
4.2软件结构设计原理
4.2.1模块化
——模块
……定义:
是构成程序的基本单位,数据说明、可执行语句等程序对象的集合,或者是单独命名和编址的元素(如函数、子程序、过程)等。
——模块化
……定义:
解决一个复杂问题时自顶向下逐层把软件系统划分成若干个独立命名、且可独立访问的模块的过程。
每个模块完成一个特定的子功能,所有的模块按某种方法组装起来,成为一个整体,完成整个系统所要求的功能。
——模块的基本属性
……外部属性:
接口,功能,状态
……内部属性:
逻辑
4.2.2抽象:
逐步求精
——定义:
抽出事物本质特性而不考虑细节
4.2.3信息隐藏和局部化
——信息隐藏原理定义:
设计和确定模块时,使得一个模块内包含的信息对于不需要这些信息的模块来说,是不能访问的。
——局部化定义:
把一些关系密切的软件元素物理地放得彼此靠近
4.2.4模块独立性
——模块独立定义:
每个模块完成一个相对独立的特定子功能,并且和其他模块之间的关系很简单。
——模块独立性的定性标准度量:
……耦合:
(1)定义:
软件系统结构中各模块间相互联系紧密程度的一种度量。
模块之间联系越紧密,其耦合性就越强,模块的独立性则越差。
(2)分类:
无直接…数据…控制…特征…公共…内容
……内聚:
(1)定义:
一个模块内部各个元素彼此结合的紧密程度的度量。
(2)分类:
偶然…逻辑…时间…过程…通信…顺序…功能
……原则:
力争做到高内聚,并且能辨认出低内聚的模块,通过修改设计提高模块的内聚程度并降低模块间的耦合程度。
4.3软件结构设计工具
——层次图
——HIPO图:
带编号的层次图
——软件结构图
4.4软件结构设计启发式规则
——作用域定义:
指受该模块内一个判断影响的所有模块的集合
——控制域定义:
指模块本身以及其所有直接或者间接从属于它的模块集合
——原则:
好的设计:
所有受判定影响的模块应该都从属于做出判定的那个模块,最好局限于做出判定的那个模块本身及它的直属下级模块。
——深度:
指软件结构中模块的层次数
——宽度:
指同一层次中最大的模块个
——扇出:
指一个模块直接调用的模块数目,一般是3-4,不能超过5-9
——扇入:
指有多少个上级模块直接调用它
4.5结构化设计方法
4.5.1数据流图的类型
——变换型数据流图
——事务型数据流图
4.5.2结构化设计方法过程
4.5.3变换型分析设计
4.5.4事务型分析设计
4.5.5综合型数据流图
第5章详细设计
5.1详细设计的目的与任务
——处理方式的设计(数据结构、算法、性能、外部信号形式)
——为数据库进行物理设计
——其它设计(IO格式,人机对话格式)
5.2详细设计方法
5.2.1结构化程序设计(StructuredProgramming,SP)方法
——单入单出结构:
顺序、选择和循环,goto语句
——基本思路
……自顶向下、逐步细化
……模块化设计
……结构化编码
5.2.2面向数据结构的设计方法
——Jackson图
——改进的Jackson图
——Jackson方法
5.3详细设计工具
5.3.1程序流程图
5.3.2盒图
5.3.3PAD问题分析图
5.3.4PDL过程设计语言
5.3.5判定表与判定树
第6章实现
目的:
使用选定的程序设计语言,把模块的过程性描述翻译为用该语言书写的源程序
6.1程序设计语言的分类
——面向机器语言:
机器语言,汇编语言
——高级语言:
通用语言,专用语言
6.2程序设计语言的选择
6.3编码风格
——定义:
编码风格是指在不影响程序正确性和效率的前提下,有效编排和合理组织程序的基本原则。
6.3.1程序内部文档
——标识符,程序的注解,语句,输入和输出
6.3.2语句的构造及书写
6.3.3输入/输出
6.3.4效率
6.4程序复杂度度量
6.4.1McCabe方法——环形复杂度度量
6.4.2Halstead方法——文本复杂度度量
第7章软件测试
7.1软件测试目标
——测试是为了证明程序有错,而不是证明程序无错误
7.2软件测试准则(6个)
——所有测试都应该能追溯到用户需求
——测试开始之前制定测试计划
——Pareto原理可应用于软件测试
——从小规模测试开始,并逐步进行大规模测试
——穷举测试是不可能的
——由独立的第三方从事测试工作
7.3软件测试方法
——测试时是否需要执行被测软件
……静态测试定义:
对被测程序进行特性分析的方法的总称,这些方法的主要特性是无须执行被测代码,而是借助专用的软件测试工具评审软件文档或程序,度量程序静态复杂度,检查软件是否符合编程标准,借以发现编写的程序的不足之处,减少错误出现的概率。
……动态测试定义:
实际运行被测程序,通过输入相应的测试用例,判定执行结果(输入/输出的对应关系)是否符合要求,从而检验程序的正确性、可靠性和有效性。
——测试是否针对内部结构和具体实现算法
……黑盒测试定义:
是一种从用户观点出发的测试。
用这种方法进行测试时,把被测程序当作一个黑盒,不考虑程序内部结构和特性,测试者只考虑程序输入输出和程序功能,根据需求规格说明书来设计测试用例,推断测试结果的正确性
……白盒测试定义:
依赖于对程序内部细节的严密检验,针对特定条件设计测试用例,对软件的逻辑路径进行测试。
……灰盒测试
7.4软件测试过程
7.4.1单元测试
——定义:
将每个模块作为一个独立的实体来测试。
用详细设计描述作指南,对重要的程序执行通路进行测试,以便发现模块内部的错误。
发现编码和详细设计的错误。
——驱动模块,桩模块(存根程序)
7.4.2集成测试
——定义:
按照概要设计的要求组装独立模块成为子系统或系统,同时经过测试来发现接口错误的一种系统化的技术。
——模式:
……非渐增式测试方法(分模块测试→一次性组装→所有模块集成测试)
……渐增式测试方法(分模块测试→逐个模块组装→直到集成测试)
●自顶向下集成(深度优先策略,宽度优先策略)
●自底向上集成
●三明治集成
7.4.3系统测试
——定义:
系统测试是指将经过集成测试的软件作为整个基于计算机系统的一个元素,与计算机硬件、外设、支持软件、数据和人员等元素结合在一起,对计算机系统进行一系列的组装测试和确认测试。
系统测试的依据是软件需求规格说明书,测试的内容主要包括功能测试和性能测试两方面。
——测试内容:
功能测试,性能测试
7.4.4确认测试
——定义:
确认测试又称“验收测试”、“有效性测试”,其任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
——分类:
Alpha测试(开发者+用户),Beta测试(用户+开发者)
7.4.5回归测试
——定义:
重新执行已经做过的测试的某个子集,以保证上述这些变化没有带来非预期的副作用。
——作用:
保证由于调试或其他原因引起的变化,不会导致非预期的副作用。
7.5测试用例的设计
7.5.1测试用例的设计原则
7.5.2白盒测试方法用例的设计
——逻辑覆盖
……语句覆盖:
程序中每个可执行语句至少执行一次
……判定覆盖:
使得程序中每个判断的取真分支和取假分支至少经历一次,即判断真假值均曾被满足
……条件覆盖:
使每个判断中每个条件的可能取值至少满足一次
……判定条件覆盖:
使得判断条件中的所有条件可能至少执行一次取值,同时所有判断的可能结果至少执行一次
……条件组合覆盖:
使得每个判定表达式中条件的各种可能组合都至少执行一次
……路径覆盖:
覆盖程序中的所有可能的执行路径
——循环覆盖
……单循环
……嵌套循环
——基本路径测试
7.5.3黑盒测试方法用例的设计
——等价类划分
……有效等价类定义:
指对于程序的规格说明来说,是合理的有意义的输入数据构成的集合
……无效等价类定义:
是指对于程序的规格说明来说,是不合理的,是无意义的输入数据构成的集合
——边界值分析
——错误推测
——因果图法
7.6软件调试
——试探法
——回溯法
——对分查找法
——归纳法
——演绎法
第8章维护
8.1软件维护的定义
——在交付使用后,为改正错误或满足新需要而修改软件的过程。
8.2软件维护的分类
——改正性维护
——完善性维护
——适应性维护
——预防性维护
各类维护活动都必须应用于整个软件配置,包括维护文档和维护软件的可执行代码。
8.3软件维护的特性
8.3.1软件维护的困难
——结构化维护定义:
指软件开发过程是按照软件工程方法进行的、各开发阶段文档齐全的软件的维护过程。
修改从设计文档开始,到编写源代码和回归测试,再次交付使用。
——非结构化维护定义:
指在只有源程序,缺乏必要的文档说明,难于确定数据结构、系统接口等特性的情况下,进行的软件维护过程。
8.3.2维护代价高昂
8.3.3软件维护的副作用
——修改代码的副作用
——修改数据的副作用
——修改文档的副作用
8.4软件维护过程
——本质:
修改和压缩了的软件定义和开发过程
——过程
……
(1)维护组织
……
(2)维护报告
……(3)维护的事件流
……(4)保存维护记录
……(5)评价维护活动
8.5软件的可维护性
——定义:
软件的可维护性是指维护人员理解、改正、改动或改进这个软件的难易程度,它是软件质量的主要特征之一。
8.6提高可维护性的途径
第9章面向对象的技术
9.1面向对象方法学
——基本思想:
尽可能模拟人类习惯的思维方式,使开发软件的方法与过程更接近人类认识世界、解决问题的方法与过程。
9.1.1两种方法学的比较(传统的程序设计技术、面向对象的软件技术)
——与人类习惯的思维方法一致
——系统稳定性好
——可重用性好
——较易开发大型软件产品
——可维护性好
9.1.2面向对象的基本概念
——对象定义:
一个包含数据结构和施加其上的操作的封装体
——类定义:
对一组具有相同属性和运算的对象的抽象
——继承定义:
是父类和子类之间共享数据结构和方法的机制
——多态性定义:
指相同的操作或函数、过程作用于不同的对象上并获得不同的结果
——消息定义:
指对象之间在交互中所传送的通信信息
9.1.3面向对象的开发方法
——Booch方法
——Coad方法
——OMT(ObjectModelingTechnology,对象建模技术)
——UML(UnifiedModelingLanguage,统一建模语言)
9.2面向对象的实施步骤
——面向对象分析OOA
——面向对象设计OOD
——面向对象实现OOP
——面向对象测试OOT
9.3面向对象的建模语言—UML
9.3.1UML的特点
9.3.2UML的构成
——视图(4+1):
用例视图+设计视图、过程视图、实现视图、配置视图
——图
——模型元素
——通用机制
9.3.3UML的通用模型元素
——关联、泛化、依赖、聚合、细化、组合
第10章面向对象的需求分析
10.1用例图
——元素:
参与者、用例、关系(包含、扩展、泛化)
10.2用例建模的步骤
——步骤1:
定义系统边界
——步骤2.确定参与者
——步骤3.识别用例
——步骤4.确定用例之间的关系
——步骤5.建立完整的用例图
——步骤6.书写用例描述文档
第11章面向对象的分析
11.1面向对象分析的任务
——分析的过程:
提取系统需求,开发分析模型
——分析工作内容:
理解,表达,验证
——文档资料:
软件需求规格说明
——中心任务:
从需求模型中导出分析模型
——分析模型由3个独立模型构成:
……用例模型:
表示系统功能,用例和场景
……对象模型:
表示系统组成,类和对象图
……动态模型:
表示用例实现,协作图和顺序图
11.2静态结构建模
——静态分析是分析静态模型(类图或对象图)
——静态结构建模过程:
……提取系统中的类(在用例中寻找类)
……添加关系
……确定类的属性
……确定类的操作
……完善初始的静态结构模型
11.3动态结构建模
——动态分析是分析动态模型(顺序图或协作图)
——动态行为建模的过程:
……
(1)消息
……
(2)事件序列图
……(3)状态转换图
……(4)活动图
……(5)协作图
第12章面向对象的设计与实现
12.1面向对象设计准则
——模块化
——抽象
——信息隐藏
——弱耦合:
交互耦合(松散好),继承耦合(紧密好)
——强内聚
——可重用
12.2面向对象启发规则
12.3面向对象的实现
12.4面向对象的软件测试
12.4.1测试类型
——面向对象分析测试:
分析、验证对象及其关系的合理性、可行性
——面向对象设计测试:
确定类和类结构满足要求
——面向对象编程测试:
类功能的实现和相应的面向对象程序风格
——面向对象单元测试:
对类及其实例的测试
——面向对象集成测试:
基于线程的测试,基于使用的测试
——面向对象系统测试:
检测软件的整体行为表现,是对软件开发设计的再确认
——面向对象确认测试:
集中检查用户可见的动作和用户可识别的输出
12.4.2测试用例的设计
——测试类的方法
……随机测试:
不考虑对类对象操作的限制而设计为一组按不同次序排列的操作序列
……划分测试(类似等价划分测试)
……基于故障的测试(类似错误推测法)
——集成测试方法
……多类测试
……从动态模型导出测试用例