Software Engineering Review


软件工程总复习

2023春季学期 QingDao University

第一章

软件的定义(P1)

软件是能够完成预定功能和性能的可执行的计算机程序,包括使程序正常执行所需要的数据,以及有关描述程序操作和使用的文档。

工程学范畴技术包括?(P4)

软件工程的分代是哪三代?作比较(P9)

构件的定义(P8)

构件(component,有些文献翻译为组件)可以理解为标准化(或者规格化)的对象类(参见2.3.3节)。它本质上是一种通用的、可支持不同应用程序的组件,正如硬件中 的标准件一样,插入不同的平台或环境后即可直接运行。

软件危机的定义、产生的主要原因(P2,3)

定义:庞大的软件费用,加上软件质量的下降,对计算机应用的继续扩大构成了巨大的威胁。面对这种严峻的形势,软件界的有识之士发出了软件危机的警告。

原因

  1. 软件维护费用急剧上升,直接威胁计算机应用的扩大

  2. 软件生产技术进步缓慢, 是加剧软件危机的重要原因

第二章

软件生存周期的定义、分为哪三个周期、那些阶段(P19)

一切工业产品都有自己的生存周期,软件(产品)也不例外。 一个软件从开始立项起,到废弃不用止,统称为软件的生存周期 (life cycle)。

软件生存周期被划为:计划、开发和运行3个周期。

  1. 需求分析
  2. 软件分析
  3. 软件设计
  4. 编码
  5. 软件测试
  6. 运行维护

增量模型的定义(P24)

增量模型 (incremental model) 是瀑布模型的顺序特征与快速原型法的迭代特征相结合的 产物。这种模型把软件看作一系列相互联系的增量 (increments),在开发过程的各次迭代中, 每次完成其中的一个增量。

各种演化模型特点、适合哪类软件开发(P24)

可行性研究的内容、步骤(P35)

  1. 研究的内容

    经济可行性。 实现这个系统有没有经济效益?多长时间可以收回成本?

    技术可行性。 现有的技术能否实现这一新系统?有哪些技术难点?建议采用的技术先进程度怎样?

    运行可行性。 为新系统规定的运行方式是否可行?例如, 若新系统是建立在原来已担负其他任务的计算机系统上的,就不能要求它在实时在线的状态下运行, 以免与原有的任务相矛盾。

    法律可行性。 新系统的开发会不会在社会上或政治上引起侵权、 破坏或其他责任问题?

  2. 研究的步骤

    对当前系统进行调查和研究。

    导出新系统的解决方案。

    提出推荐的方案。

    编写可行性论证报告:系统概述、可行性分析、结论意见

风险分析包括哪三项活动(P36)

  1. 风险识别
  2. 风险预测
  3. 风险的驾驭与监控

第三章

结构分析(SA)模型的组成(画图)*/(P45)

第一步:通过对现实环境的调查研究,获取当前系统的具体模型

第二步: 分析需求, 建立系统分析模型, 包括当前系统模型和目标系统模型。

  1. 去掉上述模型中的非本质因素, 提炼出当前系统的逻辑模型。
  2. 分析当前系统与目标系统的差别, 建立目标系统的逻辑模型。

第三步: 整理综合需求, 编写系统需求规格说明书。

第四步: 验证需求, 完善和补充对目标系统的描述。

  1. 通过目标系统的人机界面, 和用户一起确认目标系统功能, 主要是区分哪些功能交给计算机去做, 哪些功能由人工完成。
  2. 复审需求规格说明书, 补充迄今尚未考虑过的细节, 例如确定系统的响应时间、 增加出错处理等。

各部分的作用/应用

DFD是什么?表达____的一种图形化技术(P46)

数据流图,表达面向数据流的一种图形化技术

数据字典哪三类?(P47)

  1. 数据流
  2. 数据文件
  3. 数据项

画判定表、判定树*(P49)

数据流图哪两种类型(P57)

  1. 变换型结构
  2. 事务性结构

优化初始SC的指导原则(P62)

  1. 对模块划分的原则
  2. 高扇入/低扇出的原则

模块/详细设计的目的?(P65)

详细设计的目的, 是为SC图中的每个模块确定采用的算法和块内数据结构, 用选定的表达工具给出清晰的描述。 表达工具可由开发单位或设计人员自由选择, 但它必须具有描述过程细节的能力, 而且能在编码阶段直接将它翻译为用程序设计语言书写的源程序。

模块化设计原则、方法——实现清晰意图、可靠(P66-68)

  1. 清晰第一的设计风格

    “清晰第一,效率第二”

  2. 结构化的控制结构

    为了方便使用或者提高程序效率, 大多数软件开发项目还允许在详细设计中补充使 用 DO-UNTIL 和 DO-CASE 两种控制结构。

    在许多情况下, 当程序执行到满足某种条件时, 需要立即从循环中转移出来。

  3. 逐步细化的实现方法——错误较少,可靠性也比较高。

    由粗到细地对程序进行逐步的细化。

    在细化程序的过程时, 同时对数据的描述进行细化。

    每步细化均使用相同的结构化语言, 最后一般直接用伪代码来描述, 以便编码时直接翻译为源程序。

第四章

UML的两类图、五类视图、九种图是什么?(P82)

  1. 图是系统构架在某个侧面的表示,UML1.4提供了两大类图静态图和动态图,共计9种不同的图。

    1. 静态图

      用例图、类图、对象图、构件图和部署图

    2. 动态图

      状态图、时序图、协作图和活动图

  2. 视图

    用例视图(usecase view)。用例视图表达从用户角度看到的系统应有的外部功能,有时也称用户模型视图(usermodel view)。

    逻辑视图Clogical view)。逻辑视图主要用类图和对象图来描述系统的静态结构,它同时也描述对象间为实现给定功能发送消息时出现的动态协作关系,故称结构模型视图(structural model view)。

    进程视图(processview)。进程视图用于展示系统的动态行为及其并发性,也称行为模型视图(behavioralmodel view)。

    构件视图(componentview)。构件视图展示系统实现的结构和行为特征,包括实现模块和它们之间的依赖关系,也称实现模型视图(implementationmodel view)。

    部署视图(deploymentview)。部署视图显示系统的实现环境和构件被部署到物理结 构中的映射,如计算机、设备以及它们相互间的连接,哪个程序或对象在哪台计算机上执行 等。

用例之间的关系(选择)(P85)

用例之间的关系:

  1. 扩展关系 (extend)
  2. 包含关系 (include)

UML建模——构建关系、类、对象

P85—P91

第五章

软件需求分析四个步骤(P108)

  1. 需求获取
  2. 需求建模
  3. 需求描述
  4. 需求验证

面向对象的需求模型包括:(P114)

用例模型、补充规约和术语表

需求管理的特定实践包括:(P124)

  1. 获得对需求的理解。
  2. 获取需求承诺。
  3. 管理需求变更。 维护变更历史, 为调整与控制提供数据。
  4. 在需求变更后维护对需求的双向可追溯性。
  5. 标识项目工作(包括计划和产品)与需求的不一致性。

软件需求的定义、哪两方面理解(P105)

软件需求主要指一个软件系统必须遵循的条件或具备的能力。 这里的条件或能力可以从两个方面来理解:一是用户解决问题或达到目标所需的条件或能力, 即系统的外部行为; 二是系统为了满足合同、 规范或其他规定文档所需具有的条件或能力, 即系统的内部特性。

需求描述SRS包括哪些(选择)(P123)

在分析阶段要编写 SRS, 包括引言、 信息描述、 功能描述、 行为描述、 质量保证、 接口描述和其他描述等内容。

第六章

OOA模型的组成(P139)

面向对象模型的组成——哪三种子模型(画图、描述)

哪三种分析类:边界类、实体类、控制类

方法

第七章

区分软件分析和设计(P165)

从表面上看, 设计模型同分析模型有许多相似之处, 但两者的目的有本质的区别。 分析模型强调的是软件 “应该做什么“,并不给出解决问题的方案, 也不涉及具体的技术和平台。例如,它不必关心在J2EE还是.NET平台上实现,是否应用EJB或一般的JavaBean, 系统是安装在WebSphere还是WebLogic环境下。 而设计模型要回答 “该怎么做" 的问题,而且要提供解决问题的全部方案, 包括软件如何实现、如何适应特定的实施环境等。当设计模型完成后,编程人员便可以进行编程了。

信息隐藏定义(P166)

早在 1972 年, D. L. Parnas 就提出了把系统分解为模块时应遵守的指导思想, 称之信息隐藏 (information hiding)。他认为, 模块内部的数据与过程, 应该对不需要了解这些数据与 过程的模块隐藏起来。 只有为了完成软件的总体功能而必须在模块间交换的信息, 才允许在 模块间进行传递。

控制复杂性的基本策略、常用方法(填空)(P167)

分解 (decomposition) 是处理复杂问题常用的方法。

模块化设计的定义(P167)

模块化设计 (modular design) 由来已久, 目的是按照规定的原则把大型软件划分为一个个较小的、相对独立但相互关联的模块。

分解和模块独立性, 是实现模块设计的重要指导思想。

图7.6 耦合性、顺序、内聚 举例说明(P169-171)

面向对象包括哪两任务、哪些具体任务(P174)

  1. 系统架构设计

    系统高层结构设计。

    确定设计元素。

    确定任务管理策略。

    实现分布式机制。

    设计数据存储方案。

    人机界面设计。

  2. 系统元素设计

    类/对象设计。

    子系统设计。

    包设计。 设计包, 将逻辑上相关的设计元素组织在一起。

分层次方法(P176-177)

图7.34 泛化和聚类的关系 区分聚集和组合的关系(P204)

  1. 聚集关系

    部分对象可以是任意整体对象的一部分。

  2. 组合关系

    在组合关系中, 整体和部分有相同的生存周期, 若整体不在了, 部分也会随之消失。

第八章

软件测试的目的:发现程序的错误(P233)

软件测试的特性(P234)

  1. 挑剔性
  2. 复杂性
  3. 不彻底性
  4. 经济性

黑盒测试依据、又叫——、使用技术——(P234-238)

黑盒测试就是根据被测试程序功能来进行测试, 所以也称为功能测试。

3种常用技术:

  1. 等价分类法
  2. 边界值分析法
  3. 错误猜测法

等价分类法的定义

所谓等价分类, 就是把输入数据的可能值划分为若干等价类, 使每类中的任何一个测试用例, 都能代表同一等价类中的其他测试用例。

边界值分析定义

实践表明, 程序员在处理边界情况时, 很容易因疏忽或考虑不周发生编码错误。 采用边界值分析法, 就是要这样来选择测试用例, 使得被测程序能在边界值及其附近运行, 从而更有效地暴露程序中隐藏的错误。

白盒测试依据、又叫——、使用技术——(P240)

白盒测试以程序的结构为依据, 所以又称为结构测试。

为了区分这两种白盒测试技术,以下把前者称为逻辑覆盖测试(logic coverage testing), 后者称为路径测试(path testing)。

逻辑覆盖测试五种覆盖(P242)

流程图——>程序图(P245)

黑盒白盒的测试用例设计(P248)

多模程序设计包括哪些层次、含义(P254)

用例图——>描述含义、多少参与者、用例之间的关系