软件工程知识点集.docx
《软件工程知识点集.docx》由会员分享，可在线阅读，更多相关《软件工程知识点集.docx（30页珍藏版）》请在冰豆网上搜索。
软件工程知识点集
第一章：
软件工程学概述
软件危机：
是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
软件危机的表现形式：
Ø对软件开发成本和进度的估计常常很不准确；
Ø用户对“已完成的”软件系统不满意的现象经常发生；
Ø软件产品的质量往往靠不住；
Ø软件常常是不可维护的；
Ø软件通常没有适当的文档资料；
Ø软件成本在计算机系统总成本中所占的比例逐年上升；
Ø软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
软件危机的原因：
Ø与软件本身的特点有关（难于维护，逻辑复杂）
Ø与软件开发与维护的方法不正确有关
⏹软件≠程序
⏹急于求成=拔苗助长
⏹各自为阵无方法/学
消除软件危机的途径：
Ø消除“软件就是程序”的错误观念
Ø软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目
Ø成功的软件开发技术和方法
Ø软件工具和软件工程支撑环境
软件=程序+数据+文档
软件工程：
是指导计算机软件开发和维护的一门工程学科。
包含有技术和管理两方面的内容。
软件工程的本质特性：
Ø软件工程关注于大型程序的构造
Ø软件工程的中心课题是控制复杂性
Ø软件经常变化
Ø开发软件的效率非常重要
Ø和谐地合作是开发软件的关键
Ø软件必须有效地支持它的用户
Ø在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品
软件工程方法学三要素：
工具，过程，方法。
Ø软件方法：
完成软件开发的各项任务的技术方法，回答“怎么做”的问题；
Ø软件工具：
为运用方法而提供的自动的或半自动的软件支撑环境；
Ø理论工具：
逐步求精法、成本-效益分析法、软件度量
ØCASE（Computer-AidedSoftwareEngineering）计算机辅助软件工程
Ø软件过程：
为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
传统方法学——强调自顶向下：
Ø传统方法学也称为生命周期方法学或结构化范型
Ø它采用结构化技术（结构化分析、结构化设计和结构化实现）
Ø结构化范型要么面向行为（即对数据的操作），要么面向数据
面向对象方法学——强调主动地多次反复迭代：
把数据和行为看成同等重要，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。
面向对象方法=对象+类+继承+用消息通信
面向对象方法学的优点：
Ø面向对象方法学的尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程。
Ø面向对象方法学开发软件的过程，是一个主动地多次反复迭代的演化过程，保证了在各项开发活动之间的平滑过渡。
Ø促进了软件重用。
降低了复杂性，提高了可理解性，简化了开发和维护工作。
传统方法与面向对象方法比较：
Ø信息隐藏（Informationhiding）
Ø有利用维护软件
Ø使得软件开发变得容易
Ø职责驱动设计或按合同设计
软件生命周期：
由软件定义、软件开发和运行维护（也称为软件维护）三个时期组成，每个时期又进一步划分成若干个阶段。
软件过程：
是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
软件过程模型：
Ø瀑布模型
Ø快速原型模型
Ø增量模型
Ø螺旋模型
Ø喷泉模型
ØRational统一过程
Ø敏捷过程与极限编程
Ø微软过程
瀑布模型的特点：
Ø1.阶段间具有顺序性和依赖性
前一阶段的工作完成之后，才能开始后一阶段的工作；
前一阶段的输出文档就是后一阶段的输入文档。
Ø2.推迟实现的观点
对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长。
Ø3.质量保证的观点
每个阶段都必须完成规定的文档，是“文档驱动”的模型；
每个阶段结束前都要对所完成的文档进行评审，尽早发现问题，改正错误。
瀑布模型的优点：
Ø可强迫开发人员采用规范的方法；
Ø严格地规定了每个阶段必须提交的文档；
Ø要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
瀑布模型的缺点：
Ø只能通过文档了解产品，不经过实践的需求是不切实际的。
瀑布模型适用于：
Ø需求是预知的；
Ø软件实现方法是成熟的；
Ø项目周期较短。
快速原型模型的特点：
Ø快速原型模型不带反馈环，软件产品的开发基本上是线性顺序进行的。
Ø快速原型的本质是“快速”。
应该尽可能快地建造出原型系统，以加速软件开发过程，节约成本。
根据原型的不同作用，有三类原型模型：
Ø探索型原型——用于开发的需求分析阶段
Ø实验型原型——主要用于设计阶段
Ø演化型原型——用于及早向用户提交一个原型系统
比较：
Ø瀑布模型试图一次就获得正确的产品
Ø快速原型频繁变化，然后废弃
增量模型：
把软件产品作为一系列的增量构件来设计、编码、集成和测试。
每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
增量模型优缺点:
Ø优点：
能在较短的时间内，提供可完成部分工作的初步产品给用户；
用户有较为充裕的时间学习和适应新产品。
Ø缺点：
对开发人员技术能力要求较高，要求能从系统整体出发正确划分增量构件，并进行分别开发，最后能很好地集成这些构件。
增量模型适用于：
Ø适用于需求经常改变的软件开发过程。
Ø如果在项目既定的商业要求期限之前不可能找到足够的开发人员，在这种情况下，增量模型显得特别有用。
软件开发总要冒一定风险:
Ø产品交付用户不满意
Ø到交付期产品未完成
Ø成本超预算
Ø产品完成前开发人员跳槽
Ø竞争对手：
价格、功能。
螺旋模型：
将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析。
螺旋模型强调风险分析
螺旋模型的优点：
Ø主要优势在于它是风险驱动的。
Ø对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；
Ø减少了过多测试或测试不足所带来的风险；
Ø维护只是模型的另一个周期，维护和开发之间没有本质区别。
螺旋模型的缺点：
Ø采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
Ø过多的迭代次数会增加开发成本，延迟提交时间。
螺旋模型适用于：
Ø特别适用于庞大、复杂并具有高风险的系统。
Ø适用于内部开发的大规模软件项目。
喷泉模型：
是典型的面向对象生命周期模型。
“喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。
为避免使用喷泉模型开发软件时开发过程过分无序，应该把一个线性过程（例如，快速原型模型或图中的中心垂线）作为总目标。
喷泉模型的优点：
Ø该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。
Ø多次反复地增加或明确目标系统，而不是本质性的改动，降低错误的可能性。
喷泉模型的缺点：
Ø由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，不利于项目的管理。
Ø要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
喷泉模型适用于：
Ø适用于面向对象的软件开发过程。
重构:
Ø提高代码质量，可维护性；
Ø帮助尽早的发现错误；
Ø可以提高开发速度；
微软过程模型:
Ø每一个生命周期发布一个递进的版本，各生命周期持续快速地迭代循环
Ø优点：
综合了Rational统一过程和敏捷过程的优点
Ø缺点：
对方法、工具和产品等方面不够全面
第二章：
软件设计基本概念
步骤：
Ø设想供选择的方案
Ø选取合理的方案
系统流程图
组成系统的物理元素清单
成本/效益分析
实现这个系统的进度计划
Ø推荐最佳方案
Ø功能分解
结构设计
⏹确定程序由哪些模块组成，以及这些模块之间的关系
⏹结构设计是总体设计阶段的任务
过程设计
⏹确定每个模块的处理过程
⏹过程设计是详细设计阶段的任务
Ø设计软件结构
Ø设计数据库
Ø制定测试计划
Ø书写文档
设计原理：
Ø模块化
Ø抽象
Ø逐步求精
Ø信息隐蔽和局部化
Ø模块独立
模块：
是由边界元素限定的相邻程序元素的序列，而且有一个总体标识符代表它。
模块化：
就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求
为什么要模块化？
Ø模块化是为了使一个复杂的大型程序能被人的智力所管理，软件应该具备的惟一属性。
Ø如果一个大型程序仅由一个模块组成，它将很难被人所理解。
评价一种设计方法定义模块能力的五条标准：
Ø模块可分解性
Ø模块可组装性
Ø模块可理解性
Ø模块连续性
Ø模块保护性
模块化的作用：
（了解）
Ø采用模块化原理可以使软件结构清晰，不仅容易设计也容易阅读和理解。
Ø模块化使软件容易测试和调试，因而有助于提高软件的可靠性。
Ø模块化能够提高软件的可修改性。
Ø模块化也有助于软件开发工程的组织管理。
抽象：
现实世界中一定事物、状态或过程之间总存在着某些相似的方面（共性）。
把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。
逐步求精：
为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。
逐步求精是人类解决复杂问题时采用的基本方法，也是许多软件工程技术的基础。
信息隐藏：
应该这样设计和确定模块，使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的。
局部化：
所谓局部化是指把一些关系密切的软件元素物理地放得彼此靠近。
模块独立：
模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果。
模块独立的重要性：
Ø有效的模块化（即具有独立的模块）的软件比较容易开发出来。
Ø独立的模块比较容易测试和维护。
模块独立程度的两个定性标准度量：
Ø耦合：
衡量不同模块彼此间互相依赖（连接）的紧密程度。
耦合要低，即每个模块和其他模块之间的关系要简单；
Ø内聚：
衡量一个模块内部各个元素彼此结合的紧密程度。
内聚要高，每个模块完成一个相对独立的特定子功能。
公共环境耦合（commoncoupling）：
当两个或多个模块通过一个公共数据环境相互作用时，它们之间的耦合称为公共环境耦合。
（类型如下：
）
应该采取下述设计原则：
Ø尽量使用数据耦合，
Ø少用控制耦合和特征耦合，
Ø限制公共环境耦合的范围，完全不用内容耦合。
内聚：
标志一个模块内各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。
简单地说，理想内聚的模块只做一件事情。
Ø偶然内聚（coincidentalcohesion）
Ø逻辑内聚（logicalcohesion）
Ø时间内聚（temporalcohesion）
Ø过程内聚（proceduralcohesion）
Ø通信内聚（communicationalcohesion）
Ø顺序内聚（sequentialcohesion）
Ø功能内聚（functionalcohesion）
内聚程度的度量：
Ø偶然内聚：
解决方案，将模块分成更小的模块，每个小模块执行一个操作。
Ø逻辑内聚：
解决方案，模块分解
Ø时间内聚：
如果一个模块包含的任务必须在同一段时间内执行，就叫时间内聚。
如：
将多个变量的初始化放在同一个模块中实现
Ø过程内聚；解决方案：
分割为单独的模块，每个模块执行一个操作。
Ø通信内聚；解决方案：
分成多个模块，每个模块执行一个操作。
Ø顺序内聚（sequentialcohesion）
Ø功能内聚（functionalcohesion）
软件设计启发规则：
Ø改进软件结构提高模块独立性
Ø模块规模应该适中
Ø深度、宽度、扇出和扇入都应适当
Ø模块的作用域应该在控制域之内
Ø力争降低模块接口的复杂程度
Ø设计单入口单出口的模块
第三章：
详细设计
详细设计阶段的根本目标：
确定应该怎样具体地实现所要求的系统。
结构程序设计：
如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。
结构程序设计是尽可能少用GOTO语句的程序设计方法。
人机界面设计-三条“黄金规则”：
Ø置用户于控制之下。
Ø减少用户记忆负担。
Ø保持界面一致。
设计人机界面过程中会遇到的4个问题：
Ø系统响应时间：
两个重要属性-长度，易变性
Ø响应时间易变性低也有助于用户建立起稳定的工作节奏。
Ø如果系统响应时间过长，用户就会感到紧张和沮丧；系统响应时间过短会迫使用户加快操作节奏，从而可能会犯错误。
Ø用户帮助设施
Ø出错信息处理
Ø命令交互
界面分类：
Ø一般交互界面
Ø信息显示界面：
数据，字符，图形，报告
Ø数据输入界面：
保持信息显示和数据输入的一致性，消除冗余输入
过程设计工具：
1、图形工具，程序流程图，盒图，问题分析图，HIPO图；2、表格工具，判定表，判定树；3、语言工具，过程设计语言。
（a）选择;（b）注释;（c）预处理;（d）多分支;（e）开始和结束;（f）准备;
（g）循环上界限;（h）循环下界限;（i）虚线;（j）省略符;（k）并行方式;
（l）处理;（m）输入输出;（n）连接;（o）换页连接;（p）控制流
程序流程图的主要缺点：
Ø程序流程图本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构。
Ø程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制。
Ø程序流程图不易表示数据结构。
盒图具有下述特点：
Ø功能域明确。
Ø不可能任意转移控制。
Ø很容易确定局部和全程数据的作用域。
Ø很容易表现嵌套关系，也可以表示模块的层次结构。
PAD图的主要优点如下：
Ø使用表示结构化控制结构的PAD符号设计出来的程序必然是结构化程序。
ØPAD图所描绘的程序结构十分清晰。
ØPAD图表现程序逻辑易读、易懂、易记。
Ø容易将PAD图转换成高级语言源程序，这种转换可用软件工具自动完成。
Ø即可表示程序逻辑，也可描绘数据结构。
ØPAD图的符号支持自顶向下、逐步求精方法的使用。
判定树的优点：
Ø它的形式简单，一眼就可以看出其含义，因此易于掌握和使用。
判定树的缺点：
Ø简洁性不如判定表，数据元素的同一个值往往要重复写多遍，而且越接近树的叶端重复次数越多。
Ø画判定树时分枝的次序可能对最终画出的判定树的简洁程度有较大影响。
PDL的优点：
Ø可以作为注释直接插在源程序中间。
有助于保持文档和程序的一致性，提高了文档的质量。
Ø可以使用普通的正文编辑程序或文字处理系统，很方便地完成PDL的书写和编辑工作。
Ø已经有自动处理程序存在，而且可以自动由PDL生成程序代码。
PDL的缺点：
Ø不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时，不如判定表清晰简单。
Jackson图的优点：
Ø便于表示层次结构，而且是对结构进行自顶向下分解的有力工具；
Ø形象直观可读性好；
Ø既能表示数据结构也能表示程序结构。
Jackson图的缺点：
Ø表示选择或重复结构时，选择条件或循环结束条件不能直接在图上表示出来，影响了图的表达能力，也不易直接把图翻译成程序；
Ø框间连线为斜线，不易在行式打印机上输出。
Jackson图：
用伪码表示程序：
注：
PPT101——例3
定量度量程序复杂程度的作用：
Ø把程序的复杂程度乘以适当常数即可估算出软件中错误的数量以及软件开发需要用的工作量；
Ø定量度量的结果可以用来比较两个不同的设计或两个不同算法的优劣；
Ø程序的定量的复杂程度可以作为模块规模的精确限度。
McCabe方法是一种软件质量度量方法，它是基于对程序拓扑结构复杂度的分析。
顺序结构：
选择结构：
循环结构：
环形复杂度的用途
Ø定量度量程序内分支数或循环个数，即程序结构的复杂程度；
Ø定量度量测试难度；
Ø能对软件最终的可靠性给出某种预测。
Ø实践表明，模块规模以V（G）≤10为宜。
●Halstead方法根据程序中运算符和操作数（变量和常量）的总数来度量程序的复杂程度。
●令N1为程序中运算符出现的总次数，N2为操作数出现的总次数，程序长度N定义为：
N=N1+N2
程序中使用的不同运算符（包括关键字）的个数n1，以及不同操作数（变量和常数）的个数n2。
预测程序长度的公式如下：
H=n1log2n1+n2log2n2
预测程序中包含错误的个数的公式如下：
E=Nlog2（n1+n2）/3000
（这个应该不会考很难）
第四章：
软件编码
注释分为序言性注释和功能性注释；
序言性注释应置于每个模块的起始部分，主要内容有：
Ø说明每个模块的用途、功能。
Ø说明模块的接口：
调用形式、参数描述及从属模块的清单。
Ø数据描述：
重要数据的名称、用途、限制、约束及其他信息。
Ø开发历史：
设计者、审阅者姓名及日期，修改说明及日期。
注释基本原则：
Ø注释应该增加代码的清晰度。
代码注释的目的是要使代码更易于被其他开发人员等理解。
Ø避免使用装饰性内容。
Ø保持注释的简洁。
Ø注释信息不仅要包括代码的功能，还应给出原因。
Ø不要为注释而注释。
Ø除变量定义等较短语句的注释可用行尾注释外，其他注释当避免使用行尾注释。
文件注释：
在每个文件的头部都应该包含该文件的功能、作用、作者、版权以及创建、修改记录等。
类、接口注释：
在类、接口定义之前当对其进行注释，包括类、接口的目的、作用、功能、继承于何种父类，实现的接口、实现的算法、使用方法、示例程序等。
方法注释：
Ø明确该方法功能、作用、各参数含义以及返回值等。
Ø参数注释时当注明其取值范围等。
Ø返回值当注释出失败、错误、异常时的返回情况。
Ø异常当注释出什么情况、什么时候、什么条件下会引发什么样的异常
版本控制的基本操作：
Ø1检入（Checkin）
Ø2检出（Checkout）
Ø3更新（Update）
Ø4同步（Synchronization）
版本控制好处：
Ø便于团队代码共享
Ø保证整个团队使用统一的代码版本
Ø能获得版本控制工具中保存的任何版本
Ø能够把出错或误操作的最新版的项目恢复到正确的历史版本
Ø快速的集成
第五章：
软件测试
什么是软件测试：
是为了发现错误而执行程序的过程。
发现错误是为了更正错误，最终得到一个高质量的软件系统。
软件测试的对象：
整个软件定义、开发周期的产品.软件测试不等于程序测试；它包括程序测试和文档测试。
测试用例：
通常指测试数据和预期的输出结果
注意：
测试不能表明软件中不存在错误，它只能说明软件中存在错误。
软件测试的准则：
Ø所有测试都能追溯到用户需求
Ø应该远在测试开始之前就制定出测试计划
Ø应该把Pareto原理（又叫80/20定律）应用到软件测试中。
Ø从“小规模”测试开始，逐步过渡到“大规模”测试
Ø穷举测试是不可能的
测试只能证明程序有错，不能证明程序没有错误
Ø应由独立的第三方从事测试工作
测试的方法：
静态测试和动态测试，动态测试有黑盒法，白盒法；
注：
黑盒（5亿年）和白盒（3170年）法两者都不可能实现穷尽测试；
测试的4个步骤：
Ø单元（模块）测试
目的：
发现模块内部可能存在的差错
依据：
详细设计说明书和源程序清单
方法：
白盒测试为主，黑盒测试为辅，多个模块并行进行
Ø集成测试（子系统和系统测试）
Ø确认（验收）测试
Ø平行（系统）测试
第六章：
软件的维护
软件维护：
就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
可分为4项活动：
Ø改正性维护（占有17%-21%）
Ø适应性维护（占有18%-25%）（包含外部环境和数据环境）
Ø完善性维护（占有50%-66%）（包含功能和性能的要求）
Ø预防性维护（占有4%左右）
影响维护工作量的因素：
Ø系统规模
Ø开发工具和平台
Ø系统年龄
Ø数据库技术的应用
Ø先进的软件开发技术
Ø其它：
应用的类型、数学模型、任务的难度。
Ø许多软件在开发时并未考虑将来的修改，为软件的维护带来许多问题，是影响软件维护工作量的最主要因素。
软件维护的策略：
Ø改正性维护：
通常要生成100％可靠的软件并不一定合算，成本太高。
但通过使用新技术，可大大减少进行改正性维护的需要。
Ø适应性维护：
这一类维护不可避免，可以控制。
Ø完善性维护：
用前两类维护中列举的方法，也可以减少这一类维护。
软件维护的特点：
非结构化维护，结构化维护。
维护过程：
本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。
软件的可维护性定性地定义为：
维护人员理解、改正、改动或改进这个软件的难易程度。
提高可维护性是支配软件工程方法学所有步骤的关键目标。
决定软件可维护性的因素主要有7个：
Ø可理解性
Ø可测试性
Ø可修改性
Ø可靠性
Ø可移植性
Ø可使用性
Ø效率
提高可维护性的方法：
、
Ø建立明确的软件质量目标和优先级
Ø使用提高软件质量的技术和工具
Ø进行明确的质量保证审查
Ø选择可维护的程序设计语言
Ø改进程序的文档
软件再工程过程模型所定义的6类活动
1.库存目录分析
2.文档重构
3.逆向工程
4.代码重构
5.数据重构
6.正向工程
第六章-小结
Ø软件维护的4类活动
（改正性、适应性、完善性、预防性）
Ø决定软件可维护性的基本要素
（可理解、可测试、可修改、可移植和可重用性）
Ø文档是影响软件可维护性的决定因素
Ø软件再工程（预防性维护）
升级会员 