软件工程复习提纲Word下载.docx

软件工程复习提纲Word下载.docx

《软件工程复习提纲Word下载.docx》由会员分享，可在线阅读，更多相关《软件工程复习提纲Word下载.docx（18页珍藏版）》请在冰点文库上搜索。

这种模型在科学计算、嵌入式和实时控制软件中使用很好，但在商业数据处理等软件中却不适用

2.5原型开发模型：

2.5.1原型开发的实质

就是允许失败。

即人类不论在开发实践活动中如何小心谨慎，也不论所使用的技术和工具多么好，仍不可能经一次努力就能开发出完

全正确的软件。

实际上，原型是确定需求的一种机制

2.5.2原型开发的方法

借鉴硬件工程的方法，在项目的早期尽快生产出一个简化（主要功能和用户界面）且便宜的可运行软件版本，作为用户和开发人员学习和评价一种系统

2.5.3原型开发存在的问题

为了快和省，原型版本经常采用一些折衷的解决方法，所以质量问题较多

原型版本只是一个临时版本，用户并不了解

2.6瀑布模型和原型开发模型的区别：

2.6.1瀑布模型

优点：

方法规范，每个阶段质量可保证，每个阶段归定的文档使错误得到及早发现和处理，容易维护

缺点：

靠文档驱动，用户不能全面地认识动态的软件产品。

且过于理想化，可能出现设计上的错误。

适用范围：

完全定义好了需求，而且没有时间压力的系统。

2.6.2原型模型

开发后期不会因为发现了规格说明文档的错误而进行较大的返工。

在设计和编码段发生错误可能性比较小。

开发者常常需要实现上的折衷，以使原型能够尽快工作。

用户看到的并不是软件的工作版本

用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；

开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式

2.7CASE（计算机辅助软件工程）：

CASE即ComputerAidedSoftwareEngineering，中文意思是计算机辅助软件工程。

CASE是一套方法和工具，可使系统开发商规定的应用规则，并由计算机自动生成合适的计算机程序。

（与软件重用相关的主要研究内容：

可重用软件构件的获取、描述、分类、存储；

可重用构件的检索、提取、组装；

可重用构件的测试和度量。

）

3.1需求分析的意义：

完全弄清用户软件需求是任何一项软件开发工作成功的前提和基础

3.2需求分析的作用：

是系统层软件配置与软件设计之间的桥梁

能够刻画软件的功能和性能

确定软件与其他系统元素（硬/软件和人）的接口

建立软件必须满足的约束

3.3数据流图（DFD）：

描述信息流和数据流从输入到输出变换的应用图像技术

3.3.1：

三层数据流图的原则：

0层数据流图，应当把系统或软件作为一个单一的圆圈来描绘

应当格外注意原始输入和原始输出

过程的下层细化，一般应控制在3-4个分过程，最多不应超过7个

过程（圆圈）和数据流（箭头）应用有意义的名称标注。

在同一DFD中，一个名称标注只能出现一次

必须保持层到层之间I/O信息流的连续性

最好一次只对一个过程细化；

一个过程的细化，一般应细化到最小处理为止

一个系统给出DFD的同时，还应开发一个与之对应的DD

在开发DFD和DD中，有时还需要给出辅助说明

注：

在Yourdon方法中方框表示外部实体；

圆圈表示过程；

箭头表示数据项；

双杠表示数据存储。

3.4数据字典（DD）：

有组织的方式来表示每个数据对象和控制特性。

实例：

一个简化的机票销售系统

需求

售票员根据旅客需要的航班，首先查询有无该航班机票。

若有，则负责录入旅客的基本信息（姓名、身份证号码、航班号、票价和到达港）；

保险公司的服务员负责录入保险金额；

售票部经理可随时查询每一个航班的售票情况（航班号、售出机票的数量及营业额），并在当日结算时能计算出日营业额

给出该系统的DFD和DD

顶层DFD（0层）

二层DFD（1层）

三层DFD-1（2层-1）

三层DFD-2（2层-2）

数据字典：

1.文件

1）文件名：

旅客基本信息

组成：

{姓名+身份证号码+航班号+票价+到达港+保险金额}

组织：

按售票先后顺序

2）文件名：

机票销售信息

{航班号+座位数+售出机票数}

按航班号、离港时间的先后顺序排序

2.数据流

1）数据流名：

｛姓名+身份证号码+航班号+票价+到达港+保险金额｝

2）数据流名：

各航班售票信息

｛航班号+座位数+售出机票数｝

3.数据项

1）数据项名：

姓名

值：

字符串

2）数据项名：

身份证

1-17位为数字，18位为校验位，值为0-9、X

3）数据项名：

航班号

前两位为汉语拼音字母＋后四位方数字

4）数据项名：

保险金额

﹝20｜40｜60｜…｜200﹞

4.处理名

1）处理名：

录入保险金额

编号：

1.4

输入：

保险级别

输出：

过程：

保险服务员根据每位旅客的要求，输入保险级别，系统按照保险金额规定的标准，录入旅客保险金额

触发条件：

接到服务员输入旅客姓名和保险金额级别

3.5模块的独立性：

模块化、抽象和信息隐藏概念的产物；

通过开发具有单一功能和与其他模块没有过多交互作用的模块来达到的；

可用聚合（Cohesion）和耦合（Coupling）两个定量准则来度量（measurement）；

（注：

聚合是模块功能相对强度的量度（metrics）；

耦合是模块之间相对独立性的量度；

两者相互关联。

在一个系统中一个高，另一个就低）

3.6数据流（根据问题域的数据流定义一组不同的映射，把问题域的数据流转换为问题解的程序结构）分类：

变换流和事物流

3.7数据流到程序结构的转换要经过以下5个步骤：

（1）确定数据流的类型

（2）说明数据流的边界

（3）把DFD映射为程序结构

（4）根据元素的分解,定义控制的层次

（5）使用设计度量和试探法（heuristics），对产生的结构进行细化和求精

3.8PDL（过程设计语言）：

PDL是混杂型语言，它采用某种语言的词汇，同时采用另一种语言的全部语法。

PDL与真正的高级语言的不同之处在于，它把说明性文字直接嵌入到PDL语句中去。

3.9结构化程序设计中的三种结构：

顺序（Sequence）、条件（Condition）、重复（Repetition）

3.10软件设计的内容：

数据、体系结构、流程设计******

4.1面向对象方法要点：

数据的抽象，即类与子类的概念及相互关系

数据及对它的操作的一体化，即封装的概念与方法

属性与操作由父类向子类传递，即继承的概念与方法

客观事物之间的相互关系用统一的、消息传递的方法来描述

4.2面向对象分析（OOA）：

OOA的目标是建立系统模型，这些模型元素来自问题域

1.确定对象（客观事物实体的抽象）

2.确定结构（通用和专门、整体和部分）

3.定义主题（对象和结构的“摘要”）

4.定义属性和实例联系

5.定义操作和消息联系

确定问题空间的对象

4.2.1可能的对象

外部实体、实际物体、事件

角色、组织单位、场所、结构

采用的方法和步骤

对要建立的系统进行描述

对描述进行词法分析，在每个名词或名词短语下面画横线

将这些名词或名词短语填入一张简单的表中

用选择特性考察表中的潜在对象

最后对能满足特性要求的潜在对象作出抉择

4.2.2类：

具有共同属性、共同操作的对象的集合。

4.3UML中的五种结构视图：

类图（classdiagram）

展示一组对象、接口、协作和它们之间的关系

对象图objectdiagram）

展示一组对象,以及它们之间的关系。

对象是类图的实例

包图（packagediagram）

由类或包组成,展示系统的分层结构

构件图（componentdiagram）

是对OO系统的物理方面进行建模时用到的，它展示一组构件之间的组织及其依赖关系

实施图（deploymentdiagram）

展示系统运行时进行处理的结点和在结点上的活动构件的配置

行为视图：

用例图（usecasediagram）

展示一组用例、参与者，以及它们之间的关系

顺序图（sequencediagram）

展示一种交互，它由一组对象和它们之间的关系组成,包括在它们之间可能发送的消息

协作图（collaborationdiagram）

也是一种交互图。

它强调收发消息的对象的结构组织（上下级关系），顺序图则强调消息的时间顺序

状态图（statediagram）

也是一种动态视图，展示了一个状态机；

主要用于对象在其生存期中可能经历的状态,以及在这些状态上对事件响应的能力

活动图（activitydiagram）

是一种特殊的状态图，展示了系统从一个活动到另一个活动可能的路径及判定条件

4.4用例图：

展示一组用例、参与者、系统边界及它们之间的关系

它用于对一个系统的用例视图建模

在多数情况下，用例图用于包括系统、子系统或类的语境建模，或为这些元素的行为需求建模

通常包括用例、参与者、系统边界、关联、泛化和依赖关系。

还可以包括注释和约束

4.4.1绘制：

用例：

一个用例代表一个系统或系统的一部分的行为，是对一组动作序列的描述。

系统执行该动作序列可为参与者产生一个可观察的结果值

用例与参与者：

一个参与者表示用例的使用者在与这些用例进行交互时所扮演的角色。

通常,一个参与者代表的角色,可以是人、硬件设备,甚至是另一个系统

用例与事件流：

一个事件流说明一个用例的行为,可以用非形化的结构化文字描述，也可使用形式化的结构化文字描述

4.5类图绘制：

展示了一组类、接口、协作和它们之间的关系

通常包含以下4项内容

类：

是对一组具有相同属性、操作、关系和语义的对象的描述

接口：

接口是一组用于详述类或构件的一个服务的操作。

是一个被命名的操作集合。

关系：

用不同种类的线段区分多个类之间的不同关系

协作：

是一组类、接口和其他元素的群体，提供比各组成部分功能总和更强的合作行为

4.6顺序图绘制：

顺序图强调消息的时间顺序（协作图则强调发送和接收消息的对象的组织结构）

交互图一般包含内容：

对象、链和消息。

也可以包含注释和约束

4.6UML中的事务分类：

4.7静态与动态建模的图有哪些：

用例视图、设计视图、过程视图、实现视图、实施视图********

4.8Rational统一过程（theRationalUnifiedProcess,RUP）

4.9工作流：

用于描述能够产生有用成果的有重要意义的活动序列，并给出工作人员之间的交互作用

核心工作流（coreprocessworkflow）

9个核心过程工作流，它们把所有工作人员和活动按涉及的领域或学科进行逻辑分组

6个核心工程工作流（业务建模、需求、分析和设计、实现、测试和实施工作流）

3个核心支持工作流（项目管理、配置和修改管理及环境工作流）

工作流细节（workflowdetails）

每个核心工作流覆盖许多领域为RUP使用工你流作流细节来展示

7.1：

软件测试的目标：

软件测试目标就是发现错误

（1）测试是一个程序执行的过程，其目的在于发现错误

（2）一个好的测试用例，是能够发现至今尚未察觉的错误的用例

（3）一个成功的测试，则是发现至今尚未察觉的错误的测试

7.2黑盒测试：

如果知道产品的功能，可以测试它的每一个功能是否都达到预期要求

白盒测试：

已知产品的内部活动方式，可以测试它的内部活动是否都符合设计要求

7.3软件测试的原则：

（1）程序员或程序设计机构不应测试自己设计的程序

（2）测试用例设计中，不仅要有确定的输入数据，而且要有确定预期输出的详尽数据

（3）测试用例的设计，不仅要有合理的输入数据，还要有不合理的输入数据

（4）除了检查程序是否做了它应做的事之外，还要检查它是否做了不应该做的事

（5）保留全部测试用例，并作为软件的组成部分之一

（6）程序中存在错误的概率与在该程序中已发现的错误数成比例

（7）所有测试都应追溯到用户需求

7.4测试用例设计：

基本目的是确定一组最有可能发现某个错误或某类错误的数据。

无论是黑盒子，还是白盒子测试都不可能进行穷举测试。

所以，测试用例的设计只能在周期和经费允许的条件下，使用最少数目的测试，发现最大数目可能的错误

7.5软件测试的步骤：

单元测试、集成测试、确认（功能）测试、系统（实例）测试。

7.5.1单元测试：

检查软件设计的最小单元（模块），是以详细过程设计为依据，对重要的控制路径进行测试，用以发现逻辑结构中的错误。

单元测试主要使用白盒子测试、多个模块可以同时平行测试。

单元测试是针对模块的，它不是一个独立的程序。

因此，模块自己不能运行，要靠其它部分来调用或驱动。

这样就要为每个单元测试模块设计两个软件：

驱动（driver）程序和连接（stub）程序

7.5.2集成测试：

它是以结构设计文档为依据，把巳通过单元测试的模块装配在一起时进行测试，主要用以发现与接口相关的错误

组装测试是用于软件装配的一种系统化的技术。

它有自顶向下结合和自底向上结合两种测试方法。

自顶向下的结合又可分为先深度后宽度的方法和先宽度后深度的方法。

自顶向下和自底向上两种方法相比较，一种方法的优点是另一种方法的缺点