武汉理工软件工程导论期末.docx
《武汉理工软件工程导论期末.docx》由会员分享，可在线阅读，更多相关《武汉理工软件工程导论期末.docx（22页珍藏版）》请在冰点文库上搜索。
武汉理工软件工程导论期末
软件工程导论复习
题型及分值
单选题（20分）20x1
判断题（10分）10x1
问答题（25分）5x5
应用题（45分）7+8+8+10+12
一、软件工程的基本概念（PPT1-2章）
1.软件危机（产生的原因）
（1）软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
（2）软件危机主要有以下表现：
a.对软件开发成本和进度的估计常常不准确。
开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见。
b.用户对“已完成”系统不满意的现象经常发生。
c.软件产品的质量往往靠不住。
Bug一大堆，Patch一个接一个。
d.软件的可维护程度非常之低。
e.软件通常没有适当的文档资料。
f.软件的成本不断提高。
g.软件开发生产率的提高赶不上硬件的发展和人们需求的增长。
（3）产生原因：
一方面是与软件本身的特点有关；另一方面是由软件开发和维护的方法不正确有关。
（4）消除软件危机的途径：
a.对计算机软件有一个正确的认识（软件≠程序）。
b.必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
c.推广使用在实践中总结出来的开发软件的成功技术和方法。
d.开发和使用更好的软件工具。
e.加强软件管理。
2.软件的特点有哪些？
（1）软件是一种逻辑实体，而不是具体的物理实体，它具有抽象性；
（2）软件的生产与硬件不同；
（3）大多数软件是定制的；
（4）在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题；
（5）软件的开发和运行常常受到计算机系统的限制对计算机系统有着不同程度的依赖性；
（6）软件开发至今尚未完全摆脱手工艺的开发方式；
（7）软件是复杂的；
（8）软件成本相当昂贵；
（9）相当多的软件工作涉及到社会因素。
3.软件工程？
软件工程的目标？
（……）
（1）定义：
软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。
它借鉴传统工程的原则、方法，以提高质量，降低成本为目的。
（2）软件工程旨在开发满足用户需要、及时交付、不超过预算和无故障的软件，其主要目标如下：
a.实现预期的软件功能，达到较好的软件性能，满足用户的需求。
b.增强软件过程的可见性和可控性，保证软件的质量。
c.提高所开发软件的可维护性，降低维护费用。
d.提高软件开发生产率，及时交付使用。
e.合理预算开发成本，付出较低的开发费用。
4.软件生存周期模型？
主要的模型类型？
（……）
（1）软件生命周期:
软件生存周期大体可分为如下几个活动：
问题定义、可行性研究、需求分析、设计、编码、测试、运行和维护。
（2）典型的软件过程模型有：
瀑布模型（waterfallmodel）
演化模型（evolutionarymodel）
增量模型（incrementalmodel）
原型模型（prototypingmodel）
螺旋模型（spiralmodel）
喷泉模型（waterfountainmodel）
基于构件的开发模型（component-baseddevelopmentmodel）
形式方法模型（formalmethodsmodel）
5.软件工程强调（文档化、规范化）？
（……）
（1）软件工程强调规范化和文档化。
规范化的目的是使众多的开发者遵守相同的规范，使软件生产摆脱个人生产方式，进入标准化、工程化的生产方式。
（2）文档化是将软件的设计思想、设计过程和实现过程完整地记录下来，以便于后人的使用和维护，在开发过程中各类相关人员借助于文档进行交流和沟通。
另外，在开发过程中产生的各类文档使得软件的生产过程由不可见变为可见，便于管理者对软件生产进度和开发过程进行管理。
在用户最终验收时可以通过对提交的文档进行技术审查和管理审查，保证软件的质量。
二、可行性研究及需求分析
1.可行性研究的目的
（1）用最小的代价在尽可能短的时间内确定问题是否能够解决。
不是解决问题，而是确定问题是否值得去解决。
（2）说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性；评述为合理地达到开发目标可能选择的各种方案。
2.需求分析的任务、方法、工具
（1）任务：
需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。
（2）方法：
a.访谈
b.面向数据流自顶向下求精
c.简易的应用规格说明技术
d.快速建立软件原型
（3）工具：
3.数据流图（作用）
（1）定义:
数据流图（DataFlowDiagram）：
简称DFD,它从数据传递和加工角度,以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程,是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
数据流图是结构化分析方法中使用的工具,它以图形的方式描绘数据在系统中流动和处理的过程,由于它只反映系统必须完成的逻辑功能,所以它是一种功能模型。
数据流图英文缩写DFD（DataFlowDiagram）它是描绘信息流和数据从输入移动到输出的过程中所经受的变换。
数据流图从数据传递和加工的角度,以图形的方式刻画数据流从输入到输出的移动变换过程。
（2）作用：
a.便于用户表达功能需求和数据需求及其联系；
b.便于两类人员共同理解现行系统和规划系统的框架；
c.清晰表达数据流的情况；
d.有利于系统建模.
4.判断表、判断树
（1）判断表：
如果数据流图的加工需要依赖于多个逻辑条件的取值，使用判定表来描述比较合适。
以“检查发货单”为例：
（2）判断树：
判定树也是用来表达加工逻辑的一种工具。
有时侯它比判定表更直观。
以“检查发货单”为例：
三、概要设计
1.划分模块的标准（高内聚低耦合）
（1）什么是耦合?
模块的耦合包括哪些类型？
耦合是对一个软件结构内不同模块之间互连程度的度量。
模块的耦合包括以下几种类型：
数据耦合，控制耦合，特征耦合，公共环境耦合，内容耦合，标记耦合，无耦合/非直接耦合
（2）什么是内聚?
模块的内聚包括哪些类型？
内聚标志着一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。
模块的内聚包括以下几种类型：
低内聚—偶然内聚，逻辑内聚，时间内聚中内聚—过程内聚，通信内聚；高内聚—顺序内聚，功能内聚。
2.模块独立性?
衡量的标准？
（……）
（1）模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他模块的接口是简单的。
（2）模块的独立程度可以由两个定性标准度量:
a.耦合:
模块之间的相对独立性的度量。
b.内聚:
模块功能强度的度量
耦合与内聚都是模块独立性的定性标准，都反映模块独立性的良好程度。
3.启发性规则
给软件工程师以有益的启示，往往能帮助他们找到改进软件设计提高软件质量的途径。
下面介绍几条启发式规则：
（1）改进软件结构提高模块独立性
设计出软件的初步结构以后，应该审查分析这个结构，通过模块分解或合并，力求降低耦合提高内聚。
例如，多个模块公有的一个子功能可以独立成一个模块，由这些模块调用；有时可以通过分解或合并模块以减少控制信息的传递及对全程数据的引用，并且降低接口的复杂程度。
（2）模块规模应该适中
经验表明，一个模块的规模不应过大，最好能写在一页A4纸内（通常不超过60行语句）。
有人从心理学角度研究得知，当一个模块包含的语句数超过30以后，模块的可理解程度迅速下降。
过大的模块往往是由于分解不充分，但是进一步分解必须符合问题结构，一般说来，分解后不应该降低模块独立性。
过小的模块开销大于有效操作，而且模块数目过多将使系统接口复杂。
因此过小的模块有时不值得单独存在，特别是只有一个模块调用它时，通常可以把它合并到上级模块中去而不必单独存在。
（3）深度、宽度、扇出和扇入都应适当.
深度：
软件结构中控制的层数；
宽度：
软件结构内同一个层次上的模块总数的最大值；
扇出：
一个模块直接控制（调用）其它模块的数目；
扇入：
一个模块被其它模块调用的数目。
（4）模块的作用域应该在控制域之内
作用域：
受该模块内一个判定影响的所有模块的集合。
控制域：
模块本身以及所有从属于它的模块的集合。
（5）力争降低模块接口的复杂度
模块接口复杂是软件发生错误的一个主要原因。
应该仔细设计模块接口，使得信息传递简单并且和模块的功能一致。
如：
QUAD-ROOT（TBL,X）
求一元二次方程的根的模块，其中TBL，X都为数组，分别代表方程的系数和方程的根。
应该使接口更简单，如：
QUAD-ROOT（A,B,C,ROOT1,ROOT2）
A、B、C是方程的系数，ROOT1，ROOT2是方程的根。
（6）设计单入口单出口的模块
（7）模块功能应该可以预测
以上列出的启发式规则多数是经验规律，对改进设计，提高软件质量，往往有重要的参考价值；但是，它们既不是设计的目标也不是设计时应该普遍遵循的原理。
4.深度、宽度、扇出和扇入
（1）深度往往能粗略地标志一个系统的大小和复杂程度。
深度和程序长度之间应该有粗略的对应关系，当然这个对应关系是在一定范围内变化的。
如果层数过多则应该考虑是否有许多管理模块过分简单了，能否适当合并。
（2）一般说来，宽度越大系统越复杂。
对宽度影响最大的因素是模块的扇出。
（3）扇出过大意味着模块过分复杂，需要控制和协调过多的下级模块；扇出过小（例如总是1）也不好。
经验表明，一个设计得好的典型系统的平均扇出通常是3或4（扇出的上限通常是5～9）。
（4）扇出太大一般是因为缺乏中间层次，应该适当增加中间层次的控制模块。
扇出太小时可以把下级模块进一步分解成若干个子功能模块，或者合并到它的上级模块中去。
当然分解模块或合并模块必须符合问题结构，不能违背模块独立原理。
（5）扇入越大则共享该模块的上级模块数目越多，这是有好处的，但是，不能违背模块独立原理单纯追求高扇入。
（6）观察大量软件系统后发现，设计得很好的软件结构通常顶层扇出比较高，中层扇出较少，底层扇入到公共的实用模块中去（底层模块有高扇入）。
5.面向数据流的设计方法
（1）面向数据流设计（DataFlow-OrientedDesign，DFOD）是与数据流分析（DFA）对应的结构化软件设计技术。
（2）面向数据流的设计要解决的任务，就是在需求分析的基础上，将表示系统逻辑模型的DFD图映射（Mapping）成软件系统结构的初始设计描述。
6.变换设计
（1）变换设计就是从变换型数据流图映射出软件模块结构的过程，也称以变换为中心的设计。
（2）变换型数据处理问题的工作过程大致分为三步，即取得数据，变换数据和给出数据。
（3）相应于取得数据、变换数据、给出数据，变换型系统结构图由输入、中心变换和输出等三部分组成。
（4）变换分析方法由以下四步组成：
a.重画数据流图；
b.区分有效（逻辑）输入、有效（逻辑）输出和中心变换部分；
c.进行一级分解，设计上层模块。
把整个变换分解成输入控制模块Ci、输出控制模块Co和变换中心控制模块Ct，由主控模块控制；
d.进行二级分解，设计输入、输出和中心变换部分的中、下层模块。
7.事物设计
（1）事务设计就是从事务型数据流图映射出软件模块结构的过程，也称为以事务为中心的设计。
（2）它接受一项事务，根据事务处理的特点和性质，选择分派一个适当的处理单元，然后给出结果。
（3）在事务型系统结构图中，事务中心模块按所接受的事务的类型，选择某一事务处理模块执行。
各事务处理模块并列。
每个事务处理模块可能要调用若干个操作模块，而操作模块又可能调用若干个细节模块。
（4）事务设计的基本方法有两步：
a.建立主控模块、接收输入类型分析模块和事务调度模块.
b.分别设计输入类型分析模块和调度模块的下层模块结构。
方法是：
将输出的每条通路作为调度模块的一个判断分支，而输入类型分析模块的下层模块与变换设计类似。
四、详细设计
1.SA方法（基本思想）
2.面向对象分析方法建造的模型（对象模型、行为模型、功能模型）
（1）对象模型
（2）行为模型
（3）功能模型
3.结构化程序设计的控制结构（顺序、分支、循环）
（1）顺序结构
（2）分支结构
（3）循环结构
4.程序流程图、N-S盒图、PAD图、PDL语言
（1）程序流程图:
程序流程图也称为程序框图，它使用五种基本控制结构。
（2）N-S盒图:
出于要有一种不允许违背结构程序设计精神的图形工具的考虑，Nassi和Shneiderman提出了盒图，又称为N-S图。
它有下述特点：
a.功能域（即，一个特定控制结构的作用域）明确，可以从盒图上一眼就看出来。
b.不可能任意转移控制。
c.很容易确定局部和全程数据的作用域。
d.很容易表现嵌套关系，也可以表示模块的层次结构。
（3）PAD图:
用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易。
它即克服了传统的流程图不能清晰表现程序结构的缺点，又不像N-S图那样受到把全部程序约束在一个方框内的限制，这就是其优势所在。
（6）PDL语言:
PDL是一种用于描述功能模块的算法设计和加工细节的语言。
称为过程设计语言。
它是一种伪码。
伪码的语法规则分为“外语法”和“内语法”。
PDL具有严格的关键字外语法，用于定义控制结构和数据结构，同时它的表示实际操作和条件的内语法可使用自然语言的词汇。
5.计算McCabe环路复杂性度量（3种方法）
McCabe度量法，又称环路复杂性度量，是一种基于程序控制流的复杂性度量方法。
它基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图。
程序图是退化的程序流程图。
流程图中每个处理都退化成一个结点，流线变成连接不同结点的有向弧（边）。
程序图仅描述程序内部的控制流程，完全不表现对数据的具体操作，以及分支和循环的具体条件。
（1）流图中的区域数等于环形复杂度
区域：
由边和结点围成的面积称为区域，当计算区域数时应该包括图外部未被围起来的那个区域.
（2）流图G的环形复杂度V（G）=E–N+2.其中，E是流图中边的条数，N是结点数。
（3）流图G的环形复杂度V（G）=P+1
其中，P是流图中判定结点的数目。
五、编码与测试
1.序言性注释的作用
通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。
（1）夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。
注释决不是可有可无的。
（2）一些正规的程序文本中，注释行的数量占到整个源程序的1/3到1/2，甚至更多。
（3）注释分为序言性注释和功能性注释。
2.软件测试的目的
（1）想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。
如果成功地实施了测试，就能够发现软件中的错误。
（2）测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。
（3）实施测试收集到的测试结果数据为可靠性分析提供了依据。
（4）证明软件有错。
3.集成测试策略（驱动模块、桩模块）
（1）集成测试是测试和组装软件的系统化技术，其主要目标是发现与接口有关的问题。
如：
数据穿过接口时可能丢失；一个模块对另一个模块可能由于疏忽而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有问题等等。
（2）计算机测试：
模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。
要运行它就必须为其开发驱动软件和（或）存根（桩）软件。
驱动程序也就是一个“主程序”，它接收测试数据，把这些数据传送给被测试的模块，并且印出有关的结果。
存根（桩）程序代替被测试的模块所调用的模块，也称为“虚拟子程序”。
它使用被它代替的模块的接口，可能做最少量的数据操作，印出对入口的检验或操作结果，并且把控制归还给调用它的模块。
（3）方法:
a.非渐增式测试方法，即：
先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序进行测试。
b.渐增式测试，即：
先把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。
这种每次增加一个模块的方法实际上同时完成单元测试和集成测试，目前在进行集成测试时普遍采用渐增式测试方法。
（4）渐增方式把模块结合到程序中去时，有自顶向下和自底向上两种集成策略。
但在实践中常采用混合的策略。
4.黑盒测试？
黑盒测试方法（等价类划分、边界值分析、错误推测、因果图法）
（1）定义：
如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用----称为黑盒测试。
（2）内容：
a.Alpha/BetaTesting
b.菜单/帮助测试
c.发行测试
d.回归测试
5.白盒测试（语句覆盖、判断覆盖、条件覆盖、判断/条件覆盖、条件组合覆盖）
（1）定义：
如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行----称为白盒测试。
也叫玻璃盒测试（GlassBoxTesting），对软件的过程性细节做细致的检查。
这一方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，来设计或选择测试用例，对程序所有逻辑路径进行测试。
（2）内容：
a.对程序模块的所有独立执行路径至少测试一次。
b.对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测试一次。
c.在循环的边界和运行边界限内执行循环体。
d.测试内部数据结构的有效性。
六、软件维护
影响维护工作量的因素？
（……）
影响软件维护工作量的因素有：
1）系统大小。
系统越大，功能越复杂，理解掌握起来就越困难，需要的维护工作量越大。
2）程序设计语言。
使用功能强的程序设计语言可以控制程序的规模。
语言的功能越强，生成程序所需的指令数就越少；语言的功能越弱，实现同样功能所需的语句就越多，程序就越大，维护起来就越困难。
3）系统年龄。
老系统比新系统需要更多的维护工作量。
许多老系统在当初并未按照软件工程的要求进行开发，没有文档，或文档太少，或者在长期的维护中许多地方与程序不一致，维护起来困难较大。
4）数据库技术的应用。
使用数据库工具，可有效地管理和存储用户程序中的数据，可方便地修改、扩充报表。
数据库技术的使用可以减少维护工作量。
5）先进的软件开发技术。
在软件开发时，如果使用能使软件结构比较稳定的分析与设计技术（如面向对象分析、设计技术），可以减少一定的工作量。
6）其它。
如，应用的类型、数学模型、任务的难度、IF嵌套深度等等都会对维护工作量产生一定的影响。
升级会员 