同等学力计算机学科软件工程精华复习提要Word文档下载推荐.docx
- 文档编号:20764529
- 上传时间:2023-01-25
- 格式:DOCX
- 页数:20
- 大小:73.82KB
同等学力计算机学科软件工程精华复习提要Word文档下载推荐.docx
《同等学力计算机学科软件工程精华复习提要Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《同等学力计算机学科软件工程精华复习提要Word文档下载推荐.docx(20页珍藏版)》请在冰豆网上搜索。
迭代、增量的开发。
*USDP核心工作流:
1.捕获需求2.分析3.设计4.实现5.测试
*USDP的四个阶段:
(1)初始阶段;
(2)精化阶段;
(3)构造阶段;
(4)移交阶段。
三.软件开发范型、典型软件开发模型
3.1软件开发模型:
是软件开发全部过程、活动和任务的结构框架。
3.2瀑布模型内容及特点:
瀑布模型将软件生存周期的各项活动规定为依固定顺序连接的若干阶段工作,是一种线性模型。
各阶段活动:
提出系统需求、提出软件需求、需求分析、设计、编码、测试和运行。
每个阶段具有以下特征:
从上一阶段接受本阶段工作的对象作为输入,对上述输入实施本阶段的活动,给出本阶段的工作成果作为输出传入下一阶段,对本阶段工作进行评审,若本阶段工作得到确认,则继续下阶段工作,否则返回前一阶段甚至更前阶段。
瀑布模型突出的缺点是该模型缺乏灵活性。
3.3演化模型内容及特点:
演化模型主要针对事先不能完整定义需求的软件开发,其开发过程一般是首先开
发核心系统,当核心系统投入运行后,软件开发人员根据用户的反馈,实施开发的迭代过程,每一迭代过
程均由需求、设计、编码、测试、集成等阶段组成,直到软件开发结束。
演化模型在一定程度上减少了软
件开发活动的盲目性。
3.4螺旋模型内容及特点:
它是在瀑布模型和演化模型的基础上,加入两者所忽略的风险分析所建立的一种软
件开发模型。
沿螺旋模型顺时针方向,依次表达了四个方面的活动,制定计划、风险分析、实施工程、客
户评估。
3.5喷泉模型内容及特点:
它体现了软件创建所固有的迭代和无间隙特征,喷泉模型主要用于支持面向对象开
发过程。
3.6增量模型内容:
在设计了软件系统整体体系结构之后,首先完整的开发系统的一个初始子集,继之,根据这一子集,建造一个更加精细的版本,如此不断的进行系统的增量开发。
3.7软件生存期(模型):
软件的提出、实现、使用到停止使用的过程。
四.系统规约、软件设计技术
4.1需求分析阶段的目标及阶段划分:
需求分析的基本任务是准确地定义未来系统的目标,确定为了满足用户的需要系统必须做什么,需求分析分为两个阶段:
需求获取阶段和需求规约阶段。
4.2需求分类:
分为功能性需求和非功能性需求,前者定义了系统做什么,后者定了系统工作时的特性。
4.3结构化方法:
结构化方法是一种系统化开发软件的方法,该方法基于模块化的思想,采用“自顶向下,逐步求精”的技术对系统进行划分,分解和抽象是它的两个基本手段。
4.4结构化分析模型及内容:
数据流图(DFD)是一种描述系统数据变换、为系统实施功能建模的图形工具,是结构化分析方法最普遍采用的表示手段,数据字典和小说明为数据流图提供了补充,并用以验证图形表示的正确性、一致性和完整性,以上三者构成了结构化分析的模型。
4.5需求分析的任务:
借助当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的“做什么”问题。
4.6需求分析的原则:
1.必须能够表达和理解问题的数据域和功能域;
2.按自顶向下、逐层分解方式问
题分解和细化;
3.给出系统的逻辑模型、物理模型;
4.7需求获取内容:
1.物理环境;
2.功能;
3.界面;
4.用户(人)因素5.资源;
6.安全性;
4.8获取技术:
1.交流—通过访谈、会议等反复沟通;
2.观察、提炼用户工作流程;
4.9原型化优点:
1.增进软件开发人员和用户对系统需求的理解,使模糊、不确定的需求明确化;
2.提供有力的学习手段;
3.易于确定系统的功能性能;
4.原型的最终版本,有的可以直接生成产品;
4.10动态分析:
为直观反映系统的动作,从特定观点出发描述系统的行为。
**常见动态分析方法:
状态迁移图;
Petri网;
时序图;
4.11需求规格说明书(SRS)质量控制标准:
高→低
1.正确性;
2.无歧义性;
3.完全性;
4.可验证性;
5.一致性;
6.可理解性;
7.可修改性;
8.可追踪性;
4.12软件设计的重要性和地位
1.开发阶段占软件开发总成本75%以上;
2.软件设计是开发阶段最重要的步骤,是将需求准确地转化为最终软件产品唯一途径。
软件设计作出的决策,最终影响软件实现的成败;
4.13软件设计的任务(目标):
软件设计是一个把软件需求变成软件表示的过程。
即给出软件的解决方案。
4.14软件设计过程
*工程管理:
概要设计;
详细设计;
*技术观点:
数据设计;
系统结构设计;
过程设计;
界面设计;
4.15软件设计准则:
抽象与逐步求精;
模块化与信息隐蔽;
模块的独立性——耦合、内聚。
*抽象:
解决问题时集中考虑与问题有关的方面,而忽略和问题无关的方面。
(抽出事物的本
质特性而暂不考虑细节)
*逐步求精:
自顶向下设计的策略。
对某个功能的宏观描述,用细化方式不断分解,形成过程
的细节,直到算法实现为止。
*模块化:
将软件划分为可独立命名和可编址的部分,每个部分称为模块。
*信息隐蔽:
指每个模块的实现细节对其他模块是隐蔽的。
(模块中所包含的信息不允许不需要
这些信息的其他模块使用)
*模块的独立性:
每个模块只涉及软件要求的具体子功能,与其他模块接口简单。
*模块独立性度量准则:
耦合与内聚。
4.16耦合性(耦合度):
各模块间相互关联的程度。
4.17耦合类型与关系
低耦合性高
非直接耦合数据耦合标记耦合控制耦合外部耦合公共耦合内容耦合
强模块独立性弱
1.非直接耦合:
两模块间没有直接关系,其联系完全通过主模块的控制和调用实现。
2.数据耦合:
两模块间通过数据参数交换信息,称为数据耦合。
3.标记耦合:
两模块间通过数据结构交换信息,称为标记耦合。
4.控制耦合:
模块间传递的信息中有控制信息(开关、标记等),这些控制信息明显地控制选择另一模块
的功能,称为控制耦合。
5.外部耦合:
一组模块都访问同一全局简单变量(而不是同一全局数据结构),且不通过参数表传递该全局变量的信息,称为外部耦合。
6.公共耦合:
若一组模块都访问同一公共数据环境,则它们之间的耦合称公共耦合。
7.内容耦合:
两模块a、b间有下列情况之一,则称为内容耦合。
•a访问b的内部数据;
•a不通过正常入口而转至b的内部;
•两个模块有一部分程序代码重叠;
•一个模块有多个入口;
4.18内聚性(内聚度):
一个模块内部各成分彼此结合的紧密程度。
4.19内聚类型与关系
高内聚性低
功能内聚顺序内聚通讯内聚过程内聚时间内聚逻辑内聚巧合内聚
1.巧合内聚(偶然内聚):
模块内各部间没有联系或联系很松散,则称这种模块为巧合内聚。
2.逻辑内聚:
一个模块完成的多任务逻辑上相关(几个相关能组合),则称为逻辑内聚。
3.时间内聚:
一个模块包含的多任务必须在同一时间段完成,称为时间内聚。
4.过程内聚:
一个模块内的多功能彼此相关,且必须按特定的次序执行,为过程内聚。
5.通信内聚:
一个模块内多功能部分都使用了相同的输入数据,或产生了相同的输出数据,(都对数据
结的同一区域操作),称通信内聚。
6.信息内聚:
一个模块的多个功能成分与同一功能相关,多功能都在同一数据结构上操作,且这些处理是顺执行,称顺序内聚。
7.功能内聚:
一个模块中各部分都是完成某一功能必不可少的组成部分(或该模块中所有部分都是为了完成一项具体功能而协同工作)紧密联系,不可分割,则称功能内聚。
4.20概要设计的任务:
1.制定规范;
2.系统结构总体设计;
3.算法设计;
4.数据结构设计;
5.编写概要设计文档;
6.文档评审;
4.21SC(MSD)术语:
*深度:
控制级别的数量的表示。
*上级模块、从属模块:
上、下两层模块a和b,且有a调用b,a是上级模块,b是从属模块。
*宽度:
整体控制跨度的表示。
*扇入:
调用一个给定模块的模块个数。
•扇出:
一个模块直接调用的其他模块数。
*水平划分:
每个主要程序功能定义了分离的模块结构分支。
*垂直划分:
自顶向下的划分。
4.22DFD类型:
变换型事务性混合型
4.23SC设计步骤:
step1:
分析、确认DFD的类型;
step2:
说明数据流的边界;
step3:
把DFD映射为程序结构;
step4:
对产生的结构进行细化和求精
4.24过程设计:
模块内部实现过程的细化。
*过程:
对处理的精确说明。
4.25设计方法:
面向数据流结构化设计(SD);
面向数据结构结构化设计(SD);
面向对象设计;
4.26SD设计工具:
图形:
程序流程图/N-S/PAD;
表格:
判定表;
语言:
PDL;
4.27面向数据结构的SA、SD方法:
JSD和DSSD方法特点:
1.与结构化分析、设计一样是覆盖需求分析、设计的方法和技术;
2.是面向数据结构的结构化方法;
3.适合与设计企事业管理一类数据处理系统;
4.以信息对象及操作为核心进行分析、设计;
•主要支持工具:
JSD--Jackson图
DSSD--Warnier_Orr图(Warnier图)
4.28面向对象方法的特点:
⒈与人类习惯的思维方法一致;
⒉唯一性;
⒊连续性;
⒋一致性;
5.可维护性、可扩充性;
4.29面向对象基本概念:
*对象:
对象是系统中用来描述客观事物的一个实体,是构成系统的一个基本单位,由一组属性和它可执行
的一组操作组成。
对象的特征:
自治性,封闭性,通信性。
*属性:
每一对象的属性是一些有着确定值的、用于描述对象状态信息的数据。
一般只能通过执行对象的操作来改变。
*操作(方法或服务)描述了对象执行的功能。
为了完成某一任务,一个对象所提供的、并体现其责任的操作。
若通过消息传递,还可以为其他对象使用。
*类:
是具有相同结构、行为和关系的一组对象的描述。
*消息一个对象为实现其责任而与其他对象的通信,在面向对象方法中,对象之间只能通过消息进行通信。
*继承表达类之间相似性的一种机制,即在已有的类的基础之上增量构造新的类,前者称为父类(或超类),后者称为子类,如果子类只从一个父类继承,则称为单继承,如果子类从一个以上父类继承,则称为多继承。
*关联把一组具有相同结构特性、行为特征和语义的链(对象之间存在的引用关系-元组,称为链。
)的描述称为关联。
4.30Coad-Yourdon方法:
该方法认为,人类在认识和理解现实世界的过程中,普遍运用着下面三个构造法则:
区分对象及其属性,区分整体对象及其组成部分,不同对象类的形成及区分。
**Coad-Yourdon模型体系:
OOA:
类、对象层;
属性层;
服务层;
结构层;
主题层;
OOD:
在OOA的五个层次建立系统的四个部分—问题论域;
用户界面;
任务管理;
数据管理;
4.31面向对象分析步骤:
⒈识别对象、属性、外部服务;
⒉识别类及结构;
⒊定义对象间的消息传递;
4.32面向对象设计步骤:
⒊定义对象间的消息传递;
4.33UML(UnitedModelingLanguage)模型体系:
静态建模机制图:
类、对象图;
构件图;
配置(部署)图;
包图;
动态建模机制图:
状态图;
活动图;
顺序图;
协作图;
4.34用例或用况(UseCaseModel)模型:
用例模型反映一组用例、执行者及它们之间关系的模型图,用例图可以直观体现系统功能。
用于需求分析阶段,用于描述外部执行者所理解的系统功能,表达了开发人员和用户对需求规格达成的共识。
4.35顺序图:
表示实例之间按时间顺序组织的交互。
支持实时系统和复杂场景的详细建模。
4.36状态图:
状态图用于描述模型元素(如对象)的行为。
五.软件测试
5.1关于软件测试的地位及重要性:
⒈是保障软件质量的关键步骤,是对软件需求、设计、编码的最后交审;
⒉软件测试的工作量、成本占软件开发总工作量、总成本的40%以上。
5.2软件测试:
为了发现错误而执行程序的过程。
5.3测试目的:
总的目的:
发现软件错误。
*用户角度:
通过测试暴露软件隐藏的错误、缺陷,能否接受该软件;
*软开者角度:
通过测试表明软件不存在错误,验证软件满足了用户要求。
5.4测试过程模型
5.5软件错误:
结构错误;
数据错误;
编程错误;
接口错误;
5.6白盒测试:
对软件的过程性细节进行检查。
(白盒测试技术依据的是程序的逻辑结构)
5.7白盒测试原则:
⒈保证所测模块中每一独立路径至少执行一次;
⒉保证所测模块所有判断的每一分支至少执行一次;
⒊保证所测模块每一循环都在边界条件和一般条件下至少各执行一次;
⒋验证所有内部数据结构的有效性。
5.8白盒测试技术:
基本路径测试和逻辑覆盖。
5.9基本路径测试思想:
据软件过程性描述中的控制流程确定复杂性度量,用此度量定义基本路径集合,并由此导出一组测试用例。
5.10基本路径测试实现:
step1:
PFD——>
程序图G;
step2:
计算V(G);
step3:
确定独立路径导出测试用例。
5.11逻辑覆盖:
以程序内部的逻辑结构为基础的测试用例设计技术。
5.12判定覆盖:
使设计的测试用例保证程序中每个判断的每个取值分支至少经历一次。
5.13条件覆盖:
设计的测试用例保证程序中每个判断的每个条件的可能取值至少执行一次。
5.14判断—条件覆盖:
设计足够的测试用例,使判断中每个条件的所有可能取值至少执行一次,同时每个判断的所有可能判断结果至少执行一次。
5.15条件组合覆盖(多重条件覆盖):
设计测试用例,保证每个判断的所有可能条件取值组合至少执行一次。
5.16路径覆盖:
设计测试用例,保证覆盖程序中所有可能的路径•黑盒测试主要诊断以下几类错误:
⒈功能不对或遗漏;
⒉界面错误;
⒊数据结构或外部数据库访问错误;
⒋性能错误;
⒌初始化和终止条件错。
5.17黑盒测试:
对软件软件功能是否满足要求进行测试、验证。
(测试功能性需求,不考虑控制结构;
黑盒测试技术依据的是软件行为的描述。
)
5.18黑盒测试主要诊断以下几类错误:
5.19黑盒测试方法:
等价类划分法;
边界值分析法;
错误推测法;
因果图;
功能图;
5.20等价类划分思想:
把程序的输入数据集合划分成若干等价类。
每一个等价类中,各个输入数据对发现程序中的错误都是等效的。
因此可以为每一个等价类设计一个测试用例。
5.21等价类划分法实施步骤:
划分等价类;
step2:
选取测试用例。
5.22边界值分析:
对各种输入、输出范围的边界情况设计测试用例的方法。
5.23边界值分析实现步骤:
Step1:
确定边界情况;
Step2:
选择测试用例;
5.24错误推测法:
依靠经验和直觉推测程序中可能存在的各种错误,设计测试用例检查这些错误。
5.25软件测试过程(合理的测试序列):
单元测试;
集成测试;
确认测试(有效性测试);
系统测试;
5.26单元测试:
对软件设计的最小单位—模块进行正确性检验的测试。
目的是发现各模块内部可能存在的各种错误。
依据是详细设计说明书和源程序。
5.27单元测试内容:
1.模块接口测试;
2.局部数据结构;
3.路径测试;
4.错误处理测试;
5.边界测试;
5.28集成测试:
在单元测试基础上,将所有模块按设计要求组装成系统后进行的测试.
•组装方式
1.一次性组装:
一次全部组装,进行整体测试;
2.将模块逐步组装成较大系统,组装过程中边连接边测试,最后增殖到所要求的系统。
5.29增殖方式—自顶向下的组装方式:
将模块按系统程序结构,沿控制层次自顶向下地组装。
5.30自顶向下的组装步骤:
(1)以主模块为所测模块兼驱动模块,所有直属主模块的下属模块全部用桩模块代替,对主模块进行测试。
(2)采用深度优先或分层的策略,用实际模块替换相应桩模块,再用桩模块代替它们的直接下属模块,
与已测的模块或子系统组装成新的子系统。
(3)进行回归测试,排除组装过程中因如新的错误的可能。
(4)判断是否所有模块都已组装到系统中?
是则结束测试;
否则转
(2)。
5.32增殖方式—自底向上的组装方式:
从程序模块结构的最底层的模块开始组装和测试。
5.33自底向上的组装步骤:
(1)由驱动模块控制原子模块的并行测试,或把原子模块组合成实现某子功能的模块群,由驱动模块控制它进行测试;
(2)用实际模块代替驱动模块,与它已测的直属子模块组装成子系统;
(3)为子系统配备驱动模块,进行新的测试;
(4)判断是否组装到达主模块?
5.34确认(有效性)测试:
验证软件的功能和性能及其他特性是否满足需求规格说明书的要求。
5.35确认测试步骤:
1.进行有效性测试(黑盒测试);
2.软件配置复审;
5.36α测试:
由一个用户(也可以是开发机构内部的用户)在开发环境下(或模拟实际操作环境下)对即将面市的软件产品(称为α版本)进行的测试.
5.37α测试目的:
评价软件产品的FLURPS(Function/Local/Usability/Reliability/Performance/Suppor).
5.38β测试:
多个用户在一个或多个用户环境下对经过α测试后的版本(β版)进行的测试.
5.39β测试目的:
衡量软件产品的FLURPS.
5.40系统测试:
将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、支持软件、数据和人员等其他系统元素结合在一起,在实际运行(使用)环境下对计算机系统进行一系列的组装测试和确认测试。
5.41软件调试:
在软件进行了成功的测试之后,进一步诊断和改正程序中潜在的错误。
5.42调试活动组成:
1.对程序中的错误定性、定位;
2.对程序进行修改,排除错误;
5.43测试覆盖率:
定量地描述一个或一组测试的效率(测试完成程度)。
语句覆盖率(C1):
遵循至少执行程序中的所有语句一次,称达到100%语句覆盖率;
分支覆盖率(C2):
遵循至少执行程序中的每一分支一次,称达到100%分支覆盖率。
5.44事务处理流程测试技术:
(基于黑盒)
*控制流程图:
程序控制结构的图形表示。
*控制流程图基本元素:
过程(块)、结点、判定。
*过程:
既不能由判定也不能由结点分开的一组程序语句。
*判定:
程序点,该点处控制流可以分叉。
判定中可包含处理。
*结点:
程序点,该点控制流可以结合。
*路径:
路径是一串指令或语句。
它在一个入口、结点、判定处开始,在另一个入口(或同一入口)、结点、判定或出口处结束。
5.45事务处理流程图与控制流程图的区别与联系:
事务处理流程图与控制流程图的类同点是使用了相同的概念
成分,不同之处是事务流程图是一种数据流程图,链支和过程块的定义有所差异,另外事务流程图的判定节点可能是一个复杂的过程,从而事务流程图中的判定只能是“抽象”,第三点不同之处是事务流程图中存在“中断”的作用,中断可以把一个过程等价的变换为具有繁多出口的链支,对此也要予以抽象。
5.46软件测试和软件调试的区别:
测试从一个侧面证明程序员的“失败”,而调试是为了证明程序员的正确,测试以已知条件开始,使
用预先定义的程序,且有预知的结果,不可预见的仅是程序员是否通过测试,调试一般是以不可知的内部
条件开始,除统计性调试外,结果是不可预见的,测试是有计划的,并要进行测试设计,而调试是不受时
间约束的,测试是一个发现错误、改正错误、重新测试的过程,而调试是一个推理过程,测试的执行是有
规程的,而调试的执行往往要求程序员进行必要推理以至直觉的“飞跃”,测试经常是由独立的测试组在
不了解软件的条件下完成的,而调试必须由了解详细设计的程序员完成,大多数测试的执行和设计可由工
具支持,而调试时,程序员能利用的工具主要是调试器。
六.软件工程管理
6.1软件管理的主要责任:
组织与规划。
6.2软件管理的主要任务:
成本估算,计划、人员、进度、质量、风险、资源、标准化、软件配置管理等。
6.3进度计划、安排方法:
1.GanttChart(甘特图/横道图)——反映时间和作业;
2.PERT(ProgramEvaluation&
ReviewTechnique计划评审技术)法;
3.CMP(CriticalPathMethod关键路径法)方法;
6.4软件开发成本:
软件开发过程中所花费的工作量及相应的代价。
(不包括材料和能源的消耗)
6.5成本估算方法:
*自顶向下估算;
*自底向上估算;
*差别估算法;
6.6成本估算模型
**基本
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 同等学力 计算机 学科 软件工程 精华 复习 提要
![提示](https://static.bdocx.com/images/bang_tan.gif)