软件工程导论期末复习
《软件工程导论》期末复习
本文是针对《软件工程导论》期末考的要点复习，归纳了一些常见的基本考点，对知识点做了一个大致的梳理。
内容来自《软件工程（第3版）》
目录
第一章 概论
1.1 什么是软件危机？（P5）
软件危机指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
随着计算机在各个领域的广泛应用，软件的需求量越来越大，软件的复杂度也越来越高，导致软件的开发远远满足不了社会发展的需要，超出预算的经费、超过预期交付时间的事情经常发生。由于 缺乏文档 以及 没有好的开发方法指导， 使得 大量已有的软件难以维护 。到20 世纪 60 年代中期出现了人们难以控制的局面，即“软件危机”。
1.2 什么是软件工程？（P5-6）
软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本为目的。
1.3 软件工程生存周期分哪几个阶段？分别简述各个阶段的任务。（P7）
（1）计算机系统工程
计算机系统工程的任务是确定待开发软件的总体要求和范围，以及该软件与其他计算机系统元素之间的关系，进行成本估算，作出进度安排，并进行可行性分析。
（2）需求分析
需求分析主要解决待开发软件要“做什么”的问题，确定软件的功能、性能、数据、界面等要求，生成软件需求规约。
（3）设计
软件设计主要解决待开发软件要“怎么做”的问题。系统设计的任务是设计软件系统的体系结构，详细设计的任务是设计各个组成成分的实现细节，包括局部数据结构和算法等。
（4）编码
编码阶段的任务是用某种程序设计语言，将设计的结果转换为可执行的程序代码。
（5）测试
测试阶段的任务是发现并纠正软件中的错误和缺陷。
（6）运行与维护
当发现了软件中潜在的错误或需要增加新的功能或使软件适应外界环境的变化等情况出现时，对软件进行修改。
1.4 简述 CMM 的 5 个等级。（P11-12）
初始级：无序的，没有管理
可重复级：基本管理，重复
已定义级：标准化、文档化
已管理级：定量、预测
优化级：改进
| 初始(initial)级 | 软件过程的特点是 无秩序的 ，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力 |
| 可重复(repeatable)级 | 建立了 基本的项目管理过程 来跟踪成本、进度和功能特性。制定了必要的过程纪律，能 重复 早先类似应用项目取得的成功 |
| 已定义(defined)级 | 已将管理和工程活动两方面的软件过程 文档化、标准化 ， 并综合成该机构的 标准软件过程 。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件 |
| 已管理(managed)级 | 收集对软件过程和产品质量的详细度量值，对软件过程和产品都 有定量的理解和控制 |
| 优化(optimizing)级 | 整个组织关注软件过程 改进的持续性 、预见及增强自身，防止缺陷及问题的发生。过程的量化反馈和先进的新思想、新技术促使过程不断改进 |
1.5 简述各类软件过程模型的特点，如何选择合适的模型？（P16-22）
1. 瀑布模型 ：上一阶段的活动完成并经过评审才能开始下一阶段的活动，接受上一阶段活动的结果作为本阶段活动的输入，依据上一阶段活动的结果实施本阶段应完成的活动，对本阶段的活动进行评审。
应用场景：项目需求明确，解决方案明确，短期或中小型项目
缺点：缺乏灵活性，维护代价大
2. 演化模型 ：从结构初始的原型出发，逐步将其演化成最终软件产品的过程。演化模型特别适用于对软件需求缺乏准确认识的情况。
典型的演化模型有：增量模型、原型模型、螺旋模型
应用场景：需求比较复杂，不能一次搞清楚
3. 增量模型 ：将软件的开发过程分为若干个日程时间交错的线性序列，融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征，特别适用于需求经常发生变化的软件开发。
应用场景：需求经常发生变化，市场急需但时间不足以开发完善的产品时，有计划地管理技术风险。需要快速构造核心产品。
4. 原型模型 ：开发人员和用户在“原型”上达成一致，缩短了开发周期，加快了工程进度，降低成本。
应用场景：需求难以被清楚定义，在没有经验的时候
原型类型：探索型、实验型、演化型
原型使用策略：废弃策略，追加策略
5. 螺旋模型 ：将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来，不仅体现了这两种模型的优点，而且增加了风险分析。
风险驱动的软件过程模型
在每一次迭代过程中包含项目风险评价
6. 喷泉模型 ：各个阶段没有明显的界限，开发人员可以同步进行开发，可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
基于面向对象思想
有面向对象方法的迭代和无间隙特性
具有较好的可移植性
7. 基于构件的开发模型 ：利用预先包装的构件来构造应用系统。
减少开发、降低风险、降低成本、需求妥协、快速交付
构件可以是组织内部开发的，也可以是商品化的、现存的软件构件
在面向对象技术获得支持的情况下应用得更好。
【例子】某公司开发企业管理ERP（企业资源计划）系统，包括销售、库存、生产、财务、物流、人力资源等部分，在系统实施过程中不同的企业具有一定的需求差异。
选用模型：基于构件的开发模型
选用分析：企业ERP系统具有构件化的结构，在不同企业实施时应该尽量重用已有的组件。因此适合采用基于构件的开发模型开发该系统，在直接应用或修改使用的基础上，最终进行组件开发和系统集成。
8. 形式化方法模型 ：易于发现需求的歧义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。
建立在严格数学基础上. 凡是采用严格的数学语言，具有精确的数学语义的方法，都称为形式化方法。
1.6 简述 CASE 工具和环境的重要性。
CASE（计算机辅助软件工程） 已被证明可以加快开发速度，提高 生产率并保证应用软件的可靠品质。计算机专业人员利用计算机使他们的企业提高了效率，企业的各个部门通过使用计算机提高了生产率和效率，增强了企业的竞争力并使之带来了更多的利润。
第二章 系统工程
2.1 简述系统工程的任务。（P28-29）
- 识别用户的要求
识别用户对基于计算机的系统的总体要求，标识系统的功能和性能范围，确定系统的功能、性能、约束和接口。
- 系统建模和模拟
一个基于计算机的系统通常可考虑建立以下模型：硬件系统模型、软件系统模型、人机接口模型、数据模型。
- 成本估算及进度安排
开发一个基于计算机的系统需要一定的资金投入和时间约束（交付日期），需进行成本估算，并作出进度安排。
- 可行性分析
主要从经济、技术、法律等方面分析所给出的解决方案是否可行。
- 生成系统规格说明
作为以后开发基于计算机的系统的依据。
2.2 什么是可行性分析？简述可行性分析的任务。（P29-32）
开发一个基于计算机的系统通常都受到资源（如人力、财力、设备等）和时间上的限制，可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。
可行性分析的任务包括以下几个方面：
- 经济可行性
a) 成本
b) 效益
c) 货币的时间价值
d) 投资的回收期
e) 纯收入
- 技术可行性
a) 风险分析
b) 资源分析
c) 技术分析
法律可行性
方法的选择和折衷
可行性分析必须有一个明确的结论，下面给出几种可以选择的结论：
可立即开始。
需要推迟到某些条件(如资金、人力、设备等)落实后才能开始
需要对开发目标进行某些修改后才能开始。
因为某种原因(如技术不成熟、经济上不合算等)不能进行
第三章 需求工程
3.1 需求工程具体包括哪些步骤？每个步骤的具体任务是什么？（P33-35）
- 需求获取：系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析。
- 需求分析与协商：分析每个需求与其他需求的关系以检查需求的一致性、重叠和遗漏的情况，并根据用户的需求对需求进行排序。
- 系统建模：通过合适的工具和符号系统地描述需求。
- 需求规约：给出对目标软件的各种需求。
- 需求验证：对功能的正确性、完整性和清晰性以及其他需求给予评价。
- 需求管理：对需求工程所有相关活动的规约和控制。
3.2 列出在制定需求获取策略时的主要考虑因素。（P35-36）
- 功能需求。考虑系统要做什么，在何时做，在何时及如何修改或升级。
- 性能需求。考虑软件开发的技术性指标。
- 用户或人的因素。考虑用户的类型。
- 其它需求。
3.3 什么是非功能性需求？举例说明。（P35-36）
非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。
例如在银行管理系统中，由于银行数据量的庞大以及对银行账户的管理需求，用户对系统的性能、可靠性、可维护性要求很高。安全性是对银行用户个人信息保密的基本要求；在使用系统时，由于用户庞大，要求能快速安全的执行要求，这就对系统的性能有高需求；银行的用户的变动比较大，需要高要求的系统维护。
3.4 需求获取的方法和策略有哪一些？举例说明。（P37-39）
- 访谈与调查
- 建立顺畅的通信途径
- 亲身实践
- 会议
- 头脑风暴
- 概念建模
- 原型、仿真
- 自省
- 用户行为数据在线采集
第四章 设计工程
4.1 简述软件设计阶段的基本任务。（P46-47）
- 数据/类设计：将分析类模型变换成类的实现和软件实现所需要的数据结构。
- 体系结构设计：定义了软件的整体结构，由软件部件、外部可见的属性和他们之间的关系组成。
- 接口设计：描述了软件内部、软件和协作系统之间以及软件同人之间的通信方式。
- 部件级设计：将软件体系结构的结构性元素变换为对软件部件的过程性描述。
4.2 简述模块、模块化及模块化设计的概念。（P49-50）
模块是数据说明、可执行语句等程序对象的集合，是单独命名的，并且可以通过名字来访问的。
模块化是指把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件。
模块化设计就是程序的编写不是开始就逐条录入计算机语句和指令，而是首先用主程序、 、子过程等框架把
的主要结构和流程描述出来，并定义和调试好各个框架之间的输入、输出链接关系。
4.3 描述信息隐蔽概念， 并讨论信息隐蔽与模块独立两概念之间的关系。
- 信息隐蔽指在设计和确定模块时，使得一个模块内包含信息（过程或数据），对于不需要这些信息的其他模块来说，是不能访问的。在面向对象方法中，信息隐蔽是通过对象的封装性来实现的。
- 信息隐蔽的概念与模块的独立性直接相关。
4.4 什么是模块的独立性？ 模块功能独立有何优点？ 如何度量独立性？
1、模块独立性：
A、模块独立性指每个模块只完成系统要求的独立的子功能，并且与其他模块的联系最少且接口简单。
B、模块独立性是指模块内部各部分及模块间的关系的一种衡量标准。
2、模块的独立程度可以由两个定性标准度量：内聚和耦合（高内聚、低耦合）。
3、优点：
A、具有独立的模块的软件比较容易开发出来。这是由于能够分割功能而且接口可以简化，当许多人分工合作开发同一个软件时，这个优点尤其重要。
B、独立的模块比较容易测试和维护。这是因为相对说来，修改设计和程序需要的工作量比较小，错误传播范围小，需要扩充功能时能够"插入"模块。
总之，模块独立是优秀设计的关键，而设计又是决定软件质量的关键环节。
4.5 简述每种类型的模块内聚度和每种类型的模块耦合度。（P51-53）
内聚： 内聚是 一个模块内部 各个元素彼此结合的紧密程度的度量。一个内聚程度高的模块（在理想情况下）应当只做一件事。
- 巧合内聚：一个模块之内各成分之间没有任何关系，只是把分散的功能整合到了一起。
将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块称巧合内聚模块。
- 逻辑内聚：几个逻辑上相关的功能放在同一模块中。
逻辑内聚是指完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制性参数来确定该模块应执行哪一种功能。
时间内聚：一个模块中的所有任务必须在同一时间段内执行。
过程内聚：一个模块完成多个任务，这些任务必须指定的过程执行。
通信内聚：一个模块内所有处理元素都集中在某个数据结构的一块区域中。
顺序内聚：一个模块完成多个功能，这些功能又必须顺序执行
功能内聚：一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割。
耦合： 耦合是 模块之间 相对独立性（互相连接的紧密程度）的度量。耦合取决于各个模块之间接口的复杂程度、调用模块的方式以及通过接口的信息类型。
- 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的
- 数据耦合：一个模块访问另一个模块时，彼此之间是通过简单数据参数(不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的。
- 标记耦合：一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，而不是简单变量。其实传递的是这个数据结构的地址。
- 控制耦合：一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能。
- 外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息。
- 公共耦合：一组模块都访问同一个公共数据环境。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
- 内容耦合：一个模块直接修改或操作另一个模块的数据，或者直接转入另一个模块。此时，被修改的模块完全依赖于修改它的模块。如果发生下列情形，两个模块之间就发生了内容耦合：
- 一个模块直接访问另一个模块的内部数据
- 一个模块不通过正常入口转到另一模块内部
- 两个模块有一部分程序代码重叠(只可能出现在汇编语言中)
- 一个模块有多个入口。
第五章 结构化分析与设计
5.1 分层数据流图的画法。（P72-76）
主要思想：数据流图描述输入数据流到输出数据流的变换（即加工），用于对系统的功能建模。
使用数据流图进行需求分析的过程：
- 画出系统的输入和输出。
A. 确定源和宿
B. 确定加工
C. 确定数据流
D. 顶层图通常没有文件
- 画出系统内部。
A. 确定加工
B. 确定数据流
C. 确定文件
D. 确定源和宿
画出加工内部。
重复第 3 步，直至每个尚未分解的加工都足够简单（即不必再分解）。
5.2 分别采用数据流方法中的哪些技术来完成用户需求的精确化、一致化和完全化任务？（P77-82）
- 父图和子图平衡
父图和子图平衡是指任何一张 DFD 子图边界上的输入/输出数据流必须与其父图中对应加工的输入/输出数据流保持一致。
- 数据守恒
数据守恒包括以下两种情况：
一个加工所有输出数据流中的数据，必须能从该加工的输入数据流中直接获得，或者能通过该加工的处理而产生
加工未使用其输入数据流中的某些数据项。这表明这些未用到的数据项是多余的，可以从输入数据流中删去。（不一定是错误,但可能隐含潜在的错误）
局部文件
考虑分层数据流中一个文件应画在哪些 DFD 中，而不该画在哪些 DFD 中。
- 一个加工的输出数据流不能与该加工的输入数据流同名。
同一个加工的输出数据流和输入数据流即使组成成份相同，仍应对它们取不同的名字， 以表示它们是不同数据流，例如：例如，“报名单”和“合格报名单”。
允许一个加工有二个相同的数据流分别流向二个不同的加工。
每个加工至少有一个输入数据流和一个输出数据流。
在整套分层数据流中，每个文件应至少有一个加工读该文件，有另一个加工写该文件。
分层数据流图中的每个数据流和文件都必须命名（除了流入或流出文件的数据流），并且与数据字典一致。
分层 DFD 中的每个基本加工（即不再分解子图的加工）都应有一个加工规约。
5.3 在数据流图中，可否将两个加工用一个数据流相连？可否将两个源用一个数据流相连？为什么？
两个加工可以直接用数据流相连，两个源不能直接用数据流相连。因为数据流由一组固定成分的数据组成。在 DFD 中，数据流的流向可以有以下几种： 从一个加工流向另一个加工，从加工流向文件（写文件），从文件流向加工（读文件），从源流向加工，从加工流向宿。
5.4 采用结构化分析方法绘制数据流图及数据字典（根据要求绘图并解决问题）。
数据流图与数据字典是密不可分的，两者结合起来构成软件的逻辑模型（分析模型）。
数据字典由字典条目组成，每个条目描述DFD中的一个元素。
数据字典条目包括：数据流、文件、加工、源或宿、数据项（组成数据流和文件的数据）、别名。
数据字典的描述符号：
【例1】
【例2】
5.5 描述基本加工的小说明（根据要求解决问题）。
结构化语言、判定表、判定树。
- 结构化语言
（1）加工规约分为若干个段落，每个段落可分为内外两层
外层有严格的语法来描述它的控制结构，内层可以用自然语言来描述
（2）三种语句：顺序语句，选择语句，循环语句
// 选择语句
IF 条件 THEN
分支内容
ELSE IF 条件 THEN
分支内容
ELSE
分支内容
ENDIF
// 循环语句
WHILE 下雨
DO
{
在家
IF 不下雨 THEN
出门
ENDIF
}
ENDDO- 判定表
判定表的组成元素：
- 条件桩（Condition Stub）：列出各种条件的对象，每行写一个条件对象
- 条件条目（Condition entry）：列出个条件对象的取值，条件条目的每一列表示了一个可能的条件组合
- 动作桩（Action stub）：列出所有可能采取的二动作，如发出发货单等，每行写一个动作
- 动作条目（Action entry）：列出各种条件组合下应采取的动作
【示例】
- 判定树
本质上与判定表是相同的，只是表示形式不同
【示例】
5.6 结构图的基本成分包括什么？（P92）
模块 ：指具有一定功能的可以用模块名调用的一组程序语句，如函数、子程序等。
调用 ：用从一个模块指向另一个模块的箭头来表示，其含义是前者调用了后者。为了方便，有时常用直线替代箭头，此时，表示位于上方的模块调用位于下方的模块。
数据 ：模块调用时需传递的参数可通过在调用箭头旁附加一个小箭头和数据名来表示。
5.7 结构图的几个概念。（P93-94）
深度 ：模块结构图中控制的层数，例如图中所示的结构图的深度是 5。
宽度 ：模块结构图中同一层次上模块总数的最大值，例如图中所示的结构图的宽度为 7。
扇出 ：该模块直接调用的模块数目。例如图中模块 M 的扇出是 4，模块 A 的是 2。
扇入 ：能直接调用该模块的模块数目。例如图中模块 G 的扇入是 1，模块 R 的扇入是 4。
第七章 面向对象方法基础
7.1 简述什么是 UML？（P130）
UML (Unified Modeling Language) 统一建模语言，是一种可视化语言
UML 是一种统一的、标准化的建模语言，UML 是一种应用面很广泛的建模语言。
7.2 ML 有哪些视图？有哪些图？
UML2.0 包含的视图和图：
- 静态视图（类图）
- 设计视图（构件图）
- 用况视图（用况图）
- 状态机视图（状态机图）
- 活动视图（活动图）
- 交互视图（顺序图）
- 部署视图（部署图）
- 模型管理视图（包图，包图是类图的一种变种）
- 剖面
用况视图 –> 用况图
静态视图 –> 类图
动态视图 –> 状态图、活动图、顺序图
7.3 UML 包括哪四种事物？（P131）
- 结构事物：类、接口、用例、主动类、构件和结点等。
- 动作事物：状态等。
- 组织事物：包。
- 注释事物：给建模者提供信息，提供关于任意信息的文本说明，但没有语义作用。
第八章 面向对象建模
8.1 用况图
用况图的主要元素有：用况、执行者、用况间的关系
用况图中的关系： 关联、泛化、包含、扩展
8.2 类图。
什么是类图，类图的组成元素（类、类的属性和操作、类之间的关系、重数），根据要求绘制类图。
类图是一种静态模型，它是其他图的基础。
类图的组成元素：类、类的属性和操作、类之间的关系、重数
类之间的关系有关联、依赖、泛化、实现等。
重数：在一个类的关联端点附加的重数表示这个类的多少个实例对象可以与另一个类（该关联的另一端）的一个实例相关。
8.3 状态图。
什么是状态图，状态图的组成元素（状态、状态之间的迁移、分支、状态内的迁移、复合状态），根据要求绘制状态图。
状态图的组成元素：状态、状态之间的迁移、分支、状态内的迁移、复合状态
| 转换类型 | 描述 | 语法 |
| 外部转换 | 改变对象状态的迁移 | 事件(参数)[监护条件]/动作 |
| 内部转换 | 指状态不变，事件引发的动作 内部迁移自始至终都不离开源状态，所以不会产生入口动作和出口动作 | 事件(参数)[监护条件]/动作 |
| 进入转换 | 当进入某一状态时，执行相应活动 | entry/活动 |
| 退出转换 | 当离开某一状态时，执行相应活动 | exit/活动 |
状态分为简单状态和复合状态。
包含子状态的状态称为复合状态
复合状态包括顺序状态、并发状态和历史状态
8.4 活动图。
活动图的组成元素：活动、泳道、分支、分岔和汇合、对象流
开始与结束：活动图只能有一个起点，但可以有多个终点。
活动：活动用圆角矩形表示，活动间的控制流用实体箭头表示。
分支判断：菱形代表分支判断
分叉与汇合：分叉与汇合必须组合使用，表示并发动作。分叉表示一个活动完成后产生后续的多个并行的活动，汇合表示多个活动全部完成后再进行下一个活动。
泳道：泳道区分了负责活动的对象，明确表示哪些活动是由哪些对象进行的。
【示例】
8.5 顺序图
顺序图的组成元素：对象和生命线、激活、消息、组合片段
对象：系统的参与者或任何有效的系统对象
生命线：表示顺序图中的对象在一段时间内的存在，时间从上到下流过。生命线实际上显示了消息的顺序。
激活（控制焦点）：在生命线中，当一个对象接收到一个消息时，该对象开始活动，称为激活。是声明线上的条形框。
消息：对象和活动者或其他对象之间的消息。
组合片段：一个组合片段中有一个关键字和一或多个子片段。
同步信息需要反馈，异步信息不需要反馈
第十三章 软件测试
13.1 什么是白盒测试？（P249）
白盒测试 主要是对程序内部结构和执行路径的测试，也称透明盒测试。测试人员将测试软件看作一个打开的盒子，搞清软件内部逻辑结构和执行路径后，利用其结构及有关信息设计测试用例，对程序所有逻辑路径进行测试，以检测不同点检查程序的实际状态与预期状态一致性。
13.2 什么是黑盒测试？（P249）
黑盒测试 也称功能测试或黑箱测试，其盒是指被测试的软件，“黑盒”则指测试人员只知道被测软件的界面和接口外部情况，不必考虑程序内部逻辑结构和特性，只根据需求分析指标要求，检查其功能是否符合。例如由界面查看功能。
第十五章 软件维护与再工程
15.1 软件维护的概念及分类
软件维护 是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程。
根据起因不同，软件维护可以分为以下四种：
1. 纠错性维护 ：为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而进行的维护。
2. 适应性维护 ：为了使软件适应内部或外部环境变化，而去修改软件的过程（硬件、操作系统平台、其他支持软件）。
3. 改善性维护 ：满足使用过程中用户提出增加新功能或修改已有功能的建议维护。
4. 预防性维护 ：为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的活动。