软件工程期末复习

zstu 浙江理工大学 2023学年第1学期软件工程

带有参考标记 ※ 的章节建议优先阅读

题目的答案不保证完全正确

考前关键词速记

目录：需求获取、需求分析、软件设计、体系结构、人机交互、详细设计、实现、结构化开发、测试、维护、持续集成、度量、管理
生存周期：需求、设计、编码、测试、运行、退役
对应：需求规约、需求模型、体系结构、详细设计、源程序、可执行代码
软件危机：需求获取、需求分析不准确；缺乏项目管理
瀑布：可行性、需求、设计、编码、测试、运行、退役
适合小规模、需求稳定
优点：利于体系结构、利于管理、规范化
缺点：确定需求、时间长、缺陷隐藏
极限编程：完整团队、增量规划、客户参与、简单设计、结对编程、测试驱动、适时重构、持续集成、集体所有
适合小型软件、原型

UML静态：包、类、对象
UML行为：顺序、通信、状态、活动
用例与软件需求的关系：用例是功能性软件需求的主体部分
用例用椭圆、包含用虚线，连接不用箭头
类的组合实心，聚合空心，关联不用箭头
顺序图的对象用矩形

需求分析过程：优先级、用例、模型评审、原型
需求优先级因素：价值、成本、风险
优先级：架构、需求、风险
用例分析过程：精化领域概念模型、设置分析类、构思协作关系、分析类图
分析类：边界、控制、实体
用例：动作序列；交互图：消息；分析类：职责（响应消息）；设计元素：方法
快速原型：探索性、实验性、进化性

设计元素：子系统、构建、类
设计模型：体系结构、用户界面、用例、数据、子系统/构建/类
质量要素：正确、充分、优化、简单

内聚：偶然 逻辑 时间；过程 通信；顺序 功能
耦合：非直接 数据/控制 外部 公共 内容
高内聚低耦合优点：结构简单、可复用、可修改、可维护、并行开发
信息隐藏优点：并行开发、便于测试、便于维护

体系结构：组件、连接件、约束
视图：逻辑、开发、物理、运行、数据
设计模式：以复用为目的，良好定义的设计经验
分层：松耦合、可复用、可替换、标准化。性能损耗大
管道：可升级、更换过滤器构件。只适合批处理
黑板：知识源可升级、更换、复用。性能差，开发测试难

体系结构初创：基于需求、参考已有体系结构、选取体系结构
逻辑体系过程：搜索设计资产、设计技术支撑、确立设计元素、整合设计元素

纵向复用：公共性领域之间进行软部件复用
领域分析：根据领域的特征预测软部件可复用性
领域分析过程：发现可复用实体、抽象化、分类、建立体系结构

界面设计：屏幕内容的表示、屏幕之间跳转关系的表示
界面元素：静态、动态、用户输入、用户命令

数据流图：外部实体矩形，转换圆形，数据流实心箭头，数据源双横线

测试：需求测试、设计测试、代码【单元测试、集成测试】、确认测试、系统测试、回归测试
确认测试：软件是否满足需求说明书
黑盒测试：等价分类、边界值分析、对比测试

非结构化维护：读代码
结构化维护：读文档、读设计、修改设计、修改代码、回归测试
可维护性因素：开发方法：设计、编码、测试；开发环境

持续集成：代码集成、编译、测试、质量分析、发布
持续集成过程：提交代码、触发集成、脚本程序 管道 主工具 从工具、发送通知
持续集成价值：风险、成本、效率、更新、环境、可视化

初始级：没有软件过程管理
可重复级：基本的软件过程管理
已定义级：软件过程的标准化、文档化
已管理级：软件过程的定量管理
优化级：软件过程的维护和更新

第 1 章软件与软件工程

1.1 软件的概念

1.1.1 软件的组成

1.1.2 软件生存周期

1.2 软件工程

1.2.1 定义

1.2.2 发展 ※

软件危机 ※

需求获取和需求分析不准确、缺乏项目过程管理

1.2.3 目标和原则

原则：抽象、信息隐藏、模块化、局部化、一致性、完全性、可验证性

1.2.4 软件开发的方法

结构化方法、面向对象方法、形式化开发方法

1.3 过程模型

1.3.1 瀑布 ※

1.3.2 增量

1.3.3 原型建造

1.3.4 螺旋

1.3.5 基于构建

题目

1.4 敏捷开发 ※

1.4.1 原则

1.4.2 极限编程

极限编程是遵循敏捷开发原则的软件过程。

1.4.3 应用

题目

第 2 章 UML 与 RUP 统一过程

2.2 面向对象的软件开发方法

2.2.1 概念 ※

略

题目

为了在对象obj1与对象obj2之间消息传递，面向对象的程序设计机制提供如下4种手段：

（1）引用全局对象。obj1直接引用作为全局对象的obj2。

（2）通过参数传递。obj2作为obj1的某项操作中的实在参数。

（3）引用局部对象。在obj1的某项操作的函数体中创建或获取obj2

（4）通过类的成员变量。obj2作为obj1所属类的属性的取值。

前三种类型的连接具有暂时性，obj1与obj2之间的连接仅在obj1的某项操作的执行过程中建立，操作完成后连接即告终结。这种暂时性连接用UML 的依赖关系表示。对最后一种具有稳定性的连接关系，需要进一步分析。如果参与连接的两个类在现实世界中存在“皮之不存，毛将焉附”的部分整体关系，则用UML 的构成关系表示。否则，如果它们在现实世界中仍存在“多个整体对象可共享同一部件对象”的部分整体关系，则用UML 的普通聚合关系表示。如果以上两种假设均不成立，则原连接关系精化成UML中普通的关联关系。