-
什么是软件?软件包括哪些基本组成要素?什么是软件工程?软件工程主要包括哪几个基本要素?
- 是一系列按照特定顺序组织的计算机数据和指令的集合,包括程序、数据和文档。
- 软件工程:应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴传统工程的原则、方法,以提高质量,降低成本为目的。
- 三要素:过程,方法,工具
-
什么是软件过程?典型的软件过程模型有哪几种?
- 软件过程:一组有序的任务,包括活动、约束和资源使用的一系列步骤,用于产生想要的输出
- 软件过程模型:瀑布模型,V模型,原型化模型,螺旋模型,增量和迭代,敏捷方式
-
什么是里程碑
- 里程碑是用来说明项目进展情况的事件,在软件工程项目中规划时间节点,从而来管控项目进度。
-
什么是数据字典?
- 数据字典(DD)是描述数据的信息的集合,是对系统中使用的所有数据元素/数据流图中包含的所有元素的定义的集合。是为了描述在结构化分析过程中定义对象的内容时,使用的一种半形式化的工具。
- 数据字典中的每一个词条应包含以下信息
- 名称:数据对象或控制项、数据存储或外部实体的名字
- 别名或编号
- 分类:数据对象?数据流?数据文件?外部实体
- 描述:描述内容或数据结构等
- 何处使用:使用该词条(数据或控制项)的加工
- 数据词典精确地、严格地定义了每一个与系统相关的数据元素,并以字典式顺序将它们组织起来,使得用户和分析员对所有的输入 、输出、存储成分和中间计算有共同的理解
-
黑盒测试和白盒测试的基本概念,其主要不同点是什么?
对比 黑盒测试 白盒测试 别名 功能测试,数据驱动测试,基于规格说明书的测试 开盒测试,结构测试,玻璃盒测试,基于覆盖的测试 概念 不深入代码细节的测试方法 对软件的过程性细节做细致的检查 主要不同 从用户观点,按规格说明书要求的输入数据和输出数据的对应关系设计测试用例,是根据程序的外部特征进行测试 根据程序内部逻辑结构进行测试 性质区别 是一种确认技术,回答“我们在构造一个正确的系统吗?” 是一种验证技术,回答“我们在正确地构造一个系统吗?” -
什么是结构化分析?结构化分析包括哪几种图,各个图的主要作用是什么?
- 结构化分析:结构化分析(SA)方法,它用抽象的概念,按照软件内部的数据传递、变换的关系,自顶向下逐层分解的系统分析方法来定义系统的需求。
- 数据流图、实体关系图、状态-迁移图
- 数据流图(DFD):描述数据在目标系统中如何被传送或变换,以及描述如何对数据流进行变换,用于功能建模
- 实体-关系图(E-R):描述数据对象及数据对象之间的关系,用于数据建模
- 状态-迁移图(STD):描述系统对外部事件如何响应、如何动作,用于行为建模
- 结构化分析方法使用工具:数据字典,实体关系图,数据流图,状态迁移图,逻辑说明工具
-
什么是面向对象分析OOA? OOA有哪几种基本模型,各种模型分别对应哪些UML图?
- OOA定义:是确定需求或业务的角度,按照面向对象的思想来分析业务
- 分类:
- 需求模型:
- 用况图:捕获与描述用户的要求
- 基本模型(类图)
- 对象层:给出所有问题域和系统责任有关的对象,用对象类表示
- 特征层:定义每个对象类的属性与服务
- 关系层:通过以定义的关系描述对象类之间的关系
- 辅助模型
- 交互图:完成某项特定功能的一组对象之间的详细交互
- 状态图:一个对象的状态变迁
- 活动图:一个服务的流程或业务流程
- 包图:对关系密切的元素打包,帮助理解系统模型
- 需求模型:
-
模块化设计的基本原则是什么?什么是分治原则?使用分治原则有哪些注意事项?
-
什么是集成测试?集成有哪些基本方式?
-
集成测试的定义:又称组成测试或联合测试。在单元测试的基础上,将所有模块按照设计要求组装成系统,进行集成测试。
-
集成(组装成系统)的基本方式:
集成基本方式 一次性组装方式 增殖式组装方式 别名 整体拼装 渐增式组装 概念(过程) 首先对每个模块分别进行模块测试,然后再把所有模块组装在一起测试。 首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统,在组装过程中边连接边测试,已发现连接中的问题。最后通过增殖逐步组装成为要求的软件系统。 - 增殖式组装方式进一步分类
- 自顶向下的增殖方式
- 自底向上的增殖方式
- 混合增殖式测试
- 增殖式组装方式进一步分类
-
-
什么是单元测试?单元测试有哪些基本方式?
- 单元测试:又称模块测试,对源程序中每一个程序单元进行测试,检查各个模块是否正确实现规定的功能,从而发现模块在编码中或算法中的错误
- 模块接口测试,局部数据结构测试,路径测试,错误处理测试,边界测试
-
什么是环路复杂度?环路复杂度主要应用在软件开发的哪个方面?环路复杂度如何计算?什么是独立路径,如何找出独立路径?
- 环路复杂度定义:用来度量程序中的逻辑复杂度,定义为控制流程图中的区域数
- 主要应用在软件开发的软件测试方面(通过分析控制构造的环路复杂性,到处基本可执行路径集合,从而设计测试用例)
- 环路复杂度的计算:
- 定义为控制流程图中的区域数(区域为:边和结点圈定的范围)
- 设E为控制流图的边数,N为图中的结点数,则(V(G)=E-N+2)
- 设P为控制流图中的判定结点数,则:(V(G)=P+1)
- 独立路径:独立路径式指包括一组没有处理的语句或条件的一条路径
- 如何找出独立路径:从流控图上看,一条独立路径就是至少包含又一条在其他独立路径中从未含有的边的路径。
-
什么是软件体系结构?典型的软件体系结构分哪几类?其主要特征和应用场景是什么?
- 软件体系结构:是系统的一个或多个结构,为软件系统提供了一个结构、属性和行为的高级抽象。包括
- 软件的组成元素(组件)
- 这样协议的外部可见特性
- 这些元素之间的相互关系
- 软件体系结构不仅指定了系统的组织结构和拓扑结构,并且显示了系统需求和构成系统的元素之间的对应关系,提供了一些设计决策的基本原理
- (!)分为以下几类(软件体系结构的建模):
- 结构模型:
- 这是一个最直观、最普遍的建模方法。
- 这种方法以体系结构的构件、连接件和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质。
- 研究结构模型的核心是体系结构描述语言。
- 框架模型:
- 与结构模型类似,但不太侧重描述结构的细节而更侧重于整体的结构。
- 框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
- 动态模型
- 是对结构或框架模型的补充,研究系统的"大颗粒"的行为性质。例如,描述系统的重新配置或演化。
- 动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。这类系统常是激励型的。
- 过程模型
- 过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果
- 功能模型
- 该模型认为体系结构是由一组功能构件按层次组成,下层向上层提供服务。它可以看作是一种特殊的框架模型。
- 结构模型:
- 软件体系结构:是系统的一个或多个结构,为软件系统提供了一个结构、属性和行为的高级抽象。包括
-
什么是UML? UML动态模型包括哪几种图? UML静态建模包括哪几种图?
-
UML(统一建模语言)是:面向对象分析和设计的图形化建模语言。
-
UML动态模型图:
- 状态模型:状态图、活动图
- 交互模型:描述对象之间的动态合作关系以及合作过程中的行为次序。(序列图和协作图可相互转换,语义上等价)
- 序列图:描述对象之间的信息交互时的时间顺序
- 协作图:描述系统对象之间如何协作共同完成系统功能的需求(结构方面)
-
UML静态模型图:类图、对象图、用例图、部署图、构件图
-
-
快速原型法主要应用的目的是什么?原型发包括哪几种基本类型?
- 快速原型是快速建立起来的可以在计算机上运行的程序
- 目的:获知用户的真正需求,一旦需求确立了,原型将被抛弃。
-
需求规格说明书(SRS)中主要包括哪几方面的内容?
- 引言
- 任务概述(项目概述)
- 数据描述(DFD、DD)
- 功能描述
- 接口
- 性能需求
- 属性
- 其他需求
-
面向对象的典型特征包括哪几个方面
- 面对对象设计的基本特性:抽象、封装、继承、多态
- 面向对象的特性(ppt):标识,抽象,分类,封装,继承,多态,持久性.
-
软件测试的基本步骤,这些步骤的测试目标对象是什么?什么是V模型?
-
基本步骤 概念 目标对象 依赖的文档 单元测试 检验每个模块能否单独工作 对象的单元模块 详细设计说明书、源程序清单 集成测试 检验概要设计中模块接口设计问题 组装后的程序模块 概要设计说明书 确认测试 以需求规格说明书为检验尺寸 可运行的目标软件 需求规格说明书 系统测试 综合检验 整个系统 需求规格说明书 -
什么是V模型
- 是瀑布模型的一个变种
- 用单元测试验证程序设计
- 用系统测试验证系统设计
- 用验收测试验证需求
- 如果在验证和确认过程中发现了问题,那么再次执行右边的测试步骤之前,重新执行左边的步骤以修正左边
-
-
什么是软件危机?软件危机主要表现有哪些方面?
- 计算机软件开发与维护过程中所遇到的一系列严重问题
- 软件的发展速度远远滞后于硬件的发展速度,不能满足社会日益增长的软件需求
- 原因:
- 与软件本身的特点有关
- 与软件开发人员有关
- 表现:
- 软件开发周期长
- 软件开发成本高
- 软件质量差
- 软件维护困难
-
什么是“瀑布模型"?其主要缺陷是什么?造成这些缺陷的根本原因是什么?
- 什么是瀑布模型?
- 是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作,形如瀑布流水,最终得到软件
- 瀑布模型的主要缺陷:
- 几乎完全依赖于书面规格说明,很可能导致最终开发出的软件产品不能真正满足用户的需要
- 只适用于项目开始时需求已确定的情况
- 对如何处理开发中产品和活动的变化没有提供相关的制导
- 将软件开发视为制造而不是创造
- 创造一个产品没有迭代的活动
- 需要等待很长的时间
- 造成这些缺陷的根本原因:瀑布模型的各个阶段顺序是固定的,难以满足变化的需求。
- 什么是瀑布模型?
-
UML中的主要视图包括哪些图形?它们分别应用在软件生存周期的哪些阶段?
- 用例图:用来表示系统和用户参与的公共活动的集合,也描绘了每个用例的参与者
- 类图:在设计过程中的开始阶段用于定义应用的领域模型,系统中数据和对象的关系、对象之间的关系,对象可以执行的操作
- 用例图:用例图表示了角色和用例以及它们之间的关系。
- 类图:通过关系和类表示的类图,可以图形化的方式描述一个系统的设计部分。
- 对象图:它是描述系统在某个时刻的状态,对象图即可用于建模系统潜在的实质性的内容,也可以得到当前驻留在某个系统中的数据在某个时刻的系统快照
- 状态图: 描述类的对象所有可能的状态,以及事件发生时状态的转移条件,对类图的补充
- 序列图:用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。
- 协作图:通过描绘对象之间消息的移动情况来反映具体的方案。显示对象及其交互关系的空间组织结构,而非交互的顺序。
- 活动图:用于标识系统中的处理流程,与程序流程图不同,活动图包括超越于代码本身之上的用户活动,并能够清楚的描绘系统中的各个参与者分别扮演的不同角色
- 组件图:组件图的主要目的是显示系统组件间的结构关系,反映代码的物理结构
- 部署图(配置图):用来简要说明一个系统将如何分布于物理资源之上,也为系统在部署阶段对系统配置进行文档说明
- 需求分析阶段:业务用例图
- 概要分析阶段:用类图描述静态结构,用顺序图,合作图,活动图,状态图描述动态行为
- 详细设计阶段:类图、包图
- 实现
-
软件生存周期分为几个阶段,每个阶段的重点工作什么?每个阶段的输出物是什么?
-
阶段 主要任务 输出 问题定义 弄清“用户需要计算机解决什么问题” 用户审查和确认 可行性研究与计划 对问题是否行得通的解决方法 可行性论证报告
初步的项目开发计划需求分析 为了解决这个问题,目标系统必须做什么 软件需求规格说明书 总体设计 应该怎么实现目标系统 概要设计规格说明书
数据库或数据结构设计说明书
集成测试计划详细设计 应该怎样具体地实现这个系统 详细设计规格说明书
单元测试计划实现 写出正确的容易理解、容易维护的程序模块 源程序代码 集成测试 根据概要设计规格说明书,将经过单元测试的模块逐步进行集成和测试 满足概要设计要求、可运行的系统源程序和系统集成测试报告 确认测试 根据软件需求规格说明书,测试软件系统是否满足用户的需求 可供用户使用的软件产品 使用和维护 通过各种必要的维护活动使系统持续地满足用户的需要 版本更新
-
-
软件产品质量模型中有哪些指标?各个指标的基本含义分别是什么?
- 正确性:程序能够满足规格说明和完成用户业务目标的程度
- 可靠性:程序能够按照要求的精度实现其预期功能的程度
- 效率:程序实现其功能所需要的计算机资源量
- 完整性:软件或数据不受未授权人控制的程度
- 可用性:学习、操作程序、为其准备输入数据、解释其输出的工作量
- 可维护性:对运行的程序找到错误并排除错误的工作量
- 测试性:为保证程序执行其规定的功能所需的测试工作量
- 灵活性:修改运行的程序所需的工作量
- 可移植性:将程序从一种硬件配置(或环境)转移到另一种硬件配置(或环境)所需工作量
- 可重用性:程序可被用于与其实现功能相关的其他应用问题的程度
- 互操作性:一系统与另一系统协同运行所需工作量
-
接口与抽象类之间的相同点和不同点分别是什么?如何在实践中理解和应用它们?
-
不同点
对比 接口 抽象类 概念 一组没有实现的操作的集合,是一个不带实现的类,它只规定类的外部特性,只有操作声明而没有方法体和物理存储区 指不具有任何对象的类,允许增加一些方法的实现 语义 是一组具有相同属性和方法的逻辑上不相关的事物的一种抽象。 抽象类是一种类对一组具有相同属性和方法的逻辑上有关系的事物的一种抽象。 数据成员 只能有静态的不能修改的数据成员 可以有自己的数据成员,也可以有非abstract的成员方法 关系 一个类可以实现多个接口 表示一种继承关系,一个类只能使用一次继承关系 默认行为 不能有 可以有 -
相同点
- 都是只定义接口而推迟定义其实现部份
-
-
需求分析的基本任务是什么?需求分析过程中主要面临哪些问题?针对这些问题采用哪些解决方法?
- 准确地定义未来系统的目标,确定为了满足用户的需求系统必须做什么。用 <需求规格说明书> 规范的形式准确地表达用户的需求。
- 基本任务
- 准确了解用户情况和需要解决的问题
- 对需求反复求精和细化,得出对目标系统完整、准确和具体的要求
- 需求建模:对获得的需求做出抽象,进行无歧义描述
- 编制需求规格说明书
- 进行需求分析的评审
- 问题:
-
综合运用软件工程的基本框架和活动、原理与方法,针对经典的信息系统进行分析与设计,熟练掌握和运用面向对象分析与设计思想和主要UML的画法。