软件工程知识点.docx
- 文档编号:8562026
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:13
- 大小:81.88KB
软件工程知识点.docx
《软件工程知识点.docx》由会员分享,可在线阅读,更多相关《软件工程知识点.docx(13页珍藏版)》请在冰豆网上搜索。
软件工程知识点
软件工程知识点
第一章
软件危机:
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
软件危机的表现:
(1)软件开发进度和成本难以控制。
(2)软件产品难以满足用户的需求。
(3)软件质量难以得到保证。
(4)软件产品难以进行维护。
(5)软件的文档资料难以管理。
(6)软件产品的生产率难以得到提高。
软件危机出现的原因:
一方面是软件自身特点,另一方面是开发软件和使用软件的人员。
(1)对软件开发缺乏正确的理论指导。
(2)软件开发人员与用户缺乏充分的交流。
(3)对软件开发过程缺乏整体认识。
(4)对软件产品缺乏有效一致的质量评价标准。
软件工程发展的四个阶段:
(1)传统软件工程阶段:
用工程化思想指导软件项目开发逐步为业界所理解和接受。
(2)面向对象软件工程阶段:
这一阶段的发展是以“对象”为基础展开的。
(3)过程工程的软件工程阶段:
提出对软件项目管理的计划,实施,监控,成本核算,质量保证以及软件配置的技术和过程,逐步形成了过程软件工程,并衍生出群体过程和个体过程两个子类。
(4)构建工程的软件工程阶段:
重视发展软件体系结构,软件设计模式,系统交互性,标准化等领域的重用,积极提倡基于软构件的开发方法。
软件工程的概念:
应用计算机科学理论和技术以及工程管理原则和方法,按预算和进度,实现满足用户要求的软件产品和定义,开发,发布和维护的工程或进行研究的学科。
软件工程三要素:
方法,工具,过程。
简答第一大题衡量软件质量的因素:
(1):
可理解性:
它对软件体系结构,数据程序的描述清晰和易于掌握的程度。
(2)功能性:
它是软件所实现的功能和达到的性能与满足用户实际需求的程度(3)安全性:
它是软件具有的自身保护能力的程度。
(4)可靠性:
它是软件在给定的时间、空间、外部环境等条件下,按照设计须有,成功运行的能力。
(5)有效性。
它是软件能充分利用计算机时间、空间、宽带等资源的能力。
(6)可扩充性;它是软件在功能或性能发生变化时,系统改变的容易程度。
(7)可维护性,它是软件出现异常时,对系统进行修改、改进、删除、增加等操作,并恢复系统正常运行的能力。
(8)可重用性,它是软件的部分或整体被其他系统利用的程度(9)可移植性,它是将软件系统有一个软件或硬件环境转移到另一个软件或硬件环境的容易程度。
软件的七大基本原理
1,用分阶段的生命周期计划严格管理。
2,坚持进行阶段评审。
3,执行严格的产品质量控制4,采用现代程序设计技术5,结果应能清楚地审查。
6,开发人员应少而精。
7,承认不断改进软件工程的必要性
软件实现的是一个从现实问题域(输入)到信息域的解(输出)的过程,在此过程中包括程序、数据、文档、以及它们之间的联系
软件生命周期六个阶段
1,可行性与计划研究阶段。
2需求分析阶段。
3,设计阶段。
4,实现阶段。
5,测试阶段、6,运行和维护阶段
软件过程模型:
(1)瀑布模型:
1、特点:
简单、严格(每一阶段过程都始于前一阶段过程的结束,每一阶段结束后都进行技术审查和管理复查)、顺序、质量保证。
2、适用领域:
瀑布模型是一次性单向开发,难以适应软件需求不明确或出现变动的情
(2)
(3)
(4)简单、使用、满足用户需求为要旨)、变化(敏捷过程模型要能反映这种变化,并将变化及时反映在软件的设计和实现中)、有目的的建模(多与团队人员沟通,与客户沟通,保证建模的正确性和足够详细)、快速反馈(在开发过程中,自己所做的工作,与别人合作,都应该及时得到反馈,快速反馈是建立在团队合作的基础上)2、优点:
综合瀑布模型和原型模型的优点,在保证减少错误的前提下,快速得到用户系统,在每个阶段都引入风险分析。
快速开发、建模,不但能够促进个人和团队开发人员之间的沟通。
第二章
基本的需求分析任务是:
定义软件的适用领域和必须满足的约束(需求发现),确定系统功能、性能、领域等内容,确定软件与其他成分间的借口和通信(需求分析),建立数据模型、功能模型和行为模型(建模),最终定义需求规格说明书,并经技术审查和管理复审,用作评价确认测试和质量评估的依据。
系统中最主要的、最基本的要求是功能需求。
定义逻辑模型:
通过定义逻辑模型,把问题域中的问题转换为信息领域问题。
需求分析的原则:
软件人员要从用户角度考虑软件需求;以流程为主线;尽量重用软部件;划分需求的优先级;需求变更要及时反馈;
需求分析的内容:
功能需求,性能需求,领域需求,其他需求。
功能需求:
描述系统提供的服务和在特定条件下的行为,包括系统登陆、输入、响应、输出、异常等,有事还需要特别的说明系统不应该做什么。
通过功能需求分析,划分出系统必须完成的所有功能。
软件的功能描述满足完整性和一致性。
性能需求:
规定了软件系统必须满足在时间上或空间上的约束,通常包括系统响应时间,主存容量,储存容量,安全性,压力等方面的需求。
领域需求:
与软件系统的具体应用范围有关,它是对需求中的功能或数据在领域上需要的特别实现,具有特殊性。
其他需求:
是软件系统有关的外在约束,如法律需求,道德需求,外部数据交换需求,预期需求等。
需求工程过程中的活动:
需求工程过程是一个可行性研究、需求获取、需求分析与建模、需求评审的迭代过程。
可行性研究:
是需求工程最初的计划阶段,目的不是确定问题如何去解,而是确定问题是否值得去解。
可行性分析主要包括四个方面的内容:
(1)技术可行性:
从问题的复杂性、现有技术、技术所需代价、技术风险等三个方面出发。
(2)操作可行性。
(3)经济可行性:
运用软件成本估算技术(成本/效益分析等方法)判断是否盈利。
(4)法律可行性。
需求分析与建模:
采用软件开发方法提供的图形工具,用形式化或半形式化的定义来描述初步需求,确保需求的完整性、正确性和一致性,将目标系统的物理模型转换为详细模型。
需求工程的管理:
存在两大难题:
一是需求确认困难,二是需求不断变更。
对传统的需求变更管理过程来说,主要包括软件配置、软件基线和变更审查。
软件配置项主要有两类:
一是属于产品自身需要的内容,如开发文档、代码、数据等;二是为软件产品服务的内容,如进度计划,人员安排,报告等。
软件基线由一组软件配置组成,当软件配置处于稳定状态后(如需求文档经过评审以后),就确定了这组软件配置项的基线。
需求获取技术:
(1)个别会议和小组会议:
小组会议则体现了用户群组的集思广益。
W5H2原则(Why:
为什么要开发该系统?
,What:
系统将要开发的功能是什么?
,When:
什么时候开发?
,Who:
系统由谁负责?
系统会有哪些相关的人、事务或其他系统?
Where:
所开发的业务处于整个系统的什么位置?
,How:
完成系统的开发目标技术上采用何种方法?
管理上如何进行?
,Howmuch:
开发系统需要那些资源?
需要多少?
)
(2)调查问卷。
(3)面向用例的场景分析:
访谈和问卷调查是一种抽象的需求描述,存在用户描述模糊,分析员工不理解甚至误解的情况。
用户的一次手工操作就是一个用例。
场景让分析员实际模拟了用户的操作流程,但需要注意防止场景陷阱。
(4)快速原型技术:
快速原型技术的基本思想是,在系统的开发时期就让用户尽早地接触系统,对系统原型进行评估,指出不足之处并提出修改意见。
快速原型有两种不同类型:
抛弃型原型法和演化型原型法。
演化型原型法是无风险机制,任然是迭代的。
结构化需求分析和建模:
主要目的是减少分析时的错误,通过自定向下地建立系统逻辑模型,降低系统设计时的复杂性,提高系统的可维护性。
结构化分析的核心是数据。
包括:
实体关系模型,数据流图,状态转换图。
面向对象的数据建模:
数据建模给出了软件开发过程中与各部分设计有关的所有数据对象。
数据对象包括实体、实体属性和实体间关系。
实体关系模型(ER)是结构化建模的可视化图形工具,他描述了数据对象(实体),对象属性和对象间关系。
关系和基数:
基数表明数据对象在关系上的数量约束,在ER模型中,关系用菱形表示,它通常是一个动词或动宾短语。
基数关系(一对一一对多多对多)
数据流图是结构化建模中最流行的功能建模工具。
建模的基本过程:
(1)确定系统的外部信息源,数据源或外部系统的接口。
(2)画出顶层(0层)DFD图。
(3)第一次精化:
划分系统的子系统。
(4)逐层求精:
对各子系统进一步精化。
面向状态转换的行为建模:
行为建模是所有需求分析办法的操作性原则,系统状态的改变状态转换图来描述。
STD图中的状态分为初态,终态,中间状态和复合状态。
状态变换是由事件或条件触发的。
STD图定义了3个标准事件,它们都没有参数:
(1)entry事件:
用于说明转换到该状态的特定动作。
(2)exit事件:
用于说明触发该状态的特定动作。
(3)do事件:
用于说明处于当前状态时执行的动作。
数据字典:
以结构化方式定义了在数据建模、功能建模和行为建模过程中设计的所有数据信息、控制信息。
词条描述:
详细说明了数据和控制信息在系统内的传播途径,它包括数据流词条,数据元素词条,加工词条和存储文件词条等内容。
定义式特点:
清晰、准确、无二义地定义数据。
Warnier图用树形结构表示数据的层次结构,利用顺序,选择和重复三种结构对应数据的层次分解,并指出可以从数据层次结构导出程序结构。
加工逻辑:
也称为过程说明,用于描述DFD中加工部分的流程或算法。
加工逻辑的形式主要有过程描述语言、判断树和判断表等。
过程描述语言也称为伪码语言,它是一种介于自然语言和形式语言之间的结构化语言。
第三章
软件设计的目标就是要构造一个高内聚、高可靠性、高维护性和高效的软件模型。
软件设计的依据是需求规格说明和数据规格说明,并将它们映射为软件设计的内容。
一般把软件设计分为概要设计和详细设计两个子阶段。
概要设计包括:
体系结构设计、界面设计和数据设计。
模块化设计的指导思想是分解、抽象、求精、信息隐藏和模块独立性。
界面设计的任务主要包括用户特性研究、用户工作分析、界面任务分析、界面类型确定和界面原型评估。
分布式结构存在的不足:
复杂性、安全性、运行状态难以确定。
出选择:
体系结构设计:
确定各子系统模块间的数据传递、调用关系。
界面设计:
包括与系统交互的人机界面设计以及模块间、系统与外部的接口关系。
数据设计:
包括数据库、数据文件、全局数据结构的定义。
体系结构设计是软件设计的早期活动,它的作用集中在两点:
1、提供软件设计师能预期的体系结构描述2、数据结构、文件组织、文件结构体现了软件设计的早期抉择,这些抉择将极大地影响着后续的软件开发人员,影响着软件产品的最后成功。
抽象:
抽象是指对软件设计不同层次的理解,它与分解是解决问题的两个方面。
分解是对问题细节的表述,抽象则忽略问题的细节,抓住问题的本质。
抽象根据对象类型的不同,分为对实体对象抽象、接口抽象和设计模式抽象。
模块独立性由内聚性好人耦合度两个指标来评价。
内聚性高或耦合度低,独立性就强。
内聚性:
偶然内聚:
模块间功能偶然聚集在一起,导致模块的不易理解,不易修改维护。
逻辑内聚:
将逻辑相关的功能放在同一模块内,由模块参数来决定执行哪一个功能。
时间内聚:
各任务间彼此无联系,但由于需要在同一时间运行而聚集在一起。
过程内聚:
按照过程描述,在同一模块内至上而下的组织各任务。
通信内聚:
模块中各成分引用共同的数据,即模块内的功能使用统一输入数据。
顺序内聚:
各成分中,前一部分的输出是下一部分的输入,它们彼此具有较高的依赖性。
功能内聚:
共同完成一个具体功能,它们之间紧密联系,不可分割,具有较高的内聚性。
耦合度:
耦合度越低,模块尖紧密程度月松散,模块独立性越强。
非直接耦合:
模块间没有直接的数据调用关系。
数据耦合:
模块间相互调用时,传递的是基本数据类型,而非复合数据结构。
特征耦合:
模块间相互调用时,传递的是复合数据结构而非基本数据结构。
控制耦合:
模块间传递的数据不是普通的值信息,而是控制变量。
公共耦合:
多个模块访问全局变量、结构、文件等公共信息都称为公共耦合。
内容耦合:
一个模块直接访问另一个模块内部的数据,或一个模块有多个入口,或一个模块非法进入另一个模块内部。
考虑模块耦合度时,应遵循“尽量使用数据耦合,少用控制耦合,限制公共耦合范围,坚决避免使用内容耦合”。
数据仓库模型是一种集中式模型。
详细设计的任务是完成过程设计。
过程设计包括:
确定软件各模块内部的具体实现过程和局部数据结构。
软件设计的原则:
分而治之、重用设计模式、可跟踪性、灵活性、一致性。
简答题:
数据仓库模型的优点:
1、数据统一存储和管理,确保了数据的实时性2、数据仓库对数据复杂性的统一封装有利于数据共享3、采用黑板模型,与某类数据有关的应用系统能及时获取数据4、采用数据订阅推送模型,应用系统在有数据更新时,能自动获得数据,而不用采取询问方式,提高了数据管理效率5、各应用系统间仅通过数据仓库完成数据交换,在功能上没有关联,增加,删除应用系统及其部分功能,将不会影响其他应用系统的正常运行。
集中式数据仓库不足:
1、增加了数据仓库设计的复杂性,降低了数据传递的效率2、应用系统的数据结构发生改变,就需要单独设计数据适配器,以实现新的结构与数据仓库在数据上的匹配3、数据共享带来的访问控制的复杂性、安全性、效率、备份、存储、恢复策略等一系列问题,影响了仓库模型的有效利用。
分布式结构特点:
1、共享:
实现了数据共享,云计算的提出还能进一步实现云计算共享2、异构型:
客户端/服务器允许软件配置不同3、开放性:
只要符合互联网协议,任何计算机,局域网,智能设备和物品等都可连入互联网。
4、易修改性:
由于用户界面,系统逻辑和数据访问分布的不同,各部分具有较强的独立性,易于系统的修改和维护5、透明性:
分布式结构中仅需要知道服务器的服务位置,而对后端的逻辑实现,数据存储,数据访问等不必清楚其架构和访问方式。
简答第二大题可能启发式规则:
1、改进软件结构,提高模块独立性2、模块规模适中3、软件结构的宽度、深度、扇出度和扇出度都应适中4、模块的作用域应在模块控制域之内5、设计单入口、单出口的模块,并力争降低模块接口的复杂度。
可能第二大题简答模块的作用域是指模块内定义的所有元素(如数据、变量等)各自有效的使用范围。
模块的控制域是指模块所能操作和调用的所有元素(如其他模块等)的集合。
模块的作用域应在模块的控制域之内
TheoMandel提出的界面设计黄金三原则:
1、置用户与控制之下2、减少用户的记忆负担3、保持界面一致。
MVC软件设计模型:
模型—视图—控制器。
模型是系统的主体部分,使用系统处理数据规则和使用控制逻辑的业务规则。
控制器定义了应用程序的行为,它负责对用户的请求进行解析。
视图完成对数据的展示,包括数据接收、数据分布、维度分析、信息展示等一系列步骤,但视图不包括应用系统的任何数据规则和业务逻辑。
MVC软件设计模型优势:
1、一个模型对应多个不同的视图2、模型的自包含性3、控制层把一个模型和多个不同的视图组合在一起,能够完成多种类型的请求4、MVC分层模式使得只修改其中某层就能满足用户新的需求,使系统达到不同的效果,且更易于系统的更新升级5、MVC利于软件工程的工程化管理。
缺点:
1、增加了系统的复杂性2、导致修改的连锁反应3、数据访问效率低。
第四章结构化设计方法
填空题:
结构化设计分为面向数据流的设计方法和面向数据的设计方法。
结构图与层次图的不同是,它增加了对连线的数据流描述。
*变换分析法还是事务分析法是以数据流图为基础,并根据数据流的特征进行软件系统结构涉及到方法。
*结构化设计的详细设计阶段,主要完成系统各模块功能的过程描述。
详细设计提供了图形,表格和语言等三类不同工具。
结构化设计的思想,是提供一种自顶向下,逐步求精,单入口单出口的程序设计。
判断:
由于合图没有控制流,控制的跳转就不能随意转移
PAD图体现了自顶向下,自左向右,逐步细化,逐层推进的设计工程。
第五章软件实现
客观题:
程序设计语言的分类:
1.机器语言:
自从有了计算机,就有了计算机语言。
2.汇编语言:
汇编语言也是与系统硬件直接交互的机器语言,但它已经有了一定的符号指令。
3.高级语言:
4.4GL:
4GL是过程描述语言。
将要实现的功能,而实现的过程被隐藏起来。
4GL应用是数据库的结构化查询语言。
简答题:
源代码形式的复用
源代码复用要求被复制重用的代码和新系统的开发代码是同一种语言,或是能兼容的程序语言。
利用中间语言实现跨语言的重要。
泛型编程提供了一定抽象层面的源代码复用,并提供了一组标准容器类。
源代码形式的重用导致代码兼容的问题。
填空:
面向对象程序设计语言机制:
类,继承性,多态性,消息机制
选择:
变量和常量的命名应遵循匈牙利命名法。
软件复用包括代码复用,设计模式复用,软件开发过程复用
代码复用是最低级的
判断:
语句结构处理
每行语句只表达一个语义信息,如赋值,运算,函数调用,判断等。
不能同时具有多个表达式。
现阶段对编码的标准,已是可理解性第一,效率第二。
代码评审分为正式评审和轻重量级评审
正式评审:
正是评审是针对代码编写完成之后召开的评审会议。
轻重量级的评审:
主要采取非正式的代码走查方式,不需要组织正式会议,因此它成本小,灵活性强。
第六章
测试的重要概念的定义:
失败,错误,缺陷,测试用例
判断:
软件测试是在一定软件环境下,以最小的成本来验证系统能否按照需求正确运行,并尽可能多地发现存在的错误。
测试只能证明程序有错,并尽可能多地发现存在的错误。
软件测试的目的发现程序中的错误,它既找不出错误发生地位置,也不分析出错的原因。
一个好的测试用例和过程有可能发现一个尚未发现的错误。
一个成功的测试用例是发现了一个尚未发现的错误。
进行测试要求有测试配置(如测试方案,测试计划,测试用例等),测试环境配置,执行测试过程,最后进行测试结果与预期结果的对比及评价。
简答:
测试的V模型测试W模型测试H模型主要特点
软件测试不再是一个独立阶段,而是贯穿于整个开发过程,与各流程并发。
软件测试分阶段,分层次,分对象,并按照开发过程先后顺序进行的活动,是一个迭代过程。
软件测试应早准备,早执行。
软件测试需要测试配置,测试方案,测试用例和预期测试结果,而不仅是测试的运行。
客观题:
1应尽早地和不断地进行测试
软件错误的放大效应,即每一阶段产生的错误都会给下一阶段造成更大的错误。
2开发人员应尽量避免参加测试
3注重测试用例的设计和选择
对测试对象进行完全测试是困难的表现在:
不可能测试所有的输入数据。
不可能测试用户的输入行为。
不可能测试所有路径。
4增量式测试
5充分注意测试的群集现象
充分注意测试的群集现象:
软件中的错误不是均匀分布在各部分中的,而是出现扎堆的现象。
当发现某部分出现错误时,就应该进一步测试是否还存在更多的错误。
6合理安排测试计划,严格执行测试计划
7全面统计和分析检测试结果
8保存测试文档,并及时更新
设计阶段分为概要设计和详细设计两个子阶段
概要设计确认测试的方案保证软件系统整体的功能,性能符合需求。
详细设计单元测试方案既要完成内部流程测试,也要验证接口定义是否符合设计规范,并能正确传递数据或信息。
填空题:
静态测试的测试对象包括源程序和文档。
对文档的测试数据都属于静态测试。
动态测试的测试对象是源程序
白盒测试和黑盒测试综合题
逻辑覆盖
1语句覆盖(最弱)
2判定覆盖
3条件覆盖
4判定/条件覆盖
5条件组合覆盖
路经测试,等价划分综合题
有效等价类是指对被测程序来讲,是最有意义的,合理的数据组合。
无效等价类正好相反,试图通过无效的,无意义的数据,从反面说明软件功能和性能可靠性。
边界值分析是对等价类划分的有益补充。
再划分等价类的过程中,有效和无效等价类的边界,往往是测试的重点。
判断题:
错误推测是根据测试人员的经验和直觉来推测程序中可能存在的各类错误。
因果图是一个通过逻辑网络表示的形式语言,他将输入数据作为因,把输出数据看做果
填空或选择
1模块接口2局部数据结构3执行路径4边界条件5异常处理
判断题:
确认测试也称为验收测试,它是指在模拟用户实际操作的环境下(或开发环境下),运用黑盒测试法验证软件的有效性是否符合需求。
系统测试是指软件系统作为整个计算机系统的一部分,与计算机系统的硬件系统,数据,外部其他软件,文档等要素相结合,在用户实际运行环境中进行的测试。
填空题:
系统测试的范围1功能测试2性能测试3压力测试4容量测试5安全测试6文档测试7恢复性测试8备份测试
第七章
UML是一种可视化语言
UML的构成1视图2图3模型元素4通用机制
判断:
试图从不同角度来描述系统,因而视图不是图。
视图由图组成,图描述了一个视图的内容,是构成视图的图形元素。
UML的9类图例图,类图,包图,状态图,活动图,顺序图,协作图,构件图部署图
用例视图是其他视图的基础,会影响到其他试图的建模过程和描述内容
用例视图描述系统的外部特征,系统功能和性能等需求,它从用户角度描述系统。
选择题:
设计视图描述系统内部的静态结构和动态行为,包括系统结构模型和系统行为模型。
设计视图是从系统内部角度描述如何实现系统功能。
设计视图通过类图,包图来描述静态结构,通过状态图,顺序图,协作图和活动图来描述动态行为。
实现视图表示系统的组建结构,通常用独立的文件来描述,它表示系统的逻辑组成实现视图通过构件图来表示。
过程视图表示系统内部的控制机制和并发特征,主要是解决各种通信和同步问题。
用状态图,协作图和活动图。
配置视图表示描述系统软件系统和物理设备之间的配置关系,它表示系统的物理组成。
配置视图由配置图描述。
包图是对UML中用例,类图,UML关系等模型元素的封装。
包之间的关系主要有两个类:
依赖关系:
一个包引入另一个包的输出信息。
泛化关系:
定义包的继承关系,体现具有与类库相似的包的家族。
构件图和配置图的基础是类图配置图也被称为部署图
UML的关系关联关系包括复合关联和聚合关联依赖关系泛化关系实现关系
关联关系1普通关联2限定关联3关联类4递归关联5聚合
如果二元关系是双向关系,则表明两个类彼此都能调用对方公共部分的属性和方法。
聚合也称聚集,它是特殊的关联关系,其特殊之处在于它描述的多个类之间是整体和部分的关联关系。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 知识点