软件工程整理.docx
《软件工程整理.docx》由会员分享，可在线阅读，更多相关《软件工程整理.docx（33页珍藏版）》请在冰点文库上搜索。
软件工程整理
第1章软件工程学概述
软件危机、产生原因、解决途径
软件、软件工程、软件生命周期、各阶段主要任务
软件过程模型：
瀑布模型、快速原型模型等
软件概念-软件
软件（Software）是计算机系统中与硬件相互依存的另一部分，它是包括程序（Program），数据（Data）及其相关文档（Document）的完整集合。
软件=程序+数据+文档
软件概念-软件的特点
抽象性
软件是逻辑实体，没有明显的制造过程，运行和使用没有磨损与老化问题。
依存性
软件开发和运行依赖于计算机系统。
工艺性
软件开发至今尚未完全摆脱手工工艺的开发方式。
复杂性
软件逻辑结构、开发技术、项目管理复杂。
成本高
开发成本、维护成本高。
风险大
软件项目的成功率低。
维护难
维护不能依靠原开发者，理解软件代码难，维护也是开发，维护成本高
软件工作涉及各种社会因素
政策规章、管理思想、文化背景、信息素养、技术水平、系统接口等。
软件的复杂性
逻辑复杂
软件的逻辑结构非常复杂
开发复杂
成本难以估算、进度难以控制、人员素质要求、质量得不到保证
软件危机
软件危机是计算机软件开发和维护过程中所遇到的一系列严重问题。
主要包括下列两个方面的问题：
如何开发软件，以满足对软件的日益增长的需求；
如何维护不断增多的已有软件。
软件危机的典型表现
对软件开发成本和进度的估计常常很不准确；
用户对交付的软件经常不满意；
软件产品的质量往往达不到要求；
开发出来的软件通常难以维护；
软件产品文档资料不适用和不完善；
软件成本在整个系统总成本中所占比例逐年上升；
软件开发生产率的提高不能满足对软件需求的增长；
………
产生软件危机的原因
与软件本身的特点有关
成本高、风险大、难于维护、逻辑复杂。
软件是计算机系统中的逻辑实体而不是物理实体，软件生产与硬件不同，在它的开发过程中没有明显的制造过程。
软件是通过人们的智力活动，把知识与技术转化成信息的一种产品。
在软件的运行过程中，没有“用坏”的问题。
软件维护意味着修正原来的设计，较为困难。
与软件开发与维护的方法不正确有关
软件专业人员对软件开发和维护存在糊涂观念，在实践过程中采用了错误的方法和技术。
如忽视软件需求分析的重要性；轻视软件维护。
消除软件危机的途径
正确认识“软件”
软件≠程序，软件是相关程序、数据及文档的集合。
正确认识“软件开发”
软件开发不是个体劳动，而主要是一种有组织的团队活动。
研究软件开发的技术手段
在软件开发中使用已证明行之有效的技术，研究和探索新的技术。
更好地使用软件工具，建立一个良好的软件工程支撑环境。
研究软件开发的管理方法
在软件开发中使用已证明行之有效的工程管理方法。
组织良好、管理严密，使各类人员协同配合，共同完成软件开发的工程项目。
软件工程学的产生
软件工程学的是由于“软件危机”的出现和加重而产生的，研究用工程的方法来管理软件的开发。
开发一个具有一定规模和复杂性的软件系统与编写一个简单的程序不一样。
大型、复杂软件系统的开发是一项工程，必须按照工程化的方法组织软件的生产和管理，必须经过分析、设计、实现、测试、维护等一系列软件过程和活动
软件工程概念
软件工程是指导计算机软件开发与维护的一门工程学科。
采用工程的概念、原理、方法和技术来开发和维护软件。
将经过时间和实践考验而证明正确的管理方法和最好的技术手段结合起来，经济有效地开发和维护软件。
软件工程是一门不断发展的学科。
软件工程的本质特性
关注于大型程序的构造
控制软件复杂性
适应软件的经常变化性
提高软件开发的效率
和谐合作开发软件
使软件有效地支持它的用户需求
软件是有一种文化背景的人为另一种文化背景的人开发的产品。
软件工程的基本原理
用分阶段的生命周期计划严格管理
坚持进行阶段评审
实行严格的产品控制
采用现代程序设计技术
结果应能清楚地审查
开发小组的人员应该少而精
承认不断改进软件工程实践的必要性
软件工程方法学
软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。
通常把在软件生命周期全过程中使用的一整套技术方法的集合称为软件工程方法学（methodology），也称为范型（paradigm）
软件工程方法学包含3个要素：
方法、工具和过程。
软件生命周期
一个软件定义、开发、使用和维护，直到最终被废弃，要经历的漫长的时期，称为软件的生命周期。
软件生命周期基本阶段的任务
（1）软件定义时期
总目标的确定，可行性，采用策略，系统功能，所需资源与成本，工程进度表，也称为系统分析时期，分为所定义，可行性研究和需求分析。
（2）开发时期
具体设计和实现前面所定义的软件。
分为：
总体设计，详细设计，编码和单元测试，综合测试。
（3）维护时期
使软件尽量地满足用户需要，纠错，适应新环境，满足新需求
软件生命周期的阶段（具体）
1.问题定义
要解决的问题是什么？
2.可行性研究
问题能够解决吗？
3.需求分析
为了解决问题需要做什么？
4.总体设计
为了解决问题，大概怎样做？
5.详细设计
为了解决问题，具体怎样做？
6.编码和单元测试
编程实现，并测试每一个程序模块，验证程序达到设计要求。
7.综合测试
集成测试、压力测试、验收测试，验证系统满足需求。
8.软件维护
改正性维护、适应性维护、完善性维护、预防性维护，保障系统持久性满足用户的要求。
软件过程
软件过程是为了获得高质量的软件需要完成的一系列任务的框架，规定了完成各项任务的工作步骤。
软件过程定义了软件工程的阶段、应用方法的顺序、应交付的文档、保证软件质量的措施、标志软件开发各阶段的里程碑。
常用软件过程模型（具体见课件）
（1）瀑布模型（WaterfallModel）
（2）快速原型模型（RapidPrototypeModel）
（3）增量模型（IncrementalModel）
（4）螺旋模型（SpiralModel）
（5）面向对象模型（喷泉模型、可重用组件模型）
（6）统一软件开发过程（IBMRUP）
（7）敏捷（灵活）过程与极限编程
（8）微软过程（MicrosoftSolutionFramework）
瀑布模型的优缺点
瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。
瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。
“瀑布模型是由文档驱动的”，这个事实是它的一个主要缺点。
实际项目很少按照该模型给出的顺序进行；
用户常常难以清楚地给出所有需求；
用户必须有耐心，等到系统开发完成。
快速原型模型
快速原型法是一种新型的软件开发方法，它使用交互的，快速建立起来的原型取代了形式的、僵硬的大量的规格说明，用户通过在计算机上实际运行和试用原型系统而向开发者提供真实的反馈意见。
原型模型存在的问题
⑴为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。
⑵为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。
⑶开发过程不便于管理。
有效的使用原型模式
建造原型仅是为了定义需求，之后就被抛弃（或被部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。
增量模型
是一种渐进地开发逐步完善的软件版本的模型
增量模型优点
在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。
从第一个构件交付之日起，用户就能做一些有用的工作。
整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。
逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。
增量模型的困难
在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。
此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。
开发人员既要把软件系统看作整体。
又要看成可独立的构件，产生观念上的矛盾。
多个构件并行开发，具有集成的风险。
螺旋模型
软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。
对于复杂的大型软件，开发一个原型往往达不到要求。
螺旋模型将瀑布模型和增量模型结合起来，加入了风险分析。
在该模型中，软件开发是一系列的增量发布，早期的迭代中，发布的增量可能是一个纸上的模型或原型，在以后的迭代中，逐步产生系统更加完善的版本。
螺旋模型的基本思想是降低风险。
螺旋模型的优点和特点
螺旋模型的优点
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标
减少了过多测试或测试不足
维护和开发之间并没有本质区别
螺旋模型的特点
风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大
主要适用于内部开发的大规模软件项目，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险
随着迭代次数的增加，工作量加大，软件开发成本增加
面向对象-喷泉模型
喷泉模型（FountainModel）是面向对象模型。
主要用于支持面向对象开发过程，体现了软件创建所固有的迭代和无间隙的特征
面向对象-构件集成模型
构件（components）也称为组件，是一段实现一系列有确定接口的程序体，具有自己的功能和逻辑，能同其他构件集成起来协调工作。
该模型（又称为可重用部件组装模型）支持软件重用（Reusability），对缩短软件开发周期、降低项目成本有重要的现实意义。
同时，建造符合某应用领域体系结构标准的构件，可以用来搭建分布式的、跨越不同操作平台（集成化软件开发环境（ISEE））的软件，扩展了软件的应用前景，促进了软件标准化、商品化的发展。
在此基础上专家们又提出了“基于构件的软件工程”（CBSE）。
第2章可行性研究
可行性研究的主要任务和过程
数据流图和数据字典的实际应用
可行性研究的目的
用最小的代价在尽可能短的时间内确定问题是否能够解决。
可行性研究不是解决问题，而是确定问题是否值得去解决。
可行性研究的任务
可行性研究的主要任务是“了解客户的要求及现实环境，从技术、经济和社会因素等三方面研究并论证本软件项目的可行性，编写可行性研究报告，制定初步项目开发计划。
”
可行性研究的最根本任务——对软件开发以后的行动方针提出建议。
可行性研究的内容
可行性分析
（1）技术可行性
（2）经济可行性
（3）操作可行性
（4）社会条件可行性（如法律可行性）
效益分析
社会效益
经济效益
解决方案选择
导出系统的逻辑模型，对多种可能的解决方案分析可行性，选择方案
可行性研究过程
1.复查系统规模和目标
确切了解要做的事情。
2.研究目前正在使用的系统
现有系统能做什么？
不能做什么？
有什么缺陷？
3.导出新系统的高层逻辑模型
使用形式化工具（数据流图、数据字典等）描述系统高层模型。
4.进一步定义问题
以系统高层模型为基础，与用户一起进一步问题的定义、系统规模和目标，修改模型，使其符合系统建设目标。
5.导出和评价供选择的解法
以最后提出的系统模型为基础，导出物理解决方案（可能多个），分析技术、操作、经济等可行性，制定进度表。
6.推荐行动方针
确定是否继该项工作，选择解决方案，进行成本效益分析。
7.草拟开发计划
估算进度、经费、人力资源（各层次开发、管理人员）、其他资源（硬件、软件等）的需求和使用计划。
8.书写文档提交审查
将上述研究编写成“可行性研究报告”，提交评审。
数据流图（具体设计及相关符号看课本ppt）
一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示。
设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能，所以它也是今后进行软件设计的很好的出发点。
数据流图的用途
基本用途是作为交流信息工具
对目标系统所设想的系统模型，不含系统实现的物理细节，用户容易理解，可供相关人员评审。
作为分析和设计的工具
数据流图只描述了系统的功能和数据及其流动，而不是系统的物理实现（而系统流程图将功能和功能的实现方案混合在一起），便于分析人员关注与与实现无关的模型，开发人员关注设计与实现，界面清晰。
用于确定系统工作边界
当数据流图用于辅助物理设计时，根据不同的处理要求，可用来在图上划分不同的自动处理、手工处理边界，从而实现不同的物理系统。
数据字典（具体实现见课本ppt）
数据流图和数据字典共同构成系统的逻辑模型
数据字典的内容
一般说来，数据字典应该由对下列4类元素的定义组成：
（1）数据流
（2）数据流分量（即数据元素）
（3）数据存储
（4）处理
数据字典的实现
CASE结构化分析与设计工具（大型软件）
卡片形式/excelorrecordinfile（小型软件）
卡片应该包含下述信息：
名字、别名、描述、定义、位置。
第3章需求分析
需求分析的目的和主要任务
需求分析主要方法
需求分析的主要描述工具：
数据流图/数据字典、实体-联系图、状态转换图等
需求分析的意义
软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。
需求分析的目的
需求分析是软件定义时期的最后一个阶段，它的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
并在在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。
----准确地回答“系统必须做什么?
”
需求分析的任务
确定对系统的综合要求
功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、逆向需求、将来可能提出的要求。
分析系统的数据要求
用直观和定义的形式建立系统的数据模型，优化和规范化数据结构。
常用工具：
图形工具（层次方框图、Warnier图）、数据字典。
导出系统的逻辑模型
综合上述分析结果，导出系统的详细逻辑模型。
常用工具：
数据流图、实体-联系图、状态转换图、数据字典、主要处理算法。
修正系统开发计划
以详细逻辑模型为基础，与用户交流，跟深入地了解和明确用户的需求，估算系统开发成本、进度等，修订项目开发计划。
需求分析的相关人
在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用
需求获取方法与技术
需求分析小组
建立由客户（用户）、系统分析员、领域专家参加的联合小组。
需求获取的方法
个别访谈、召集会议、文档研究、问卷调查、观察用户工作流程、建立原型。
需求表达的技术
（1）需求列表：
需求与系统的特殊视角或环境的关系
（2）业务流程图（状态/活动图）
（3）数据流图
（4）实体-联系图
*与用户沟通获取需求的方法
访谈
面向数据流自顶向下求精
简易的应用规格说明技术
快速建立软件原型
访谈
访谈的基本形式
非正式访谈：
获取用户（高端用户）的想法、理念;
正式访谈：
获取用户（业务部门用户）的具体需求，如功能需求、数据需求等。
访谈技术
开放性问题（非正式访谈）
具体问题（正式访谈）
问卷调查表
情景分析技术
座谈会
……
面向数据流自顶向下求精
数据流分析重要性
数据是需求分析的出发点和落脚点
信息系统的基本模型：
输入数据ð数据处理ð输出数据
数据在流动中被处理，数据决定了处理所需的算法
结构化分析方法
可实现数据流自顶向下逐步求精
从可行性研究得出的顶层模型（顶层数据流图）开始，将数据流和数据存储及其处理向下分解，直到元素级。
数据流分析的结果
清晰地定义了可实际操作的个数据元素；
明确地展现了数据的来源与去处；
初步描绘了数据处理的可能算法（方法）。
数据流描述方法
数据流图：
数据及其处理关系
数据字典：
数据元素
IPO图：
处理算法
简易的应用规格说明技术
前叙方法的缺陷问题
面谈调研、数据流图、数据字典等是具有一定技术性的、形式性方法，一般用于难以掌握，不好交流，不难有效地构建需求分析团队。
简易的应用规格说明技术
这是一种面向团队的需求收集方法。
提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。
快速建立软件原型
构建软件原型
按照“快速原型法”构建系统的软件原型，这是最准确、最有效、最强大的需求分析技术。
软件原型的要点是展现用户看得见、直接交互的功能，如输入、输出、检索、显示、打印等。
软件原型构建特性
快速
易于修改
软件原型构建方法和工具（综合使用）
第四代程序设计技术
可重用的软件构建
形式化规格说明工具和软件环境工具
*软件需求的组成部分
业务需求：
反映组织机构和客户对系统、产品高层次的目标要求。
用户需求：
从用户使用的角度给出需求的描述。
系统需求：
从系统的角度描述要提供的服务以及所受到的约束。
功能需求：
描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务。
性能需求
存储容量、处理速度、用户数、并发能力等。
接口需求
本系统与其他系统的接口。
出错处理需求
系统可能的错误及其处理方法。
非功能性需求：
系统必须具备的属性或品质。
可靠性和可用性需求
可靠性指标、可用性指标
设计约束：
设计与实现必须遵循的标准、约束条件。
如运行平台、协议、选择的技术、编程语言和工具等。
*软件需求的描述
语言描述
自然语言、结构化语言、过程描述语言PDL...
图形/表格化描述
数据流图、数据字典、IPO图、判定表、判定树、状态图...
数学描述
形式化语言、函数、状态机
*软件需求获取和分析
需求获取
是开发人员与客户或用户一起对应用领域进行调查研究，收集系统需求的过程。
需求分析
是将获取到的需求准确的理解、求精，并将其转化为完整的需求定义（包括建模），进而生成需求规约的过程。
需求描述和文档编写
按照规范的格式（标准指南，如国标）和采用常用的工具编制软件需求分析说明书。
需求管理
管理需求工程的变更。
需求有效性验证
提交用户反馈，召开需求评审会。
从哪些方面验证软件需求的正确性（验证软件需求的方法）
（1）一致性
所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
（2）完整性
需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
（3）现实性
指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
（4）有效性
必须证明需求是正确有效的，确实能解决用户面对的问题。
第4章形式化说明技术
有穷状态机
Petri网
有穷状态机——概念（具体使用见课本ppt）
一个有穷状态机包括下述5个部分：
状态集J、输入集K、由当前状态和当前输入确定下一个状态（次态）的转换函数T、初始态S和终态集F。
状态集J：
有所有可能的状态构成的有穷集合；
输入集K：
引发状态变换的可能的外部输入（或操作）；
转换函数T：
由当前状态和当前输入变换到下一个状态（次态）的函数（或规则）；
初始态S∈J，状态机的初始状态；
终态集F∪J，状态机的终止状态集；
Petri网及其用途（具体使用见课本ppt）
用于确定系统中隐含的定时问题的一种有效技术是Petri网，这种技术的一个很大的优点是它也可以用于设计中，有效地描述并发活动。
Petri网是对离散并行系统的数学表示。
Petri网既有严格的数学表述方式，也有直观的图形表达方式。
Petri网适合于描述异步的、并发的自动化系统和计算机系统模型。
Petri网在计算机科学得到了广泛的应用，例如，在系统性能评价、操作系统和软件工程等领域，Petri网应用得都比较广泛。
Petri网包含4种元素：
一组位置P（Place）:
圆形
一组转换T（Transition）:
线性/矩形
输入函数I（Input）
输出函数O（Output）
其他元素
连接Connection:
箭头
权标Token（令牌）:
圆点
总体设计
总体设计目的和主要任务
总体设计过程
模块化概念：
模块化、抽象、求精、信息隐蔽
模块独立性：
耦合程度、内聚程度
总体设计的目的
用比较抽象的方法确定系统概要地是如何实现的（Howtodogenerally!
）。
从初步的数据流图导出（设计出）软件结构。
主要分为系统设计（DFD、方案、功能）和软件结构设计（DFD、软件结构）二个阶段。
总体设计的过程
1.设计供选择的方案
2.选取合理的方案
3.推荐最佳实现方案
4.功能分解
5.软件结构设计
6.数据库设计
7.制定测试计划
8.编写文档
9.审查和复审
软件设计基本原理（总体设计的原理）
1.模块化
2.抽象
3.逐步求精
4.信息隐蔽
5.模块独立性
1.模块化
模块
模块是由一个标识符所代表的、由边界元素（如Java中的｛…｝）限定的相邻程序元素（数据/变量说明、可执行语句）的、实现特定功能的序列。
模块又称构件，是能够单独命名并独立地完成一定功能的程序语句的集合。
例如高级语言中的过程、函数、子程序等都可作为模块。
模块化是软件的一个重要属性
模块化的特性提供了人们处理复杂的问题的一种方法，同时也使得软件能够被有效地管理。
模块化特性
设函数：
C（x）表示问题x的复杂程度；
E（x）表示解决问题x所需要的工作量（时间）。
对于两个问题P1和P2，
如果：
C（P1）＞C（P2），则显然有：
E（P1）＞E（P2）
另一个特性是：
C（P1＋P2）＞C（P1）＋C（P2）
根据上面的结论，还有：
E（P1＋P2）＞E（P1）＋E（P2）
这个不等式表明：
单独解决问题P1和P2所需的工作量之和，比把P1和P2合起来作为一个问题来解决时所需的工作量要少。
这种“分而治之”的思想提供了模块化的根据：
把复杂的问题分解成许多容易解决的小问题，原来的问题也就容易解决了。
2.抽象
抽象
我们在考虑问题时，集中考虑和当前问题有关的方面，而忽略和当前问题无关的方面，这就是抽象。
或者说抽象就是抽出事物的本质特性而暂时不考虑它们的细节。
软件工程过程中的抽象
软件工程过程的每一步，都是对软件解法的抽象层次的一次细化。
在可研阶段，软件被看作是一个完整的系统部分；在需求分析期间，使用在问题环境中熟悉的术语来描述软件的解法；当由总体设计阶段转入详细设计阶段时，抽象的程度进一步减少；最后，当源程序写出来时，也就达到了抽象的最低层。
总体设计中的抽象
总体设计中的软件层次结构是一种抽象，自顶向下是软件抽象层次的细化。
这种抽象简化了软件的设计与实现，提高了可理解性和可测试性。
3.逐步求精
逐步求精：
逐步求精是人类解决复杂问题时采用的基本用法，也是许
升级会员 