武汉理工软件工程导论期末.docx

上传人:王** 文档编号:748981 上传时间:2023-12-31 格式:DOCX 页数:17 大小:80.68KB
下载 相关 举报
武汉理工软件工程导论期末.docx_第1页
第1页 / 共17页
武汉理工软件工程导论期末.docx_第2页
第2页 / 共17页
武汉理工软件工程导论期末.docx_第3页
第3页 / 共17页
武汉理工软件工程导论期末.docx_第4页
第4页 / 共17页
武汉理工软件工程导论期末.docx_第5页
第5页 / 共17页
武汉理工软件工程导论期末.docx_第6页
第6页 / 共17页
武汉理工软件工程导论期末.docx_第7页
第7页 / 共17页
武汉理工软件工程导论期末.docx_第8页
第8页 / 共17页
武汉理工软件工程导论期末.docx_第9页
第9页 / 共17页
武汉理工软件工程导论期末.docx_第10页
第10页 / 共17页
亲,该文档总共17页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《武汉理工软件工程导论期末.docx》由会员分享,可在线阅读,更多相关《武汉理工软件工程导论期末.docx(17页珍藏版)》请在优知文库上搜索。

1、软件工程导论复习题型及分值单选题(20分)推断题(10分)问答题(25分)应用题(45分)20x110x15x57+8+8+10+12一、软件工程的基本概念(PPT1-2章)1.软件危机(产生的缘由)(1)软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严峻问题。(2)软件危机主要有以下表现:a.对软件开发成本和进度的估计常常不精确。开发成本超出预算,实际进度比预定安排一再拖延的现象并不罕见。b.用户对“已完成”系统不满足的现象常常发生。C.软件产品的质量往往靠不住。BUg一大堆,PatCh一个接一个。d.软件的可维护程度特别之低。e.软件通常没有适当的文档资料。f.软件的成本不断提高

2、。g.软件开发生产率的提高赶不上硬件的发展和人们需求的增长。(3)产生缘由:一方面是及软件本身的特点有关;另一方面是由软件开发和维护的方法不正确有关。(4)消退软件危机的途径:a.对计算机软件有一个正确的相识(软件程序)。b.必需充分相识到软件开发不是某种个体劳动的神奇技巧,而应当是一种组织良好、管理严密、各类人员协同协作、共同完成的工程项目。c.推广运用在实践中总结出来的开发软件的胜利技术和方法。d.开发和运用更好的软件工具。e.加强软件管理。2.软件的特点有哪些?(1)软件是一种逻辑实体,而不是具体的物理实体,它具有抽象性;(2)软件的生产及硬件不同;(3)大多数软件是定制的;(4)在软件

3、的运行和运用期间,没有硬件那样的机械磨损、老化问题;(5)软件的开发和运行常常受到计算机系统的限制对计算机系统有着不同程度的依靠性;(6)软件开发至今尚未完全摆脱手工艺的开发方式;(7)软件是困难的;(8)软件成本相当昂贵;(9)相当多的软件工作涉及到社会因素。3 .软件工程?软件工程的目标?()(1)定义:软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴传统工程的原则、方法,以提高质量,降低成本为目的。(2)软件工程旨在开发满足用户须要、刚好交付、不超过预算和无故障的软件,其主要目标如下:a.实现预期的软件功能,达到较好的软件性能,满足用户的需求。b.增加软件过程的可见性

4、和可控性,保证软件的质量。c.提高所开发软件的可维护性,降低维护费用。d.提高软件开发生产率,刚好交付运用。e.合理预算开发成本,付出较低的开发费用。4 .软件生存周期模型?主要的模型类型?()(1)软件生命周期:软件生存周期大体可分为如下几个活动:问题定义、可行性探讨、需求分析、设计、编码、测试、运行和维护。(2)典型的软件过程模型有:瀑布模型(waterfallmodel)演化模型(evolutionarymodel)增量模型(incrementalmodel)原型模型(prototypingmodel)螺旋模型(spiralmodel)喷泉模型(waterfountainmodel)基于

5、构件的开发模型(component-baseddevelopmentmodel)形式方法模型(formalmethodsmodel)5 .软件工程强调(文档化、规范化)?()(1)软件工程强调规范化和文档化。规范化的目的是使众多的开发者遵守相同的规范,使软件生产摆脱个人生产方式,进入标准化、工程化的生产方式。(2)文档化是将软件的设计思想、设计过程和实现过程完整地记录下来,以便于后人的运用和维护,在开发过程中各类相关人员借助于文档进行沟通和沟通。另外,在开发过程中产生的各类文档使得软件的生产过程由不行见变为可见,便于管理者对软件生产进度和开发过程进行管理。在用户最终验收时可以通过对提交的文档进

6、行技术审查和管理审查,保证软件的质量。二、可行性探讨及需求分析1 .可行性探讨的目的(1)用最小的代价在尽可能短的时间内确定问题是否能够解决。不是解决问题,而是确定问题是否值得去解决。(2)说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性;评述为合理地达到开发目标可能选择的各种方案。2 .需求分析的任务、方法、工具(1)任务:需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的“做什么”的问题。(2)方法:a.访谈b.面对数据流自顶向下求精C.简易的应用规格说明技术d.快速建立软件原型(3)工具:3,数据流图(作用)(1)定义:数据流图(DataFlow

7、Diagram):简称DFD,它从数据传递和加工角度,以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程,是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。数据流图是结构化分析方法中运用的工具,它以图形的方式描绘数据在系统中流淌和处理的过程,由于它只反映系统必需完成的逻辑功能,所以它是一种功能模型。数据流图英文缩写DFD(DataFlowDiagram)它是描绘信息流和数据从输入移动到输出的过程中所经受的变换。数据流图从数据传递和加工的角度,以图形的方式刻画数据流从输入到输出的移动变换过程。(2)作用:a.便于用户表达功能需求和数据需求及其联系;b.便于两

8、类人员共同理解现行系统和规划系统的框架;c.清楚表达数据流的状况;d.有利于系统建模.4.推断表、推断树(1)推断表:假如数据流图的加工须要依靠于多个逻辑条件的取值,运用判定表来描述比较合适。以“检查发货单”为例:(2)推断树:判定树也是用来表达加工逻辑的一种工具。有时侯它比判定表更直观。以“检查发货单”为例:三、概要设计1.划分模块的标准(高内聚低耦合)(1)什么是耦合?模块的耦合包括哪些类型?耦合是对一个软件结构内不同模块之间互连程度的度量。模块的耦合包括以下几种类型:数据耦合,限制耦合,特征耦合,公共环境耦合,内容耦合,标记耦合,无耦合/非干脆耦合(2)什么是内聚?模块的内聚包括哪些类型

9、?内聚标记着一个模块内各个元素彼此结合的紧密程度,它是信息隐藏和局部化概念的自然扩展。模块的内聚包括以下几种类型:低内聚一偶然内聚,逻辑内聚,时间内聚中内聚一过程内聚,通信内聚;高内聚一依次内聚,功能内聚。2 .模块独立性?衡量的标准?()模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能,而和软件系统中其他模块的接口是简洁的。模块的独立程度可以由两个定性标准度量:a.耦合:模块之间的相对独立性的度量。b.内聚:模块功能强度的度量耦合及内聚都是模块独立性的定性标准,都反映模块独立性的良好程度。3 .启发性规则给软件工程师以有益的启示,往往能帮助他们找到改进软件设计提高软件质量的途径

10、。下面介绍几条启发式规则:改进软件结构提高模块独立性设计出软件的初步结构以后,应当审查分析这个结构,通过模块分解或合并,力求降低耦合提高内聚。例如,多个模块公有的一个子功能可以独立成一个模块,由这些模块调用;有时可以通过分解或合并模块以削减限制信息的传递及对全程数据的引用,并且降低接口的困难程度。模块规模应当适中阅历表明,一个模块的规模不应过大,最好能写在一页A4纸内(通常不超过60行语句)。有人从心理学角度探讨得知,当一个模块包含的语句数超过30以后,模块的可理解程度快速下降。过大的模块往往是由于分解不充分,但是进一步分解必需符合问题结构,一般说来,分解后不应当降低模块独立性。过小的模块开销

11、大于有效操作,而且模块数目过多将使系统接口困难。因此过小的模块有时不值得单独存在,特殊是只有一个模块调用它时,通常可以把它合并到上级模块中去而不必单独存在。(3)深度、宽度、扇出和扇入都应适当.深度:软件结构中限制的层数;宽度:软件结构内同一个层次上的模块总数的最大值;扇出:一个模块干脆限制(调用)其它模块的数目;扇入:一个模块被其它模块调用的数目。(4)模块的作用域应当在限制域之内作用域:受该模块内一个判定影响的全部模块的集合。限制域:模块本身以及全部从属于它的模块的集合。(5)力争降低模块接口的困难度模块接口困难是软件发生错误的一个主要缘由。应当细致设计模块接口,使得信息传递简洁并且和模块

12、的功能一样。如:QUAD-ROOT(TBL,X)求一元二次方程的根的模块,其中TBL,X都为数组,分别代表方程的系数和方程的根。应当使接口更简洁,如:QUAD-ROOT(A,B,C,ROOTl,ROOT2)A、B、C是方程的系数,ROOTl,ROOT2是方程的根。(6)设计单入口单出口的模块(7)模块功能应当可以预料以上列出的启发式规则多数是阅历规律,对改进设计,提高软件质量,往往有重要的参考价值;但是,它们既不是设计的目标也不是设计时应当普遍遵循的原理。4 .深度、宽度、扇出和扇入深度往往能粗略地标记一个系统的大小和困难程度。深度和程序长度之间应当有粗略的对应关系,当然这个对应关系是在肯定范

13、围内改变的。假如层数过多则应当考虑是否有很多管理模块过分简洁了,能否适当合并。一般说来,宽度越大系统越困难。对宽度影响最大的因素是模块的扇出。(3)扇出过大意味着模块过分困难,须要限制和协调过多的下级模块;扇出过小(例如总是1)也不好。阅历表明,一个设计得好的典型系统的平均扇出通常是3或4(扇出的上限通常是59)。扇出太大一般是因为缺乏中间层次,应当适当增加中间层次的限制模块。扇出太小时可以把下级模块进一步分解成若干个子功能模块,或者合并到它的上级模块中去。当然分解模块或合并模块必需符合问题结构,不能违反模块独立原理。扇入越大则共享该模块的上级模块数目越多,这是有好处的,但是,不能违反模块独立

14、原理单纯追求高扇入。(6)视察大量软件系统后发觉,设计得很好的软件结构通常顶层扇出比较高,中层扇出较少,底层扇入到公共的好用模块中去(底层模块有高扇入)。5,面对数据流的设计方法(1)面对数据流设计(DataFlow-OrientedDesign,DFOD)是及数据流分析(DFA)对应的结构化软件设计技术。面对数据流的设计要解决的任务,就是在需求分析的基础上,将表示系统逻辑模型的DFD图映射(MaPPing)成软件系统结构的初始设计描述。6 .变换设计变换设计就是从变换型数据流图映射出软件模块结构的过程,也称以变换为中心的设计。(2)变换型数据处理问题的工作过程大致分为三步,即取得数据,变换数

15、据和给出数据。相应于取得数据、变换数据、给出数据,变换型系统结构图由输入、中心变换和输出等三部分组成。(4)变换分析方法由以下四步组成:a.重画数据流图;b.区分有效(逻辑)输入、有效(逻辑)输出和中心变换部分;C.进行一级分解,设计上层模块。把整个变换分解成输入限制模块Ci、输出限制模块CO和变换中心限制模块Ct,由主控模块限制;d.进行二级分解,设计输入、输出和中心变换部分的中、下层模块。7 .事物设计事务设计就是从事务型数据流图映射出软件模块结构的过程,也称为以事务为中心的设计。它接受一项事务,依据事务处理的特点和性质,选择分派一个适当的处理单元,然后给出结果。在事务型系统结构图中,事务 中心模块按所接受的事务的类型, 选择某一事务处理模块执行。各事 务处理模块并列。每个事务处理模一(n事务中心Z0(S)-卷篇主模块4, 输入类型分析调度LJI I I T I I Cji 1I 12 I I 13 I IA2 I I B2 I 12 I块可能要调用若干个操作模块,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 大学课件

copyright@ 2008-2023 yzwku网站版权所有

经营许可证编号:宁ICP备2022001189号-2

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!