软件工程知识点整理
软件工程 (Software Engineering)
玛格丽特
软件工程是一门综合性交叉学科
软件的定义见计算机科学常识整理的软件一节
软件文档
软件文档在软件工程中的作用如下
软件危机
软件开发管理困难复杂
人月 (Man-Month)
软件开发需要软件工具
人月是危险和带有欺骗性的神话
向进度落后的项目追加人手
概念完整性 (Conceptual Integrity)
概念完整性指对于一个领域
体系结构
第二系统效应
计算机辅助软件工程 (CASE; Computer Aided Software Engineering)
使用计算机及相关软件工具辅助软件开发
软件开发环境的集成机制有如下几种
- 数据集成
统一的数据模式和数据接口规范: ; - 界面集成
统一的界面风格: ; - 控制集成
支持环境中各个工具或开发活动间的通信: 切换、 调度和协同工作、 ; - 过程集成
将多种开发方法: 过程模型及其相关工具集成、 ; - 平台集成
在不同的硬件和系统软件之上构件用户界面一致的平台: 。
软件生存周期 (SLC; Software Life Cycle)
即软件开发的路线图
软件规模
随生存周期的推移
能力成熟度模型 (CMM; Capability Maturity Model)
CMM
- 初始级
过程往往是混乱的: 成功源于英雄主义, ; - 可重复级
建立基本项目管理以跟踪成本: 进度和功能、 制定必要的过程纪律, ; - 需求管理
; - 软件项目计划
跟踪和监督、 - 软件分包合同管理
; - 软件质量保证和配置管理
。
- 需求管理
- 已定义级
将管理和工程活动文档化: 标准化、 ; - 组织级过程焦点
定义、 ; - 集成软件管理
; - 软件产品工程
; - 组件协调
; - 同行评审
; - 培训大纲
。
- 组织级过程焦点
- 已管理级
对软件过程有定量的理解和控制: 过程可预测, ; - 定量过程管理
; - 软件质量管理
。
- 定量过程管理
- 优化级
过程的量化反馈和先进的新思想: 新技术使过程持续改进、 。 - 缺陷预防
; - 技术更新管理
; - 过程更改管理
。
- 缺陷预防
软件过程模型 (Software Process Model)
软件过程模型是将软件生存周期进行合理的整合后形成的开发方式
瀑布模型 (Waterfall Model)
瀑布模型将软件开发各阶段线性顺序联接
若错误由前一阶段引起
瀑布模型不灵活
演化模型 (Evolutionary Model)
原型
适用于对软件需求缺乏准确认识的情况
- 增量模型
融合了瀑布模型的基本成分: 强调每一个增量都发布一个可运行的产品; 能有计划地管理技术风险; ; - 原型模型
快速构建原型: 交付客户试用, 收集反馈意见并改进原型, ; - 螺旋模型
在瀑布模型和增量模型的基础上增加了风险分析活动: 指引软件项目开发沿着螺线自内向外旋转, 每旋转一圈, 表示开发出一个更为完善的新软件版本, 。
喷泉模型 (Fountain Model)
喷泉模型是支持面向对象开发的过程模型
系统工程 (System Engineering)
考虑完整的软硬件解决方案
- 识别用户的要求
简化的: 压缩的需求分析、 ; - 可行性分析
用最小的代价确定该软件项目是否能够开发: 是否值得去开发, ; - 经济可行性
进行开发成本的估算以及了解取得效益的评估: ; - 技术可行性
通常包括风险分析: 资源分析和技术分析、 ; - 法律
分析开发的项目是否存在任何侵犯: 妨碍等责任问题、 要开发项目目的运行方式在用户组织内是否可行, 现有管理制度, 人员素质、 操作方式是否可行、 。
- 经济可行性
- 系统建模和模拟
建立硬软件系统模型: 人机接口模型和数据模型等、 建模是软件开发中实现映射的基本手段, 系统物理模型通常可使用系统流程图描述, ; - 成本估算和进度安排
; - 生成系统规格说明
。
需求工程 (RE; Requirement Engineering)
开发人员准确地理解用户的需求
- 需求获取
与用户交流: 对现有系统进行观察及对任务进行分析, 捕获和修订用户的需求, ; - 需求分析
分析需求间关系以检验需求的一致性: 重叠和遗漏的情况、 ; - 系统建模
建立概念模型以对需求进行抽象描述: 尽可能多地捕获现实世界的语义, ; - 需求规约
需求分析的输出: 即软件产品的概念模型, 并对此制定合适的验收标准, ; - 需求验证
检验系统是否能反应用户意愿: ; - 需求管理
支持系统的需求演进: 如需求变化和可跟踪问题, 。
需求的发现方式如下
- 自悟
作为用户: 提出问题, 适用于当开发者无法与用户进行直接交流时, ; - 交流
询问用户想要的功能: 需要控制用户提出合理需求, ; - 观察
观察用户执行现行的任务和过程或观察如何操作与期望系统有关的现有系统: 了解运行环境, 但用户可能抵触这一观察, 且会让用户误以为开发者已经熟悉了业务, ; - 小组会
举行客户和开发人员的联席会议: 与客户代表共同开发需求, ; - 提炼
可复用的技术文档: 提取出未来可能会用到的信息, 适用于已有部分需求文档的烂尾项目, 。
除功能需求外
- 性能需求
并发访问数等: ; - 质量属性
对非法操作的容错等: ; - 对外接口
支持第三方插件等: ; - 设计约束
运行平台等: 与其他非功能需求不同, 设计约束是必须予以满足的, 且对项目规划, 所需的附加成本和工作产生直接影响、 。
非功能需求必须依附于功能需求而存在
设计工程 (Design Engineering)
定义软件的实现细节以满足用户需求
软件的设计原则如下
模块化设计
模块的功能独立性可以由两个指标衡量
内聚
- 偶然内聚
又称巧合内聚: 仅相同程序代码独立出来而建立的模块, ; - 逻辑内聚
完成一组逻辑相关任务: ; - 时间内聚
模块中的多个任务必须在一段时间内先后执行: 而无明确的过程约束, ; - 过程内聚
模块中的多个任务必须按指定过程执行: ; - 通信内聚
模块中所有处理元素都集中在某个数据结构的一块区域中: ; - 顺序内聚
完成必须顺序执行的多个功能: ; - 功能内聚
模块中各部分都是为完成一项具体功能而协同工作: 不可分割, 。
耦合
- 内容耦合
可以直接访问另一模块的内部数据或内部功能: ; - 公共耦合
可与其他模块共同访问某些公共数据元素: ; - 外部耦合
与其他模块遵循同样的外部约束: 数据格式等)、 ; - 控制耦合
与其他模块的交互参数包含控制信息: 即能影响另一模块的执行逻辑, ; - 标记耦合
模块间传递特定数据结构: ; - 数据耦合
模块间仅传递简单数据: ; - 非直接耦合
模块可相对独立工作: 。
良好的设计策略要求降低耦合度
概要设计 (Overall Design)
又称总体设计
概要设计是详细设计的基础
概要设计阶段的基本任务如下
详细设计 (Detailed Design)
设计每个模块实现算法
详细设计阶段的基本任务如下
详细设计的描述方法见结构化程序设计
人机交互界面 (HCI; Human-Computer Interface)
在
人机交互界面应该具备如下特性
- 可使用性
最关键的特性: ; - 灵活性
用户可根据需要定制和修改界面: ; - 可靠性
无故障使用: ; - 可扩展性
。
设计人机交互界面需要考虑如下因素
人机交互界面设计的三条
容错 (Fault Tolerance)
系统在部分组件发生故障时仍能正常运作的能力
- 结构冗余
包括静态冗余: 动态冗余和混合冗余、 ; - 信息冗余
为检测或纠正信息在运算或传输中的错误所外加的信息: ; - 时间冗余
重复执行指令或程序来消除瞬时错误的影响: ; - 冗余附加技术
实现上述冗余技术所需的资源和技术: 。
编码 (Coding)
良好的编码原则如下
编码风格
编码风格可根据花括号位置分为如下两类
- Allmans
花括号独占一行: ; - Kernighan
左花括号居于行尾: 。
软件测试 (Software Testing)
软件测试是确保程序按期望运行的工序
早期的软件测试与软件调试概念混淆
测试用例
软件测试的策略如下
- 单元测试
又称模块测试: 着重对软件构件或模块进行测试, 可并行进行, 其中使用的桩模块, 而不是软件产品的组成的部分, ; - 集成测试
又称组装测试: 将程序模块组装为软件系统后进行测试, ; - 确认测试
又称验收测试: 检查软件功能和性能是否与需求规格说明书的指标相符, 确认整个软件是用户所需的, 一般运用黑盒测试方法, 由专门测试人员和用户参与, ; - Alpha
粗糙: 错误很多、 通常只在公司内部测试, 用户操作经由开发者指导, ; - Beta
软件接近完成: 可能向公众发布以帮助发现问题, 开发者通常不在现场, 。
- Alpha
- 系统测试
软件通常受制于计算机系统的其他元素: 需要测试是否能与计算机系统协调工作, ; - 压力测试
又称强度测试: 需要在非正常数量, 频率或容量的方式下执行、 ; - 性能测试
测试运行性能: 对实时系统和嵌入式系统尤为重要, ; - 安全保密性测试
。
V
黑盒测试 (Black-Box Testing)
黑盒测试不考虑内部结构或运作
- 等价类划分
等价类: 同子集的输入能引发相同的情况, 从等价类中选择的用例具有, 代表性「 」 等价类分为有效等价类, 分别验证程序是否实现了规格说明中规定的功能, 以及是否实现了对不合理的非法输入处理的功能, ; - 边界值分析
通常是等价类划分的一种补充: 专门挑选位于输入或输出边界值附近的数据作为测试用例, ; - 比较测试
又称背对背测试: 通常由两支开发队伍, 根据需求规格说明开发两个软件版本, 然后用相同的用例分别测试, 适用于高可靠性要求的软件, 如航空航天控制软件, 核电厂控制软件等、 ; - 猜测
根据直觉和经验推测存在的错误: ; - 因果图
分析输出条件对输入条件的依赖关系: 是选取高效测试用例的方法, 。
白盒测试 (White-Box Testing)
白盒测试又称玻璃盒测试
- 逻辑覆盖测试
; - 语句覆盖
每个可执行语句都至少执行一次: ; - 条件覆盖
每个判断的每个条件的所有可能结果都至少出现一次: ; - 判断覆盖
又称分支覆盖: 每个进入点和每个结束点都至少执行一次, 每个判断的分支都至少经过一次, ; - 条件/判断覆盖
每个进入点和每个结束点都至少执行一次: 每个判断的每个条件的所有可能结果都至少出现一次, 每个判断的分支都至少经过一次, ; - 修正的条件/判断覆盖
每个进入点和每个结束点都至少执行一次: 每个判断的每个条件的所有可能结果都至少出现一次, 每个判断的分支都至少经过一次, 而每一个条件都可以独立地影响判断的结果, ; - 路径覆盖
每条路径都至少经过一次: 。
- 语句覆盖
- 基本路径测试
; - 数据流测试
; - 变异测试
将源程序注入错误: 即变异为变体, 然后于变体上执行测试用例, 验证测试用例是否可以发现注入的错误, 。
版本控制 (Version Control)
版本控制追踪工程从诞生一直到定案的过程
大型工程代码通常存储于一个中心服务器上
软件缺陷预测 (SDP; Software Defect Prediction)
软件缺陷预测是一种能够有效地挖掘软件中尚未被发现的潜在缺陷及其分布情况的技术
根据是否与软件生命周期有关
- 项目内缺陷预测
利用项目中足够多的已标记数据来训练一个稳定的分类模型: 然后基于该模型来预测同一项目中新的模块或实例中的缺陷倾向性, ; - 跨项目缺陷预测
利用其他项目: ; - 异构缺陷预测
源项目与目标项目特征异构: 。
通常缺陷预测模型的构建方法有如下两种
代码度量元
- 代码行数
最早的代码度量元: 过于简单而难以合理地度量软件系统的复杂性, ; - Halstead
通过统计程序内操作符和操作数的数量来度量代码的阅读难度: 其假设是代码的阅读难度越高, 则含有缺陷的可能性也越高, ; - McCabe
其假设是程序的控制流复杂度越高: 则含有缺陷的可能性也越高, ; - C&K
综合考虑面向对象程序中的继承: 耦合性和内聚性等特征、 是适用于面向对象程序的度量元, 。
在软件缺陷预测问题中
即时
在即时软件缺陷预测领域
软件维护 (Software Maintenance)
软件维护是软件生存周期中持续时长最长
- 修正性维护
又称纠错性维护: 诊断和改正用户使用软件时所发现的软件错误的过程, ; - 适应性维护
与变化的环境适配而进行的修改: ; - 完善性维护
满足用户提出的新功能或改进意见: ; - 预防性维护
为未来的改进奠定更好的基础: 。
非结构化维护需要付出很大代价
可维护性
软件维护有如下两类技术
- 面向维护技术
在开发阶段用于减少错误: 提高软件可维护性、 ; - 维护支援技术
在维护阶段用于提高维护效率和质量: 。
软件维护一般经过如下步骤
软件维护的副作用即因修改软件而造成的错误
结构化分析与设计 (Structured Analysis and Design)
结构化分析
结构化程序设计 (SP; Structured Programming)
结构化程序设计指程序的代码块仅通过顺序
结构化程序设计可避免写出混杂代码的编程典范
部件执行过程的描述方式有如下几种
- 图形表示法
; - 程序流程图
以框图表示步骤: 使用箭头连接, 直观清晰, 独立于任何一种程序设计语言, ; - N-S(Nassi-Shneiderman)
又称盒图: 符合结构化程序设计原则, 可以表示程序的结构, ; - PAD(Problem Analysis Diagram)
由日本日立公司提出: 是用结构化程序设计思想表现程序逻辑结构的图形工具, PAD, 是软件自动化生成的有力工具, 还允许递归使用, 。
- 程序流程图
- 判定表
清晰地表达复杂条件的真值组合与动作间的对应关系: ; - 设计性语言
用于描述功能部件的算法设计和处理细节: 是一种伪代码, 。
结构化分析 (SA; Structured Analysis)
面向数据流的分析方法
数据流图 (DFD; Data Flow Diagram)
用于对系统的功能建模
DFD
DFD
- 数据流
由一组固定成分的数据组成: 代表数据的流动方向, 用箭头表示, ; - 加工
输入数据流到输出数据流的变换: 用圆圈表示, ; - 文件
保存某些数据供以后使用: 在各加工间建立合理关系, 用双杠表示, ; - 源
软件系统外的人员或组织: 用矩形表示, 。
为表达稍为复杂的实际问题
分层
分层
加工规约
数据字典 (DD; Data Dictionary)
手动建立或计算机辅助建立的
数据字典是用来定义数据流图中的各个成分的具体含义的
数据字典与数据流图密不可分
结构化设计 (SD; Structured Design)
面向数据流的设计方法
模块结构图 (MSD; Module Structure Diagram)
描述软件系统的体系结构
用直线表示调用关系时
与
- 深度
; - 宽度
; - 扇出
模块直接调用的模块数目: ; - 扇入
能直接调用该模块的数目: 反映了该模块的复用, 。
良好的设计策略要求避免高扇出
DFD
- 变换分析
确定输入: 输出从而确定变换中心、 所有的数据流图都可看作变换型数据流图, 划分因人而异, ; - 事务分析
确定事务中心: 根据事务类型执行一个事务处理的功能, 。
MSD
IPO(Input-Process-Output)
结构化概要设计的工具
改进的
IDEF(ICAM Definition)
ICAM(Integrated Computer-Aided Manufacturing)
IDEF
- 输入
位于左侧: 实行或完成特定活动所需的资源, ; - 输出
位于右侧: 经由活动处理或修正后的产出, ; - 控制
位于上方: 活动的条件限制, ; - 机制
位于下方: 活动所需的工具, 包括人员, 设施、 装备等、 。
面向对象分析与设计 (Object-Oriented Analysis and Design)
面向对象分析
面向对象的四个基本特征是抽象
面向对象编程 (OOP; Object-Oriented Programming)
面向对象编程使用对象作为基本单元
Simula
统一建模语言 (UML; Unified Modeling Language)
UML
UML
类图 (Class Diagram)
类图展示类的静态结构
关系 | 说明 | 理解 |
---|---|---|
泛化 |
继承的反方向 | B extends A |
实现 |
实现接口的功能 | A implements B |
依赖 |
被依赖的对象作为工具 | A uses a B |
关联 |
A has a B | |
聚合 |
A owns a B | |
组成 |
A is a part of B |
类成员的可见性有如下类型
符号 | 类型 | 说明 |
---|---|---|
公共的 |
类可见时此属性就可见 | |
受保护的 |
子类可见 | |
私有的 |
只有类自身可见 | |
包内访问的 |
同一包中的类可见 |
内部结构图 (Composite Structure Diagram)
内部结构图展示类的分解
用况图 (Use Case Diagram)
用况图展示各类外部执行者与系统内用况的连接
- 用况
系统所提供的一个功能: ; - 执行者
使用这些用况的人或外部系统: 。
构件图 (Component Diagram)
构件图展示系统中的构件
构件
- 请求接口
该构件请求其他供应者提供服务: 用半圆表示, ; - 供应接口
为其他请求者提供服务: 用小圆圈表示, 。
状态机图 (State Machine Diagram)
状态机图展示该类的对象的所有可能状态
状态的改变称为迁移
活动图 (Activity Diagram)
活动图展示完成一个操作所需的活动
- 动作
活动图的基本组成: 用圆角矩形表示, ; - 决策
即条件判定: 用菱形表示, ; - 并行
并发性活动的分离与汇合: 用粗实线表示, 。
活动图可分为若干矩形区
顺序图 (Sequence Diagram)
顺序图展示对象间的交互行为
部署图 (Deployment Diagram)
部署图展示处理器
包图 (Package Diagram)
包图展示包和包间的关系
敏捷软件开发 (Agile Software Development)
影响最广泛的敏捷软件开发方法如下
- Scrum(得名于橄榄球比赛)
规划纲要: 冲刺, 总结项目, ; - 极限编程
策划: 设计, 编码, 测试, ; - 看板
可视化工作流: 限制在制品, 管理流量, 。