软件工程复习提纲Word文件下载.docx
《软件工程复习提纲Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件工程复习提纲Word文件下载.docx（33页珍藏版）》请在冰点文库上搜索。
初步的项目开发计划
（2）需求分析
为了解决这个问题，目标系统必须做什么
软件需求规格说明书
（3）总体（概要）设计
概括地说，应该怎样实现目标系统
概要设计规格说明书
数据库或数据结构设计说明书
集成测试计划
（4）详细设计
应该怎样具体地实现这个系统
详细设计规格说明书
单元测试计划
（5）实现
写出正确的容易理解、容易维护的程序模块
源程序代码
（6）集成测试
根据概要设计规格说明书，将经过单元测试的模块逐步进行集成和测试
生成满足概要设计要求、可运行的系统源程序和系统集成测试报告
（7）确认测试
根据软件需求规格说明书，测试软件系统是否满足用户的需求
可供用户使用的软件产品（文档，源程序）
（8）使用和维护
通过各种必要的维护活动使系统持久地满足用户的需要
版本更新的软件产品
2.需求分析的定义。
–确定用户对待开发软件系统的需求包括：
•功能
•性能
•运行环境约束
3.典型的软件开发过程模型的特点（优缺点）及要求，特别是原型法、瀑布模型、增量和迭代等
（1）瀑布模型：
需求分析->
系统设计->
程序设计->
编码->
单元测试和集成测试->
系统测试->
验收测试->
运行和维护；
优点：
采用规范的方法；
严格规定每个阶段提交的文档；
要求每个阶段交出的产品必须经过验证；
缺点：
对如何处理开发中产品和活动的变化没有提供相关的指导
•将软件开发视为制造而不是创造
•创造一个产品没有迭代的活动
•需要等待很长时间
（2）V模型：
•用单元测试验证程序设计
•用系统测试验证系统设计
•用验收测试验证需求
•如果在验证和确认过程中发现了问题，那么在再次执行右边的测试步骤之前，重新执行左边的步骤以修正左边
（3）原型化模型：
•允许需求或设计反复调查
•减少开发中的风险和不确定性
•
•原型模型存在的问题
•⑴为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。
•⑵为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。
•⑶开发过程不便于管理。
（3）增量开发:
先定义一个小的功能子系统，再在每个新的发布中增加新功能
迭代开发:
一开始就提交完整的系统，再在每一个新的发布中改变每个子系统的功能
•减少循环时间
•系统一部分一部分地交付
•两个系统功能可以并行
4.原型法的特点以及分类：
探索型原型、实验型原型和演化型
原型法定义
原型法是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。
反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。
•演化型原型
–不仅帮我们回答问题，而且还要演变为最终产品
–原型必须展现最终产品的质量需求，并且这些质量的要求不能改进
5.极限编程的特点
–交流:
保持客户和开发者的交换看法
–简单性:
选择简单设计和实现
–勇气:
尽早并经常性交付功能（敢于承诺并信守诺言）
–反馈:
开发过程中各种活动循环
第三章
v1.了解项目计划和管理的主要内容和常用的方法。
vPpt71到81
v2.软件可行性研究的内容。
v技术、经济、操作、社会四个可行性
v3.估算工作量的主要方法：
代码行、任务分解技术、自动估算成本技术。
v1）代码行技术
v软件成本=每行代码的平均成本×
估计的源代码总行数
估算方法：
•由多名有经验的软件工程师分别做出估计。
•每个人都估计程序的最小规模（a）、最大规模（b）和最可能的规模（m），
•分别算出这3种规模的平均值、和之后，再用下式计算程序规模的估计值：
•L=（a的平均值+4*m的平均值+b的平均值）/6
单位：
LOC或KLOC。
代码行技术的优点：
•代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数；
•有大量参考文献和数据。
代码行技术的缺点：
•源程序仅是软件配置的一个成分，由源程序度量软件规模不太合理；
•用不同语言实现同一个软件所需要的代码行数并不相同；
•不适用于非过程性语言。
•2）任务分解技术
•软件开发项目分解为若干个相对独立的任务，分别估计每个单独任务的成本：
•单独任务成本=任务所需人力估计值×
每人每月平均工资；
•软件开发项目总成本估计=各个单独任务成本估计值之和。
•3）自动估计成本技术
采用自动估计成本的软件工具估计
第四章
v1.了解需求的重要性及需求分析阶段的主要产物。
v如果开发过程的早期没有检测到并修复需求错误，那么会造成很高的代价，甚至使项目失败。
v产物：
v2.需求的类型：
功能需求、非功能需求或质量需求、设计约束、过程约束。
v功能需求:
根据要求的活动描述需求行为
v质量需求或非功能需求:
描述软件必须拥有的质量特征
v设计约束:
已经做出的设计决策或对问题解决方案集的限制的设计决策
v过程约束:
对用于构建系统的技术和资源的限制
v3.两种需求文档：
需求定义文档和需求规格说明书。
v需求定义:
用户想要得到的每一件事情的完整列表。
v描述打算构建的系统将要安装的环境中的实体
v需求规格说明:
将需求重新陈述为关于要构建的系统将如何运转的规格说明
v4.需求规格说明书的主要内容。
v详细描述输入和输出，包括
v输入的源
v输出的目的地,
v有效范围
v输入输出的数据格式
v数据协议
v窗口格式和组织
v计时约束
v根据接口的输入输出重新陈述要求的功能
v对用户的质量需求，设计适配标准
v5.常用的需求建模表示方法：
ER图、事件跟踪、状态机、Petri网、数据流图、用例图和原型法。
vER图：
v一种表示概念模型的流行图形表示法
v三个核心结构
v实体:
表示为矩形，代表具有共同性质和行为的现实世界对象构成的集合
v关系:
表示为两个实体之间的边，边中间有一个菱形，表示关系的类型
属性:
是实体的注释，描述实体相关的数据或性质
事件跟踪：
•关于现实世界实体之间交换的时间序列的图形描述
–垂直线:
不同实体的时间线，其名字出现在线的顶部
–水平线:
两个实体之间的一个事件或交互
–时间按从顶到下跟踪进展
•每一个图描述一个跟踪，表示只是若干个可能行为中的一个
•事件跟踪语义相对简单，易于理解
•
状态机：
•是一种图形描述，描述了系统与其环境之间的所有对话
–点（状态）表示存在于事件发生之间的一个稳定的条件集合
–边（转移）表示由于一个事件的发生而产生的行为或条件的变化
•在表示动态行为方面，以及在描述在响应已经发生的历史事件时行为将如何变化方面很有用
Petri网:
•Petri网是状态-转移表示法的一种形式，用于建模并发活动以及他们之间的交互。
•圆圈：
位置
•条：
变迁
•弧：
箭头
•点：
令牌
数据流图:
•数据流图（DFD）建模功能以及从一个功能到另一个功能数据流
–一个泡泡表示：
一个加工
–箭头表示：
数据流
–平行线：
数据存储:
正式的库或信息库
–矩形：
表示参与者:
提供输入数据或接受输出的实体
用例图:
•构成
–大的方框:
系统边界
–方框外的小人:
参与者，人或者系统
–方框内的椭圆:
用例，表示必须的主要功能及其变种
–参与者和用例之间的线:
参与者参与了该用例
•用例不一定建模系统应该提供的所有任务，而是用于说明用户对重要系统行为的观察
v6.
v
（1）UML的作用：
是为软件系统的制品进行描述（specifying）、可视化（visualizing）、构造（constructing）、文档化（documenting）的一种语言。
v
（2）UML中的4＋1视图：
用例视图，设计视图，进程视图，实现视图，分布视图。
v（3）UML中的三种扩展机制
▪构造型Stereotype,标记值taggedvalue,约束contraint.
▪
v（4）UML中所包含的10种图形及各自的作用。
v（5）用例图的作用。
v用例图用来描述软件需求模型中的系统功能，通过一组用例可以描述软件系统能够给用户提供的功能。
v用例图可以作为整个系统开发过程中的开发依据，指导和驱动其他模型。
v（6）用例图的主要构成部分。
v执行者、系统边界和用例
第五章
5.获取需求
•概念设计：
告诉客户系统将做什么
数据来自哪里?
系统中数据会发生什么情况?
对用户来说，系统将会是什么?
向用户提供的选择是什么?
事件的计时是什么?
报表和屏幕是什么样的?
）
•技术设计：
告诉变成这系统将做什么
对主要硬件部分及其功能的描述软件构件的层次和功能数据结构数据流
好设计的衡量：
耦合和内聚
耦合度：
•高度耦合：
当两个构件之间有大量依赖关系的时候
•松散耦合：
当两个构件具有某种程度的依赖，但他们之间的相互连接比较弱
•非耦合：
构件之间不存在相互连接
耦合度的类型：
•内容耦合：
当一个构件修改了另一个构件的内部数据项时，或一个构件内的分支转移到另外一个构件中的时候，可能出现内容耦合
•公共耦合：
对公共数据的改变意味着需要通过反向跟踪所有访问过该数据的构件来评估该改变的影响
•控制耦合
•标记耦合
•数据耦合
•内聚：
如果构件的所有元素都是直接面向执行同一个任务的并且必须的，那么该构件是内聚的
6.细述对象
1.OOM中的典型特征，其中特别是封装、继承和多态。
•标识
•抽象
•分类
•封装
•继承
•多态
•持久性
•对象的概念：
对象是指某个事物，大多对应于真实世界中的某个客观实体；
但有些对象在真实世界中没有直接的对应物，是人们对某个事物的一种抽象描述。
对象的基本特征可以归纳为对象的属性和行为两类。
类的概念：
类是指对一组具有相同特征的对象的抽象描述；
任何对象都是某个类的实例。
类图的作用：
类图技术是OO方法的核心技术，应用非常广泛，其中类、对象以及它们之间的关系是最基本的建模元素。
类模型和对象模型揭示了系统的结构。
2.了解类之间的各种关系：
关联、依赖、继承或泛化、组合/聚合等。
v关联用来表示来表示两个（或多个）类的对象之间的结构关系，它在代码中表现为一个类以属性的形式包含对另一个类的一个或多个对象的引用。
v泛化关系：
（继承关系）定义类和包之间的一般元素和特殊元素之间的分类关系。
v继承（Inheritance）:
泛化关系的一种实现机制
并非所有的泛化关系都适合用继承关系实现
v聚合：
是表示类和类之间的“整体－部分”关系，用空心菱形表示。
聚合表示类之间的整体与部分的关系。
聚合意味着一个类拥有但共享另一个类的对象
组合是聚合的一种特殊情形，用实心菱形表示。
与聚合相比，它有两个特点：
1.一个部分类最多只能属于一个整体类
2.当整体类不存在时，部分类将同时被销毁。
3.了解类图的基本建模步骤。
v
（1）寻找出需求中的名词（候选对象）。
v
（2）合并含义相同的名词，排除范围以外的名词，并寻找隐含的名词。
v（3）去掉只能作为类属性的名词。
v（4）剩下的名词就是要找的分析类（候选类）。
v（5）根据常识、问题域、系统责任确定该类有那些属性。
v（6）补充该类动态属性，如状态、对象间联系（如聚合、关联）等属性。
v（7）从需求中的动词、功能或系统责任中寻找类的操作（候选操作）。
4.接口和抽象类的定义及各自的特点。
v抽象类是指那些不具有任何对象的类，其作用是为其他的类描述它们的公共属性和行为。
通常，抽象类具有一组抽象操作。
一个拥有至少一个抽象操作的类必定是一个抽象类。
v接口是一组没有实现的操作的集合。
接口只提供操作的声明，不提供任何相应的功能代码。
具体的功能代码由使用该接口的类实现，这叫作实现关系。
一个类和一个接口不同：
一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。
5.交互图的分类：
顺序图和协作图。
这两种图形各自的优缺点。
注意UML2.0中协作图改称通信图。
▪序列图主要用来描述对象之间信息交换时的时间顺序，它强调的是消息发送的时间的先后顺序
▪而协作图则用来描述系统对象之间如何协作共同完成系统功能的要求。
协作图描述对象之间消息的连接关系，侧重说明哪些对象之间有消息传递。
与序列图相比，通过编号来看消息的执行顺序比较困难，但协作图中对象间灵活的空间布局可以更方便地展示动态连接关系等有用信息。
▪序列图和协作图都属于交互图,用来描述对象之间的动态关系。
▪序列图强调消息的时间顺序，协作图强调参与交互的对象的组织关系。
▪序列图和协作图在语义上是等价的，两者可以相互转换。
▪相同点：
▪1.它们都表现出了对象之间的交互信息。
▪2.两个图对象的绘制方式相同
▪不同点：
▪1.顺序图反映了对象之间交互的时间关系，而通信图反映了对象之间交互的空间关系。
▪2.顺序图用于展示特定的业务场景，而通信图用来展示详细的业务过程。
▪3.顺序图的对象在图形的顶部一字排开，而通信图对象的摆放位置在二维空间只要选择合适的位置即可。
▪4.通信图不能表现组合片段。
6.状态图和活动图各自的作用。
注意活动图中泳道的作用。
v状态图：
描述交互对对象内部的影响，交互图中的消息在这里变成外部事件对对象发出的命令，对象对这些命令的响应导致对象的状态发生变化。
因此，从这个意义上说，状态图是顺序图的进一步细化，并且是对核心对象（选择核心对象的依据是看是否在多个交互图中有多个消息指向该对象）的细化。
v活动图是一种特殊形式的状态机，用于对计算流程和工作流程建模.
v与交互图相比：
活动图着重表现活动的控制流，描述在对象之间传递的操作；
交互图着重表现的是对象到对象的控制流，描述在对象之间传递的消息
v泳道是活动图里对其中的活动按照其职责上的关联进行的划分。
泳道在活动图内是一系列的垂直的隔断（这也是泳道这个名字的由来）
7.组件图的作用以及组件与接口间的关系。
组件是系统的一个物理的和可替代的组成部分，该组成部分遵循并实现了一组给定的接口。
组件属于实现视图
8.部署图的作用。
用来描述软件产品在计算机硬件系统和网络上的
-安装
-分发（delivery）
-分布（distribution）
1.主要的面向对象设计原则及各自的原理：
设计原则名称
简介
重要性
里氏替换原则LSP
任意父类可以出现的地方，子类也可以出现
开闭原则OCP
对扩展开发，对修改关闭
单一职责原则SRP
类的职责单一
依赖倒转原则DIP
针对抽象（或接口）编程，而不针对具体编程
接口隔离原则ISP
使用多个专门接口要优于使用单一的接口
组合聚合原则CRP
优先使用组合或聚合关系，不要过于使用继承关系
迪米特原则LoD
一个软件实体对其他实体的引用越少越好。
2.LSP中的子类型与继承的关系及区别。
▪软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的
▪特征：
对于扩展是开放的（Openforextension）：
模块的行为可以扩展，当应用的需求改变时，可以对模块进行扩展，以满足新的需求
对于更改是封闭的（Closedformodification）：
对模块行为扩展时，不必改动模块的源代码或二进制代码
开闭原则的思想及关键。
OCP（TheOpen-ClosePrinciple,开放-封闭原则）
软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的
特征：
4.设计模式的分类。
创建型结构型行为型
5.设计模式与面向对象设计原则之间的关系，特别是OCP原则。
6.掌握各种工厂模式的设计思想及其原理，了解如何从OCP的角度进行分析。
//蓝色的字指的是ppt上没有的问题。
黄色是了解内容
7.编写程序
1.注意编程程序过程中应遵循一定的标准和过程。
对单个开发人员的标准
编写代码文档的方法
对其他开发人员的标准
集成人员,维护人员,测试人员
文档序言
对代码分析的自动化工具
设计和实现的匹配
低耦合,高内聚,定义明确的接口
2.了解一些编程指导原则。
●控制结构
使程序容易阅读
根据模块化的块来构建程序
不要让代码太过特殊，也不要太过普通
用参数名和注释来展现构件之间的耦合度
构件之间的关系必须是可见的
●算法
重点关注:
性能
效率可能会伴随着一些隐藏的代价
编写更快代码的代价
测试代码的代价
用户理解代码的代价
修改代码的代价
●数据结构
有几种使用数据结构的技术提出应该怎样对程序进行组织
保持程序简单
用数据结构来决定程序结构
●保持程序简单（continued）
⏹通用性指导原则
局部化输入和输出
包含伪代码
改正和重写，而不是打补丁
复用
生产者复用:
在设计的构建要在以后的应用中进行复用
消费者复用:
正在使用的构件是原先为其他项目开发的构件
3.注意实现容错技术的主要手段是冗余，冗余通常分为四类:
（1）结构冗余。
（2）信息冗余（3）时间冗余和（4）冗余附加技术。
4.软件中的注释主要分：
序言性注释和功能性注释两种。
8.测试程序和9.测试系统
1.测试的目标和衡量标准。
测试目标:
发现错误
只有当发现了错误时，测试才被认为是成功的
故障识别是确定由哪一个故障或哪些故障引起失效的过程
故障改正是修改系统使得故障得以去除过程
2.测试的分类（或组织）。
各种类型的测试的主要任务及所依赖的文档。
模块测试、构件测试、单元测试
集成测试
功能测试
性能测试
验收测试
安装测试
Alpha测试
Beta测试
3.黑盒测试和白盒测试的思想，了解白盒测试中的基本路径测试等方法。
闭盒或黑盒:
测试对象的功能
开盒或白盒:
测试对象的结构
黑盒优点
免于受强加给测试对象内部结构和逻辑的约束
缺点
不可能总是进行完备的测试
4.单元测试的主要内容。
检查代码
代码走查
代码审查
典型的审查准备时间和会议时间
错误发现率
证明代码的正确性
形式化证明技术
符号执行
自动定理证明
测试与证明
证明:
在假设环境下
测试:
实际操作环境下运转的相关信息
选择测试用例的步骤
确定测试目标
选择测试用例
定义测试
测试的完全性
语句测试
分支测试
路径测试
定义使用的路径测试
所有使用的测试
所有谓词使用/部分计算使用的测试
所有计算使用/部分谓词使用的测试
5.集成测试的类型及主要的测试策略。
自底向上的测试
自顶向下测试
一次性测试
三明治测试
改进的自顶向下测试:
进行合并之前每一个层的构件进行单独测试
改进的三明治测试:
允许在将较上层的构件和其他构件合并前，先对这些较上层的构件进行测试
6.了解测试计划的主要内容。
计划的目的
构建测试目标
设计测试用例
编写测试用例
测试测试用例
执行测试
评估测试结果
计划的内容
测试的目标是什么
怎样进行测试
用什么标准确定何时测试完成
7.测试系统中的测试过程：
功能测试、性能测试、验收（或确认）测试、安装测试，及它们的内容。
功能测试:
集成系统是否按照需求规格说明执行它的功能?
性能测试:
是否满足非功能需求?
验收测试:
系统是客户期望的吗？
安装测试:
系统能在客户端运行吗?
11.系统维护
1.维护活动的类型：
改正性、适应性、完善性、预防性。
2.各种维护活动的主要内容和目标。
改正性:
维护对日常的系统功能的控制
适应性:
维护对系统修改的控制
完善性:
完善现有系统
预防性:
防止系统性能下降到不可接受的程度
3.软件再生：
文档重构、重组、逆向工程、再工程，以及它们各自的内容和含义。
文档重构:
对原代码进行
升级会员 