目录
前言
参考教材:《软件工程——原理、方法与应用》(第3版)
第1章 绪论
1.1 软件和软件危机
1.1.3 软件危机
软件危机指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
软件工程方法的产生源于软件危机,软件的复杂性是产生软件危机的内在原因。
产生软件危机的原因:
- 软件维护费用急剧上升,直接威胁计算机应用的扩大。
- 软件生产技术进步缓慢,是加剧软件危机的重要原因。
Q:什么是软件危机?为什么会产生软件危机?
A:软件危机是指落后的软件生产方式无法满足迅速增长的软件需求,从而导致软件开发与维护过程中出现一系列问题现象。原因主要有:一,软件维护费用急剧上升,直接威胁计算机应用的扩大;二,软件生产技术进步缓慢。
1.2 软件工程学的范畴
1.2.1 软件开发方法学
软件的发展,大体上经历了程序、软件和软件产品 3 个阶段。
1.3 软件工程的发展
1.3.1 3种编程范型
- 过程式编程范型:着眼于程序的过程和基本控制结构,粒度最小。
- 面向对象编程范型:着眼于程序中的对象,粒度比较大。
- 基于构件技术的编程范型:着眼于适合整个领域的类对象,粒度更大。
由上可见,编程范型的演变是伴随着编程粒度的扩大而推进的,这也标志着软件开发技术的不断成熟。
Q:什么是软件生产工程化?工程化生产方法与早期的程序设计方法主要差别在哪里?
A:结构化程序设计的出现,使许多产业界认识到必须把软件生产从个人化方式改变为工程化。采用工程的概念、原理、技术和方法开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它,这就是软件工程,同时这也是工程化生产方法。
第2章 软件生存周期与软件过程
2.1 软件生存周期
Q:什么是软件生存周期?把生存周期划分为阶段的目的是什么?
A:软件生存周期划分为计划、开发和运行三个时期;把整个生存周期划分为较小的阶段,给每个阶段赋予确定而有限的任务,就能够化简每一步工作内容,使因软件规模而增长而大大增加了软件复杂性得交易控制和管理。
软件生存周期的主要活动:
需求分析 → 软件分析 → 软件设计 → 编码(测试)→ 软件测试 → 运行维护
2.2 传统的软件过程
2.2.1 瀑布模型(大题常考)
瀑布开发模型是一种基于软件生存周期的线性开发模型。
瀑布模型的缺点是缺乏灵活性,特别是无法解决软件需求不明确或不准确的问题。
特点
- 阶段间的顺序性和依赖性
- 推迟实现的观点
- 保证质量的观点
阶段
- 用户要求
- 需求分析
- 概要/总体设计
- 详细设计
- 编码
- 测试
- 维护
缺点
由于用户不可能一次性的提出所有的需求,而瀑布模型是属于“线性”的开发模型,因而瀑布模型不能适应用户在开发后期提出的需求变更。
存在的问题
按照瀑布模型来开发软件,只有当分析员能够做出准确的需求分析时,才能够得到预期的结果。不幸的是,由于多数用户不熟悉计算机,系统分析员对用户的专业也往往了解不深,因而很难在开发的初始阶段彻底弄清软件需求。为了解决这一问题,人们提出了“快速原型模型”。
2.2.2 快速原型模型
原型化方法是用户和设计者之间执行的一种交互构成,适用于需求不确定性高的情况。
在快速原型模型的开发过程中,用原型过程来代替全部开发阶段所用模型是演化型原型模型。
原型开发的优越性
- 逼真
- 快速
软件开发人员向用户提供一个“样品”,用户向开发人员迅速作出反馈。
原型模型的启示
下图显示了快速原型软件开发的过程模型。
用户的介入和反馈,使它在原型的分析与设计阶段可能出现多次回溯和迭代,从而形成非线性的开发模型。
2.3 软件演化模型
常见的演化模型有增量模型与螺旋模型两种。它们都是瀑布模型和快速原型模型相结合的产物。
2.3.1 增量模型(incremental model)
2.3.2 螺旋模型(spiral model)
适用于大型软件的开发。
项目按照顺时针方向沿螺旋线移动时,每轮螺旋包含以下四种活动:
- 计划
- 风险分析
- 建立原型
- 用户评审
按此顺序周而复始,直到实现最终产品。
螺旋模型的特点,是在项目的所有阶段都考虑各类风险,从而能在风险变成问题之前降低它的危害。螺旋模型开发的成败,在很大程度上依赖于风险评估的准确性。
2.3.3 构件集成模型
适用于面向对象的软件开发。
统一建模语言(unified modeling language,UML),把众多面向对象分析和设计工具综合成一种标准,使面向对象的方法成为主流的软件开发方法。
面向对象思想最重要的特征是在解空间中引入了“对象”的概念。
面向对象方法学包含了对象(object)、类(class)、继承(inheritance)、消息(message)等核心概念。
面向对象 = 对象 + 分类(classification)+ 继承 + 消息通信(communication with messages)
2.4 形式化方法模型
软件开发方法可分为:
- 形式化方法——学术界流行
- 非形式化方法——工业界流行
2.4.1 转换模型(transformational model)
转换模型是将形式化软件开发和程序自动生成技术相结合的一种软件开发模型。
2.4.2 净室模型(cleanroom model)
净室模型是一种形式化的增量开发模型。
基本思想:力求在分析和设计阶段就消除错误,确保正确,然后在无缺陷或“洁净”的状态下实现软件的制作。
2.5 统一过程和敏捷过程
Q:RUP是什么? 试比较RUP和XP的差异。
A:RUP(Rational Unified Process,统一软件开发过程,统一软件过程)是一个面向对象且基于网络的程序开发方法论。
RUP统一软件过程是描述软件开发中各个环节应该做什么,怎么做,什么时候做以及为什么要做,描述了以某种顺序完成的活动。其在一个二维空间中描述软件开发活动,可以分为初始阶段,细化阶段,构造阶段和迁移阶段。
XP 极限过程是一个轻量级的,敏捷的软件开发方法,同时也是一个非常严谨和周密的方法。它有四个价值观:交流,简单,反馈和勇气。
2.5.1 统一过程(Rational Unified Process,RUP)
统一过程描述了软件开发中各个环节做的内容:
- 做什么——产品(artifact)
- 怎么做——活动(activity)
- 什么时候做——工作流(workflow)
- 为什么要做
- 谁来做——人员(role)
统一过程包括四个阶段:
- 初始阶段
- 细化阶段
- 构造阶段
- 迁移阶段
2.5.2 敏捷过程
敏捷开发(agile development)是一种以人为核心、以迭代方式循序渐进开发的方法,其软件开发的过程称为“敏捷过程”。
下图为 4 个简单的价值观以及敏捷开发方法应遵循的 12 条原则:
2.5.3 极限编程(extreme programming,XP)
极限编程是敏捷过程的一种方法。
它有 4 个价值观:
- 交流
- 简单
- 反馈
- 勇气
即,任何一个软件项目都可以从 4 个方面入手进行改善:
- 加强交流
- 从简单做起
- 寻求反馈
- 勇于实事求是
XP方法包括以下 12 个核心实践:
2.6 软件可行性研究
可行性论证其实是在高层次上进行的一次大大简化了的需求分析与设计。
可行性研究进一步研究问题分析阶段所确定的问题是否有可行的解。
2.6.1 可行性研究的内容与步骤
1. 研究的内容
- 经济可行性。实现这个系统有没有经济效益?多长时间可以收回成本?
- 技术可行性。现有的技术能否实现这一新系统?有哪些技术难点?建议采用的技术先进程度怎样?
- 运行可行性。为新系统规定的运行方式是否可行?
- 法律可行性。新系统的开发会不会在社会上或政治上引起侵权、破坏或其他责任问题?
2.6.2 软件风险分析
- 风险识别
- 风险预测
- 风险的驾驭和监控
第3章 结构化分析与设计
第一代(传统软件工程)→ 第二代(OO软件工程)→ 第三代(基于构件的软件工程)
本章重点介绍基于瀑布模型的结构化分析与设计。
3.1 概述
3.1.1 结构化分析与设计的由来
系统的整个开发流程,可以简明地表示为:
- DFD 图:Data Flow Diagram,数据流图
- PSPEC:加工规格说明
- CSPEC:控制规格说明
- SRS:Software Requirements Specification,需求规格说明书
- SC 图:Structure Chart,结构图
结构化分析(structured analysis,SA)
任务:
- 建立系统分析模型(analysis model)
- 编写软件需求规格说明书
步骤:
- 自顶向下对系统进行功能分解,画出分层 DFD 图
- 由后向前定义系统的数据和加工,编写 DD 和 PSPEC
- 最终写出 SRS
数据流图和数据字典共同构成了系统的逻辑模型,是需求规格说明书的主要组成部分。
结构化设计(structured design,SD)
SD 阶段先把分析模型中的 DFD 图转换为最终 SC 图。
软件设计 = 概要/总体设计 + 详细设计/模块设计
传统的软件设计又可细分:
- 面向数据流的设计
- 面向数据(数据结构)的设计
前者以 SD 方法为代表,后者以 Jackson 方法为代表。
3.1.2 SA 模型的组成与描述