华南理工大学经济与贸易学院软件工程简单总结.docx
《华南理工大学经济与贸易学院软件工程简单总结.docx》由会员分享，可在线阅读，更多相关《华南理工大学经济与贸易学院软件工程简单总结.docx（33页珍藏版）》请在冰点文库上搜索。
华南理工大学经济与贸易学院软件工程简单总结
第一章
一、软件的特征
•软件是一种逻辑实体，具有抽象性
•软件没有明显的制造过程
•软件在使用过程中，没有磨损、老化的问题
•软件对硬件和环境有着不同程度的依赖性
•软件的开发至今尚未完全摆脱手工作坊式的开发方式，生产效率低
•软件是复杂的，而且以后会更加复杂
•软件的成本相当昂贵
•大多数软件是自定的，而不是通过已有的构件组装而来的
•软件工作牵涉到很多社会因素
二、分类
控制层次，软件分为系统软件和应用软件两大
系统软件
应用软件
计算机系统软件是计算机管理自身资源（如CPU、内存空间、外存、外部设备等），提高计算机的使用效率并为计算机用户提供各种服务的基础软件。
应用软件是计算机所应用程序的总称，主要用于解决一些实际的应用问题
（1）操作系统。
（2）语言处理程序：
机器语言、汇编语言、高级语言
（3）数据库管理系统
（4）实用程序与软件工具
（1）个人计算机软件
（2）科学和工程计算软件
（3）实时软件
（4）人工智能软件
（5）嵌入式软件
（6）事务处理软件
（7）工具软件
三、与硬件的区别
软件是一种逻辑实体，而不是具体的物理实体
软件的生产与硬件不同
在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题
四、软件危机的主要表现
●对软件开发成本和进度的估计常常不准确。
开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见。
●用户对“已完成”系统不满意的现象经常发生。
●软件产品的质量往往靠不住。
Bug一大堆，Patch一个接一个。
●软件的可维护程度非常之低。
●软件通常没有适当的文档资料。
●软件的成本不断提高。
●软件开发生产率的提高赶不上硬件的发展和人们需求的增长。
五、消除危机的途径
●对计算机软件有一个正确的认识（软件≠程序）
●必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
●推广使用在实践中总结出来的开发软件的成功技术和方法。
●开发和使用更好的软件工具。
六、软件工程的三个要素（方法、工具和过程）
1.软件工程是一种层次化的技术，以有组织的质量保证为基础。
全面的质量管理和类似的理念刺激了不断的过程改进，正是这种改进导致了更加成熟的软件工程方法的不断出现。
支持软件工程的根基就在于对质量的关注。
2.软件工程的基层是过程层。
软件工程过程是将技术层结合在一起的凝聚力，使得计算机软件能够被合理地和及时地开发出来。
过程定义了一组关键过程区域框架，构成了软件项目的管理控制的基础，并且确立了上下各区域之间的关系，规定了技术方法的采用、工程产品（模型、文档、数据、报告、表格等）的产生、成本的建立、质量的保证及变化的适当管理。
3.软件工程的方法层提供里建造软件在技术上需要“如何做？
”。
方法涵盖了一系列的任务：
需求分析、设计、编程、测试和维护。
软件工程方法依赖于一组基本原则，这些原则控制了每一技术区域，且包含建模活动和其他描述技术。
4.软件工程的工具层对过程和方法提供了自动的或半自动的支持。
当这些工具被集成起来使得一个工具产生的信息可被另外一个工具使用时，一个支持软件开发的系统就建立了，称为计算机辅助软件工程（CASE）。
CASE集成了软件、硬件和一个软件工程数据库（一个仓库，其中包含了分析、设计、编程和测试的重要信息）。
七、软件工程方法学
方法—完成软件开发的各项任务的技术方法，回答“怎样做”的问题；
工具—为运用方法而提供的自动的或半自动的软件工程支撑环境；
过程—为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
八、软件工程基本特征
⏹软件工程关注于大型程序的构造
⏹软件工程的中心课题是控制复杂性
⏹软件经常变化
⏹开发软件的效率非常重要
⏹和谐地合作是开发软件的关键
⏹软件必须有效地支持它的用户
⏹在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品
九、软件工程基本原理
1.用分阶段的生命周期计划严格管理
六类计划：
项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。
2.坚持进行阶段评审
软件的质量保证工作不能等到编码结束之后再进行，应坚持严格的阶段评审，以便尽早发现错误。
3.实行严格的产品控制
采用变动控制。
当需求变动时，其他各个阶段的文档或代码随之相应变动，以保证软件的一致性。
4.采纳现代程序设计技术
结构化软件开发->面线对象软件开发…
5.结果应能清楚地审查
软件开发小组的工作进展情况可见性差，难于评价和管理。
为更好地进行管理，应根据软件开发的总目标及完成期限，明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。
6.开发小组的人员应少而精
开发人员素质高，开发效率高质量好。
人员少，犯错误降低。
7.当开发小组为N人时，可能的通讯信道为N（N-1）/2，随着人数N的增大，通讯开销将急剧增大
8.承认不断改进软件工程实践的必要性
一十、结构化编程分析、设计和结构化程序设计
指导思想：
自顶向下、逐步求精；方法：
面向数据流；功能：
分解和抽象。
适合处理数据处理领域的问题。
1.结构化分析，就是根据分解与抽象的原则，按照系统中数据处理的流程，用数据流图来建立系统的功能模型，从而完成需求分析。
2.结构化设计，就是根据模块独立性准则、软件结构准则，将数据流图转换为软件的体系结构，用软件结构图来建立系统的物理模型，实现系统的概要设计。
3.结构化程序设计，就是根据结构程序设计原理，将每个模块的功能用相应的标准控制结构表示出来，从而实现详细设计。
一十一、Jaskson方法
1、一种面向数据结构的详细设计方法。
2、把问题分解为可由三种基本结构形式表示的各部分层次结构。
这三种基本结构形式就是顺序、选择和重复。
瀑布模型
3、以数据结构为驱动，适合小规模的项目。
一十二、瀑布模型需求分析---规格说明---设计---编码---综合测试---维护
瀑布模型优点
瀑布模型缺点
可强迫开发人员采用规范的方法（例如，结构化技术）；
实际项目很少按照该模型给出的顺序进行；
严格地规定了每个阶段必须提交的文档；
用户常常难以清楚地给出所有需求；
要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。
用户必须有耐心，等到系统开发完成；
开发者常常被不必要地耽搁
一十三、增量模型优缺点
先完成一个系统子集的开发，再按同样的开发步骤增加功能（系统子集）,如此递增下去直至满足全部系统需求。
优点
缺点
在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。
从第一个构件交付之日起，用户就能做一些有用的工作。
在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。
此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。
整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。
逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
开发人员既要把软件系统看作整体。
又要看成可独立的构件，相互矛盾。
采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报
多个构件并行开发，具有无法集成的风险
一十四、
螺旋模型优缺点
优点
特点
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；
风险驱动
主要适用于内部开发的大规模软件项目
减少了过多测试或测试不足；
要有具有丰富风险评估专门知识的开发人员，否则风险更大。
维护和开发之间并没有本质区别。
一十五、喷泉模型优缺点
主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征
一十六、快速原型模型优缺点
快速建立起来的可以在计算机上运行的程序，他所能完成的功能往往是最终产品能完成的功能的一个子集。
优点
缺点
原型系统已经通过与用户交互而得到验证。
不用担心规格说明书文档错误导致返工
软件原型因为用户的需求，往往打乱整个开发管理计划，导致软件质量的降低
开发人员在开发原型时已经掌握基本技巧，防止编码错误
软件原型开发时间短，出现问题多。
导致开发人员真正开发时候容易忽略细节问题
一十七、可重用部件组装模型（构件集成模型）
使用重用技术的软件工程模型
•构件（components）：
可重用的软件成份
•可复用性（Reusability）
•集成化软件开发环境（ISEE）
第二章
可行性研究的内容（技术、经济、操作、社会[法律]、抉择）
数据流图
⏹它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
⏹在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示。
⏹设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能，所以它也是今后进行软件设计的很好的出发点。
多层数据流图：
⏹顶层流图仅包含一个加工，它代表被开发系统。
它的输入流是该系统的输入数据，输出流是系统所输出数据。
⏹中间层流图则表示对其上层父图的细化。
它的每一加工可能继续细化，形成子图。
⏹底层流图是指其加工不需再做分解的数据流图，它处在最底层。
分层DFD图的优点
便于实现----采用逐步细化的扩展方法，可避免一次过多的细节，有利于控制问题的复杂度
便于使用----用一组图代替一张总图，方便用户及软件开发人员阅读
第三章
软件需求的内容：
功能需求
非功能需求：
性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、成本消耗需求、开打进度需求、系统目标
需求分析的任务：
确定系统必须完成哪些工作
原理：
借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。
需求分析的具体任务
1、确定对系统的综合要求：
软件需求的内容
2、分析系统的数据要求：
确定数据对象（属性、联系和约束）
3、导出系统的逻辑模型：
各种图形工具
4、修正系统开发计划
第四章
软件设计的内容
◆体系结构设计------定义软件部件间的关系
◆接口设计-------------软件内部、外部及与人之间的通信
◆数据设计-------------信息模型（软件数据结构）
◆
过程设计-------------软件组件的过程性描述
模块数与开发工作量的关系
其中模块成本指的是单个模块的成本，上面模块成本曲线的意思是一个系统模块越多，单个模块开发工作量就会降低，同时单个模块的成本也会降低
模块划分的四项基本原则
1.模块独立性强
●块内联系强：
一个模块内部各个元素彼此结合的紧密程度
●块间联系弱：
两个或两个以上的实体相互依赖于对方的程度弱
2.高内聚
●模块内部各成分之间（顺序性内聚、功能性内聚）
3.低耦合
●
一个模块与其它模块之间
4.公共（共享）模块
●多个模块共享（减少冗余）
内聚与耦合关系
内聚和耦合是相互关联的。
在程序结构中各模块的内聚程度越高，模块间的耦合程度就越低。
但这也不是绝对的。
软件概要设计的目标是力求增加模块的内聚，尽量减少模块间的耦合，但增加内聚比减少耦合更重要，应当把更多的注意力集中到提高模块的内聚程度上来。
自顶向下和自底向上设计
自顶向下
–顶层开始
–逐步分解
由底向上
–选择关键部分先设计
–扩展到整个系统
第五章
数据流图的类型：
变换型结构处理系统和事务型结构处理系统
变换型结构事务型结构
变换分析步骤
事务分析步骤
第一步：
划分DFD图的边界
第二步：
建立初始SC图的框架
●顶层都只含一个用于控制的主模块
●第一层包括传入、传出和中心变换三个模块
第三步：
分解SC图的各个分支
●分解实质上是“映射”
●最后可组成初始SC图
第一步：
在DFD图上确定边界
●事务中心
●接收部分（包括接收路径）
●发送部分（包括全部动作路径）
第二步：
画出SC图框架
●DFD图的三个部分分别映射为事务控制模块，接受模块和动作发送模块
第三步：
分解和细化接收分支和发送分支
优化结构设计的指导规则
•对模块分割、合并和变动调用关系的指导规则
●提高模块独立性（按四项基本原则调整）
●模块大小合适（可脱离DFD图进行调整）
•保持高扇入/低扇出（3-5不超过9）的原则—提高公共（共享）模块的使用率！
•作用域/控制域规则
•模块的控制域是该模块本身以及所有直接或间接从属于它的模块的集合。
（向下控制）
•模块的作用域是该模块内一个判断影响的模块的集合。
（向上作用）
●作用域不要超出控制域的范围
●
位置离受它控制的模块越近越好
伪代码语言（PDL）
•用正文形式表示数据结构和处理过程
•PDL是一种“混合”语言
–具有严格的关键字外部语法
–使用自然语言表示实际操作和判定条件
流程图的规则
第六章
测试的基本概念
测试（testing）的目的与任务
目的：
发现程序的错误
任务：
通过执行程序，暴露潜在的错误
纠错（debugging）的目的与任务
目的：
定位和纠正错误
任务：
消除软件故障，保证程序的可靠运行
软件开发与测试V模型（虚线代表同步进行）
软件测试的原则
1.所有测试的标准都是建立在用户需求之上。
2.基于“质量第一”的思想去开展各项工作
3.事先定义好产品的质量标准。
4.软件项目一启动，软件测试也就是开始
5.穷举测试是不可能的。
6.第三方进行测试会更客观，更有效。
7.测试用例是设计出来的，便于维护和复用
8.测试用例应由输入数据和预期的输出结果两部分组成。
兼顾正向和反向测试，重点是正向
9.对发现错误较多的程序段，应进行更深入的测试
10.程序修改后要回归测试
11.保存好测试用例，直到系统废弃
测试（test）
调试（debug）
发现错误
找到错误位置，排除
有计划
被动的
以已知条件开始，使用预先定义的程序，有预知的结果
以不可知内部条件开始，结果一般不可预见
由代理的测试组，在不了解软件设计的条件下完成
由程序作者进行
静态测试和动态测试：
静态测试：
不实际运行被测试软件，对需求规格说明书，软件设计说明书，源程序审阅和检查
动态测试：
实际运行被测试程序（被测试程序和测试数据[用例]）【预期结果和执行结果的比较】
黑盒测试
白盒测试
定义
在完全不考虑程序内部结构和内部特性的情况下，针对软件界面和软件功能进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用
了解产品内部工作过程，从检查程序的逻辑着手，检验程序中的每条通路是否都有能按预定要求正确工作，通过测试来检测产品内部动作是否按照规格说明书的规定正常进行
测试特点
测试功能
测试程序接口与结构
测试依据
需求规格说明书
软件程序
测试方法
等价类划分,边界值测试，错误推测法
逻辑覆盖
优点
能站在用户的立场上进行测试
能对程序内部特定部位进行覆盖测试
缺点
不能测试程序内部特定部位，如果程序有误，则无法发现
无法检验程序的外部特性
测试目的
1.是否有不正确或遗漏了的功能?
2.在接口上，输入能否正确地接受?
能否输出正确的结果?
3.是否有数据结构错误或外部信息（例如数据文件）访问错误?
4.性能上是否能够满足要求?
5.是否有初始化或终止性错误?
1.对程序模块的所有独立的执行路径至少测试一遍。
2.对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3.在循环的边界和运行的界限内执行循环体。
4.测试内部数据结构的有效性，等等。
白盒测试逻辑覆盖测试方法的五个标准：
发现错误的能力
弱
强
语句覆盖
每个语句至少执行一次
判定覆盖
每一判定的每个分支至少执行一次
条件覆盖
每一判定中的每个条件，分别按“真”、“假”至少各执行一次
判定/条件覆盖
同时满足判定覆盖和条件覆盖的要求
条件组合覆盖
求出判定中所有条件的各种可能组合值，每一可能的条件组合至少执行一次
软件的纠错
纠错的策略
试凑法——设置可疑区，边试边瞧
跟踪法——分步执行,跟踪纠错语句
推理法——归纳、演绎
常用的纠错技术
插入打印语句
设置断点
掩蔽部分程序
蛮力纠错技术
辅助模块概念
驱动模块（driver）
—模拟主程序功能，用于向被测模块传递数据，接收、打印从被测模块返回的数据。
桩模块（stub）
—又称为假模块，用于模拟那些由被测模块所调用的下属模块功能。
桩模块与驱动模块详解：
如下图组件层次结构的例子所示
假设现在只有模块B被编码出来，其余的还在开发中，现在B模块需要开展单元测试。
前提条件分析：
1、B模块不是最顶层模块，不具有main函数，不能独立运行
2、B模块调用了E和F模块，E和F模块还在开发，B模块不能通过编译器编译
那么怎样才能测试B模块呢?
需要做：
1、使B模块通过编译，写桩模块Se和Sf模拟E和F模块的基本功能
2、使B可以运行，写驱动模块Da模拟A模块的功能（带main函数）
集成测试步骤
自顶向下测试
•先广后深实施步骤A-B-C-D-E-F-G
•先深后广实施步骤A-B-E-F-C-D-G
由底向上测试
混合方式测试（sandwichtesting）（三明治）
•对上层模块采取自顶向下测试
•对关键模块或子系统采取由底向上测试
第七章
软件维护的种类
•完善性维护（perfectivemaintenance）
–完善和加强产品的功能与性能，以满足用户日益增长的需要。
50%
•适应性维护（adaptivemaintenance）
–使软件适应运行环境的变化。
25%
•纠错性维护（correctivemaintenance）
–纠正在开发期间未能发现的遗留错误。
21%
•预防性维护（preventivemaintenance）4%
-为进一步改善软件的可靠性和易维护性，或为将来维护奠定更好的基础而对软件进行修改。
修改编码的副作用
修改数据的副作用
修改文档的副作用
修改或删除子程序
局部或全局常量的再定义
文档与程序是软件中不可分的组成部分
修改或删除语句标号
记录或文件格式的再定义
修改或删除标识符
增减数据或其他复杂数据结构的体积
任何对程序的修改，都应该及时反映到有关的文档上
为提高执行效率而做得修改
修改全局数据
修改文件的open，close操作
重新初始化控制标志和指针
修改逻辑操作符
重新排列I/O表或子程序参数表
有设计变动引起的代码修改
修改对边界条件的测试
维护费用估算
计算步骤
M—维护总工作量
P—生产性活动，包括问题分析、修改编码、回归测试等
K—经验常数
C—由未采用结构化方法和文档增加的软件复杂度
D—维护人员对软件的熟悉程度。
1、计算活动比Activityratio
ACT=（修改指令数+增加的指令数）/原指令总数
2、估算维护所需人-月数
3、考虑对软件可靠的重视程度和开发方法质量
增加工作调节因子EAF
第八章
面向对象设计原则
模块化
把系统分解成模块的设计原理
类就是模块、它是把数据结构和对数据的操作紧密地结合在一起所构成的模块
抽象
过程抽象和数据抽象
规格说明抽象：
类（抽象数据类型），用户只需要通过它提供的公共接口（协议）就可以操作，无需了解其内部抽象逻辑结构，因此类的操作对用户是具体的，类内部是抽象的
信息隐藏
通过对象的封装实现对用户来说，类中的属性的表示方法和操作的实现算法是隐藏的。
弱耦合
不同对象之间通过消息相互关联的紧密程度松散
1.降低消息连接的复杂程度。
尽量减少消息中包含的参数个数，降低参数的复杂程度。
2.减少对象发送（或接收）的消息数。
强内聚
单个方法的内聚性
方法是指操作的实现过程，一个操作由一个或多个方法实现。
对方法的内聚性的评价与结构化设计中的相同，具有高内聚的方法应当只执行一个功能。
类的内聚性
设计类的原则是，一个类应该只有一个用途，类中的属性和操作应该全都是完成该类的任务所必需的，其中不包括无用的属性和操作。
如果某个类有多个用途，通常应该把它分解成多个专用的类。
层次结构的内聚性
对象之间通过继承关系而构成的层次结构，特殊类应该确实是对它的一般化类的一种具体化。
如果一个派生类摒弃了它基类的许多属性和服务，那就是一个低内聚的。
可重用
一是尽量使用已有的类（包括开发环境提供的类库，以及以往开发类似系统时创建的类）；
二是如果确实需要创建新类，则在设计这些新类的协议时，考虑将来的可重复使用性
通用模型元素
图示
模型元素
事物
结构事物
类
具有相同属性、方法、关系和语义的对象的抽象
接口
为类或组件提供特定服务的一组操作的集合
协作
元素间交互操作
用例
系统对一个特定角色执行的一系列动作
活动类
类对象有一个或多个进程或线程的类。
在UML中活动类的表示法和类相同，只是边框用粗线条
组件
一个接口集合的物理上可替换的系统部分
节点
运行时存在的一个物理元素
动作事物
交互
一组对象在特定上下文中，为达到某种特定的目的而进行的一系列消息交换组成的动作。
在交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次数（消息产生的动作）、连接（对象之间的连接）。
状态机
状态机由一系列对象的状态组成
分组事物
包
命名控件，文件夹，用来组织图形的封装，定义语意边界，提供配置管理单元
注释事物
UML模型的解释部分
关系
关联关系
连接元素和链接实例
依赖关系
一个元素对另一个元素的依附
泛化关系
继承关系
实现关系
一个元素实现另一个元素
聚合关系
一个表示整体的模型元素可能由几个表示部分的模型元素聚合而成
通用机制
修饰
将图形修饰附加到UML图中的模型元素上。
如当一个元素代表某种类型的时候，它的名称可以用粗体字形类显示；当同一元素表示该类型的实例时，该元素的名称用一条下划线修饰。
（右图带下滑线TescherPerson继承Person）
注释
用一条虚线将注释连接到它为之解释的或细化的元素上
通用划分
升级会员 