软件工程期末速成--附带几道题
软件工程中的各种设计
瀑布模型:
定义:将软件生存周期的各项活动规定为依照固定顺序连接的若干阶段工作,形如瀑布流水,最终得到软件产品
系统流程图:系统流程图是描绘物理系统的传统工具,它的基本思想是用图形符号以黑盒子形式描绘系统里面的每一个部件(程序、文件、数据库、表格、人工过程等)
数据流图:DFD是一种描述逻辑模型的图形工具,表示数据在系统内的变化。图中没有任何具体的物理元素,只是描绘信息在系统中流动和处理的情况。DFD从数据传递和加工的角度,以图形的方式刻画数据流从输入到输出的移动变换过程。它由数据流、加工、文件和数据流的源点和终点构成。
数据字典:是一种描述逻辑模型的工具。它对于数据流图中所出现的所有被命名的图形元素作为一个词条加以定义,使得每一个图形元素的名字都有一个确切的解释。DD的内容包括:图形元素的名字、别名或编号、分类、描述、定义、位置等。
ER图:学过数据库的应该都知道这个东西
ERD描绘了系统的数据关系。分析实体联系图有助于对业务或系统数据组成的理解和交互,并暗示产品将有必要包含一个数据库。ER模型三要素有:数据对象、属性和联系
状态转换图:
状态转换图简称状态图。通过描绘系统的状态及引起系统状态转换的事件,来表示系统的行为。它由1个初态/初始状态、0-N个终态/最终状态和若干个中间状态组成
层次方框图
用属性结构的一系列多层次的矩形框描述数据的层级结构
IPO图:定义:输入、处理、输出图的简称
层次图
层次图(也称H图)是在总体设计阶段最常使用的图形工具之一,它常用于描绘软件的层次结构。矩形代表一个模块,连线表示调用关系,适于在自顶向下设计软件的过程中使用;与层次方框图类似
HIPO图
是IBM公司发明的“层次图加输入/处理/输出图”的缩写;为了能使HIPO图具有可跟踪性,在H图例除了最顶层的方框之外,每个方框都加了编号:和H图中的每个方框相对应,有一张IPO图描述这个方框代表的模块的处理过程。IPO图能够方便地描述数据输入、数据处理和数据输出之间的关系。
结构图
一个方框/矩形代表一个模块,箭头连线/直线表示调用关系,带有注释的箭头表示模块调用过程中来回传递的信息
程序流程图:
N-S图:
其主要特点包括:
[1]功能域明确;
[2]不可以随意转移;
[3]容易确定局部和全局数据的作用域;
[4]容易表达嵌套关系
判定表
某数据流图的加工需要依赖于多个逻辑条件的取值,就是说完成这一加工的一组动作是由于某一组条件取值的组合而引发的。这时使用判定表来描述比较合适。判定表通常由四部分组成,即:条件桩、操作桩、条件条目和操作条目。
判定树:判定表的变种
用例图:
用例图是被称为参与者的外部用户所能观察到的系统功能概念的模型图;用例是系统中的一个功能单元,可以描述为参与者与系统之间的一次交互作用;用例图的用途是列出系统中的用例和参与者,并显示哪个参与者参与了哪个用例的执行
活动图:
活动图描述了活动发生的顺序。其图形表示规则如下:
•圆角矩形表示方框中的活动;
•矩形表示工作流影响的对象;
•实心圆表示工作流开始的开始状态;
•双层圆表示工作流结束的结束状态;
•菱形表示决策点;
•垂直甬道表示工作流中的不同参与者及相关活动
顺序图:
顺序图表示对象之间传递消息的时间顺序
垂直线表示一个对象的生命周期
箭头表示信息
协作图
§协作图对在一次交互中有意义的对象和对象间的链建模
类图:以类为中心组织起来的图形,用以表示软件系统中各类之间的相互关系
连线表示类的关系
状态图:
状态图是一个类对象所经历的所有历程的模型图。状态图有对象的各个状态和连接这些状态的变迁组成
部署图:
用来描述位于节点实例上的运行组件的安排,描述系统的实际物理结构
软件工程中的一些基本概念
可行性研究报告的一般格式:GB8567-88
软件危机是指软件开发和维护中存在的一系列问题。它主要面临的问题是: 进展难衡量、质量难评估、管理难控制。
软件工程是指开发、运行、维护、修复软件的系统方法
软件工程的中心课题是控制复杂性
目前使用得最广泛的两种软件工程方法学:传统方法学、面向对象方法学。
成本估计
代码行,任务分解技术
效益的度量方法
货币的时间价值,投资回收期,纯收入
需求分析的具体任务包括
确定综合需求
分析数据需求
导出逻辑模型
修正开发计划
验证分析正确性
编写需求说明书
软件的综合需求
功能需求,性能需求,可靠性和可用性,出错处理,接口需求,约束
需求获取方法
访谈,面向数据流自顶向下求精,应用规格说明
需求分析阶段用到的模型
数据流图(DFD):用于建立功能模型
实体-联系图(ERD):用于建立数据模型
类图:用于建立结构模型
时序图:用于建立行为模型
状态图:用于建立行为模型
协作图:用于建立行为模型
总体设计的两个阶段
系统设计:确定系统的具体实现方案
结构设计:确定软件结构
系统设计包括:设想供选择的方案,选取合理的方案,推荐最佳方案
结构设计:功能分解,设计软件结构,设计数据库,制定测试计划
对象模型
对象模型是对对象及其关系的映射,描述了系统的静态结构。通常使用统 一建模语言 (UML) 的类图来建立对象模型。
软件生命周期划分
软件定义:可行性研究和计划,需求分析
开发期:总体设计,详细设计,编码实现,集成测试
软件维护:确认测试,使用和维护
耦合和内聚
耦合用于衡量不同模块之间相互依赖的紧密程度,越低越好。应该追求「松 散耦合」的系统。
耦合设计原则: • 多用数据耦合 • 少用控制耦合 • 限制公共耦合
内聚用于衡量一个模块内部各元素彼此结合的紧密程度,越高越好
内聚设计原则: • 力求高内聚 • 可用中内聚 • 避免低内聚
软件工程的七条基本原理:
1.用分阶段的生命周期计划严格管理;
2.坚持进行阶段评审;
3.实行严格的产品控制;
4.采用现代程序设计技术;
5.结果应能够清楚地审查;
6.开发小组的人员应少而精;
7.承认不断改进软件工程实践的必要性。
软件生存期的阶段划分
面向对象的方法学
可行性分析
包含三个方面:技术可行性,经济可行性,操作可行性
可行性研究过程
各种需求分析方法所应遵循的准则
需求分析的具体任务
系统结构特征可归纳为两种经典形式
变化型结构和事务型结构
数据流图可分为两种类型
变换性数据流和事务型数据流
划分等价类的原理
各种覆盖
语句覆盖:使程序中每个语句至少执行一次;
判定覆盖(分支覆盖):使每个判定的真假分支都至少执行一次;
条件覆盖:使每个判定的每个条件的可能取值至少执行一次;
判定/条件覆盖:选取足够多的测试用例,使判断中的每个条件的所有可能取值至少执行一次。选取足够多的测试用例,同时每个判断本身的所有可能判断结果至少执行一次;
条件组合覆盖:使每个判断表达式中条件的各种可能组合至少出现一次。
选择题
软件工程产生的直接原因是软件危机。在20世纪60年代末期,随着计算机硬件的快速发展和应用需求的剧增,软件开发过程中出现了一系列严重问题:软件开发成本超支、进度延迟、质量低下、维护困难等。这些问题集中体现为"软件危机"。为了解决这场危机,人们开始研究用工程化的方法来开发软件,由此诞生了软件工程这门学科。
针对学生成绩范围0-100的黑盒测试等价类划分,应该划分为3个等价类:
1. 有效等价类(1-100分): 表示正常的成绩范围
2. 无效等价类1(小于0分): 表示异常的负分情况
3. 无效等价类2(大于100分): 表示超出满分的异常情况
IPO图(Input Process Output)是一种程序流程图,主要由输入框(Input)、处理框(Process)和输出框(Output)这三个基本组成部分构成。
在软件维护的类型中,完善性维护专门针对用户提出的新功能需求或对现有功能的改进建议,对软件进行功能扩充和完善的维护活动,所以C选项是正确答案。
分析其他选项:
A. 预防性维护:是为了预防软件出现故障而进行的维护活动,主要包括代码重构、性能优化等,并非针对用户新功能需求。
B. 适应性维护:是为了使软件适应新的运行环境(如硬件、操作系统等变化)而进行的修改,重点在于环境适应性,而不是功能改进。
D. 纠错性维护:是针对软件运行中发现的错误进行修复的维护活动,目的是纠正软件缺陷,而不是添加新功能。
软件工程的基本要素包括方法、工具和( A )。
A. 过程 B. 软件系统 C. 硬件环境 D. 人员
在需求阶段,反映需求过程本身质量的可度量属性应该是功能点的可追踪性和实现过程的稳定性
系统流程图是用图形符号来表示系统中的各个元素,例如人工处理、数据库、设备等,流程图表达了系统中各个元素之间的信息流动情况。是描绘物理系统的传统工具。
黑盒测试:
- 不考虑程序内部逻辑结构,只关注软件的外部表现
- 测试用例基于需求规格说明书设计
- 验证软件功能是否符合用户需求
- 主要由测试人员执行
白盒测试:
- 需要了解程序内部逻辑结构和代码实现
- 测试用例基于代码覆盖设计
- 验证内部运行机制是否正确
- 主要由开发人员执行