软件工程原理方法与应用第三版复习总结Word文件下载.docx

软件工程原理方法与应用第三版复习总结Word文件下载.docx

《软件工程原理方法与应用第三版复习总结Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件工程原理方法与应用第三版复习总结Word文件下载.docx（25页珍藏版）》请在冰豆网上搜索。

14.分析先于设计，设计先于编码，使程序〔的结构〕适合于问题〔的结构〕。

第二章软件生存周期与软件过程

1.软件生存周期：

方案、开发、运行3个时期。

需求分析-?

软件分析-?

软件设计-?

编码测试-?

软件测试-?

运行维护

2.需求分析〔用户视角〕：

功能需求、性能需求、环境约束、外部接口描述。

3.软件分析〔开发人员视角〕：

建立与需求模型一致的，与实现无关的软件分析模型。

4.软件设计：

总体设计/概要设计、详细设计〔确定软件的数据结构和操作〕。

5.单元测试通常与编码同时进行。

6.软件测试：

单元测试、集成测试、系统测试。

7.Boehm软件生存周期的划分：

系统需求、软件需求、概要设计、详细设计、编码纠错、测试和预运行、系统维护。

8.瀑布模型特点：

阶段间的顺序性和依赖性、推迟实现的观点、保证质量的观点。

9.瀑布模型存在的问题：

只有在需求分析准确的前提下，才能得到预期的结果。

快速原型模型：

原型系统只包括对未来系统的主要功能以及系统的重要接口。

特点：

快速开发工具、循环、低本钱。

种类：

渐进型、抛弃型。

10.常见的演化模型〔渐增式、迭代式〕：

增量模型、螺旋模型。

11.增量模型：

结合瀑布模型的顺序特征与快速原型法的迭代特征。

增量：

小而可用的软件

一般情况下，第一个增量是软件的核心局部。

如〔增量一：

需求-设计-实现和集成-交付客户〕

12.螺旋模型〔目前最常用〕：

当工程按照顺时针方向沿螺旋线移动时，每轮螺旋包含：

方案、风险分析、建立原型、用户评审4种活动。

〔高风险的大型软件采用此方法〕

13.构件集成模型：

适应于面向对象的软件开发。

利用预先封装好的构件来构造应用软件系统。

14.软件开发方法可区分：

形式化方法、非形式化方法。

15.形式化开发模型：

转换模型、净室模型

16.转换模型：

是将形式化软件开发和程序自动生成技术相结合的一种软件开发模型。

转换模型的开发过程：

确定性实话的需求规格说明书、进行自动化的程序变换、对形式化开发记录进行测试。

转换模型的常用技术：

基于模型的需求规格说明书及其变换技术；

基于代数结构的需求规格说明书及其变换技术；

基于时序逻辑的需求规格说明书及其验证技术以及基于可视化的技术。

17.净室模型：

是一种形式化的增量开发模型。

力求在分析和设计阶段消除错误。

18.统一过程RUP包括4个阶段：

初始、细化、构造、迁移。

以用例为驱动,以系统架构为中心的迭代与增量过程。

每个阶段又分为假设干次迭代，每次迭代都有一个核心工作流，有5个活动〔需求、分析、设计、实现、测试〕。

19.敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。

20.敏捷开发的价值观：

个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循方案。

21.软件可行性研究：

经济可行性、技术可行性、运行可行性、法律可行性。

22.可行性研究的步骤：

对当前系统进行调查研究、导出新系统的解决方案、提出推荐方案、编写可行性论证报告。

23.可行性论证报告的内容：

系统概述、可行性分析、结论意见。

24.软件风险分析包括：

风险识别〔工程风险、技术风险、商业风险〕、风险预测、风险的驾驭和监控。

25.软件方案的7种类型：

工程实施方案、质量保证方案、软件测试方案、文档编制方案、用户培训方案、综合支持方案、软件分发方案。

第三章结构化分析与设计

1.结构化设计SD；

结构化分析SA；

软件需求规格说明书SAS；

结构图SC；

数据字典DD；

状态转换图STD；

数据流图DFD

2.瀑布模型的生命周期：

需求定义与分析-?

总体设计-?

详细设计-?

编码-?

测试-?

维护

3.系统的开发流程〔SA和SD流程〕：

结构化分析〔工具：

DFD，PSPEC〕------?

分析模型〔分层DFD图〕+SRS

结构化设计〔工具：

SC图〕〔映射〕------?

初始设计模型〔初始SC图〕

初始设计模型〔初始SC图〕〔优化〕------?

最终设计模型〔最终SC图〕

4.结构化分析的根本步骤：

自顶向下，功能分解〔分层DFD〕、由后向前，定义数据和加工〔DD,PSPEC〕、根据需要，分析复杂数据和动态模型〔E-R图，CFD,CSPEC,STD〕、编写软件需求规格说明书SRS。

5.SA需求分析的两项根本任务：

建立系统分析模型、编写SRS。

6.分析模型组成：

功能模型、数据模型、行为模型3种。

7.抽象和分解是结构化分析的主要指导思想，细化的实质是分解。

分解和细化是软件设计的策略。

8.SD阶段把分析模型中的DFD图转换为最终SC图。

9.传统软件的开发技术：

结构化设计、模块设计。

10.软件设计：

总体设计/概要设计〔初始SC图、最终SC图〕、详细设计〔用逐步细化的方法，完成模块的说明〕。

11.需求分析的步骤：

需求获取、需求提炼、需求描述、需求验证。

12.SA模型的组成

13.SA模型同时覆盖了信息模型、功能模型、行为模型3种模型。

14.DFD图不能表示程序的控制结构〔如选择、循环结构〕。

15.加工规格说明通常用结构化语言、判定表、判定树作为描述工具。

16.软件中的数据分为3类：

数据项〔数据元素〕、数据流〔多个相关数据项〕、数据文件和数据库。

17.数据字典的组成：

数据项、数据流、数据存储（文件或数据库）、加工（处理逻辑）、外部项（人、物或其它软件系统）。

18.SD模型是由SA模型映射而来的。

SA模型的数据字典可转换为待开发系统的数据设计

数据流图可转换为体系结构设计〔SC图〕与接口设计

加工规格说明可转换为模块内部的详细过程设计

19.SD模型的组成：

从上到下依次是：

过程设计、接口设计、体系结构设计、数据设计。

20.结构化分析的根本步骤：

自顶向下对系统进行功能分解，画出DFD图；

由后向前定义系统的数据和加工；

编制DD和PEPES；

写出SRS。

21.把不需要分解的加工成为根本加工。

把逐步分解成为“自顶向下，逐步细化〞。

22.DFD的优点：

便于实现，便于使用。

23.传统的软件设计可细分为:

面向数据流设计〔SD方法〕、面向数据结构设计〔Jackson方法〕。

24.用数据流图表示逻辑模型，在设计阶段，按照数据流图的不同类型〔变换型、事务型〕转换为相应的软件结构。

25.结构化设计通常从DFD图到SC图的映射开始。

26.面向数据流的设计方法：

从DFD图到SC图的映射的4个步骤：

复审DFD图，必要时可再次进行修改或细化；

鉴别DFD图的结构特征:

事务？

变换？

；

按照规那么，把DFD图为初始的SC图；

改良初始的SC图。

27.变换型结构：

由输入、变换中心和输出三局部组成。

事务型结构：

具有在多种事务中选择执行某类事物的能力。

28.变换映射的步骤：

划分DFD图的边界、建立初始SC图的框架、分解SC图的各个分支。

事务映射的步骤：

在DFD图上确定边界、画出SC图框架、分解和细化接受分支和发送分支。

29.优化结构设计的指导规那么：

对模块分割、合并和变动调用关系的指导规那么、保持高扇入/低扇出的原那么、作用域/控制域规那么。

30.模块设计〔详细设计〕的主要任务是编写软件的模块设计说明书。

目的是确定模块采用的算法和块内数据结构。

31.模块设计的原那么：

清晰第一的设计风格、结构化的控制结构、逐步细化的实现方法。

32.“结构化〞保证程序的清晰、易读,“逐步细化〞实现程序的正确、可靠。

33.结构化程序设计原理和逐步细化的实现方法是完成模块设计的根底。

第四章面向对象和UML

1.面向对象的根本特征：

抽象、封装、集成、多态。

2.面向对象开发的优点：

提高软件系统的可复用性、可扩展性、可维护性。

3.元素之间的联系有：

关联、泛化、依赖、实现、聚集、组合。

4.UML的4个抽象层次：

用户模型、模型、元模型、元元模型。

5.UML的2类图：

静态图〔用例图、类图、对象图、构件图、部署图〕；

动态图〔状态图、时序图、协作图、活动图〕

5种视图：

用例视图、逻辑视图、进程视图、构件视图、部署视图。

6.UML的特点：

同意标准、面向对象、表达能力强，可视化。

7.UML模型作为测试阶段的依据：

单元测试使用类图和类规格说明；

集成测试使用构件图和协作图；

系统测试使用用例图来验证系统行为。

8.UML静态建模机制包括：

用例图、类图、对象图构件图、部署图。

用例图有：

系统边界、用例、参与者、关联等。

用例之间存在的关系：

扩展关系、包含关系。

包与包之间的关系有：

依赖、泛化。

9.UML动态建模机制包括：

状态图、时序图、协作图、活动图。

10.消息：

简单消息、同步消息、异步消息。

状态图有：

初态、终态、中间态。

11.时序图中的消息可以是信号或操作调用。

12.时序图着重表达交互的时间顺序；

协作图着重表达交互对象间的静态链接。

13.时序图和协作图适合描述单个用例中几个对象的行为；

活动图适合表现跨越多用例或多线程的复杂行为。

14.构件图可以用来表现、编译、链接、执行时构件间的依赖关系。

15.UML用图表示语法，用元模型表示语义，采用模型来描述系统的结构〔静态特征〕以及行为〔动态特征〕。

第五章需求工程和需求分析

1.软件需求的3个层次：

业务需求、用户需求、功能需求。

软件工程中40%~60%的问题源自软件需求阶段。

2.软件需求的6个特性：

功能性、可用性、可靠性、性能、可支持性、设计约束。

3.功能性：

普通功能、全局性功能。

4.软件需求工程：

是一门应用有效的技术和方法，适宜的工具和符号来确定、管理和描述目标系统及其外部行为特征的学科。

5.需求分析的步骤：

需求获取、需求建模、需求描述〔编写SRS〕、需求验证。

6.需求分析的主要任务：

建立需求模型。

需求分析是迭代过程。

常见模型有：

用例图、数据流图、实体联系图、控制流图、状态转换图。

7.需求建模方法：

结构化分析建模方法、面向对象分析建模。

8.结构化需求模型由3局部组成：

功能模型〔数据流图、加工规格说明书〕、数据模型〔数据字典、ER图〕、行为模型〔状态转换图、控制流图、控制规格说明书〕。

9.面向对象需求模型：

用例模型〔用例图、用例规约〕、补充规约、术语表。

10.面向对象需求建模的步骤：

画用例图、写用例规约、描述补充规约、编写术语表。

11.用例规约文档的内容：

简要说明、事件流、特殊需求、前置条件和后置条件。

12.用例规约的检查：

功能需求的完备性、模型是否易于理解、是否存在不一致性、防止二义性。

13.软件需求规格说明书SRS的内容：

引言、信息描述、功能描述、行为描述、质量保证、接口描述、其他描述。

14.质量保证说明软件交付前进行功能测试、性能测试。

接口描述包括系统用户界面、硬件接口、软件接口、通信接口。

15.需求管理的流程：

需求确认、需求跟踪、需求变更。

需求跟踪有两种方式，正向跟踪与逆向跟踪。

需求变更的流程：

变更申请、审批、更改、更新确认。

16.需求管理的5个特定实践：

17.基线（Baseline）是软件文档或源码（或其它产出物）的一个稳定版本,它是进一步开发的根底。

第六章面向对象分析

1.面向对象分析OOA的建模步骤：

需求理解、定义类和对象、标识对象的属性和操作、标识类的结构和层次、建立对象-关系模型、建立对象-行为模型、评审OOA模型。

2.OOA的优点：

同时加强了对问题空间和软件系统的理解；

改良包括用户在内的软件分析有关的各类人员之间的交流；

对需求的变化具有较强的适应性；

很好的支持软件复用；

确保从需求模型到设计模型的一致性。

3.分析模型（是一种概念模型）的特点：

全面覆盖软件的功能需求；

分析模型与软件的实现无关；

分析模型的表述方法与所采用的分析技术有关。

4.典型的五层次模型：

建立类/对象层〔抽象出类和对象〕、建立属性层〔设计静态属性和关系〕、建立效劳层〔定义动态属性和消息通信〕、建立结构层〔定义层次结构关系〕、建立主题层〔每个主题构成一个子系统〕。

5.OOA方法的共同特征：

类和类层次的表示、建立对象-关系模型、建立对象-行为模型。

6.面向对象开发的全过程：

OOA〔分析〕、OOD〔设计〕、OOP〔编码〕、OOT〔测试〕。

7.从建立需求到开发软件成品先后要生成分析、设计、实现3种模型。

8.用例模型是面向对象分析最常用的一种模型。

9.用例分析的步骤：

补充用例规约、研究用例的事件流，将用例的职责分配给假设干分析类、分析类之间的协作。

10.分析类的类型：

边界类、控制类、实体类。

11.边界类包括：

用户界面类、系统接口类、设备接口类。

如事务管理器、资源协调器、错误处理器都可为控制类。

12.为分析类分配职责是OOD的重点。

实体类具有持久性。

13.对象-关系模型的内容：

分析类的属性、分析类的关联、分析类图、分析类的合并。

14.时序图中的元素有：

对象、对象生命线、消息。

协作图中的元素有：

对象、链接、消息流。

15.面向对象分析的任务是：

将需求阶段产生的需求模型转换为软件分析模型。

面向对象设计的任务是：

将分析阶段建立的分析模型转换为软件设计模型。

第七章面向对象设计

1.软件设计的根本概念：

模块〔定义输入、输出和特性的程序实体〕与构件、抽象与细化、信息隐藏、软件复用。

2.软件设计的根底：

分析阶段对目标系统的数据、功能、行为建模。

3.软件设计包括：

数据设计、体系结构设计、接口设计、过程设计。

4.分解和模块独立性是实现模块设计的重要指导思想。

5.模块数与开发工作量的关系：

6.概要设计（总体设计）：

包括软件的结构和接口设计，并编写概要设计文档。

详细设计，确定模块内部的算法和数据结构，产生描述各模块程序过程的详细文档。

每个阶段完成的文档都必须经过复审。

7.模块的独立性从2个方面度量：

模块本身的内聚、模块之间的耦合。

8.内聚分类：

低内聚〔偶然性内聚、逻辑性内聚、时间性内聚〕、中内聚〔过程性内聚、通讯性内聚〕、高内聚〔顺序性内聚、功能性内聚〕。

9.耦合分类：

弱耦合〔非直接耦合、数据耦合、特征耦合〕、中耦合〔控制耦合〕、较强耦合〔外部耦合、公共耦合〕、强耦合〔内容耦合〕。

10.一个模块，一个功能是模块化设计的一条准那么。

11.OO设计模型由系统架构层、类和对象层、消息层、责任层4个层次组成。

12.面向对象设计中，数据和过程被封装为类/对象的属性和操作；

接口被封装为对象间的消息，而体系结构的设计那么表达为系统的技术根底设施和具有控制流程的对象间的协作。

13.OOD的软件设计可划分为2个层次：

系统架构设计、系统元素设计。

14.系统架构设计的内容：

系统高层结构设计、确定设计元素、确定任务管理策略、实现分布式机制、设计数据存储方案、人机界面设计。

系统元素设计的内容：

子系统设计、分包设计、类/对象设计。

15.软件模式分类〔按抽象级别〕：

架构模式、设计模式、习惯用法。

16.常用的架构模式有：

层次架构、模型-视图-控制架构、管道-过滤器架构、黑板架构。

17.层次架构的根本原那么：

将系统划分不同的层次。

确定设计元素的主要工作是：

确定设计类、子系统、子系统接口。

18.面向并行需求的技术：

引进任务管理部件、基于进程和线程的控制。

19.任务管理策略：

多处理机方案、操作系统方案、应用程序方案。

20.设计管理并发任务对象的策略：

确定任务的特征、定义一个协调者任务和与之关联的对象、集成其它任务和协调者。

21.任务管理部件的设计步骤：

识别由事件驱动和时间驱动的任务、识别关键性任务，任务优先级和任务管理类、定义任务、必要时扩充有关任务的类和对象。

22.

23.分包的原那么：

将边界类打包、将功能相关的类打包。

高内聚-低耦合的原那么，包之间的耦合表现为依赖关系。

24.类设计的步骤：

创立初始设计类、定义操作、定义方法、定义状态、定义属性、定义依赖关系、定义关联关系、定义泛化关系、处理非功能性需求。

第八章编码和测试

1.选择编码语言的标准：

应用领域、算法与设计复杂性、数据结构的复杂性、效率的考虑。

2.测试和纠错：

测试〔testing〕的目的与任务：

目的：

发现程序的错误；

任务：

通过执行程序，暴露潜在的错误。

纠错〔debugging〕的目的与任务：

定位和纠正错误；

消除软件故障，保证程序的可靠运行。

3.软件:

待测软件，包括软件需求规格说明书、设计说明书和源程序代码等文档资料。

测试配置:

包括测试方案、测试用例和测试期望结果。

评价:

将测试结果和期望的结果相比拟，如果不符就意味着错误，需要纠正（纠错）。

可靠性:

对测试结果进行收集和评价，得到可靠性的相关指标。

1.如果出现规律性、严重性的错误，软件质量可靠性值得疑心，需进一步测试；

2.如果软件功能完成较好，出现的错误也易纠正，那么：

或者软件质量和可靠性是可以接受的；

或者未发现错误，不排除测试配置考虑不周，可能潜伏着的错误。

4.模块逻辑中采用单入口、单出口标准结构、防止使用容易引起混淆的结构和语句、嵌套深度不超过3—4层。

5.测试的特性：

挑剔型、复杂性、不彻底性、经济型。

6.测试分类：

静态分析〔静态分析器分析、代码评审〔代码会审、走查、办公桌检查〕〕；

动态测试〔黑盒测试〔功能测试〕、白盒测试〔结构测试〕〕。

7.测试文档内容：

测试方案、测试报告。

测试方案的主体是测试内容说明：

测试工程名称、测试目的、步骤和进度、测试用例设计。

测试报告的主题是测试结果：

测试工程名称、实测结果和期望结果的比拟、发现问题、测试效果。

8.黑盒测试分类：

等价类法、边界值法、错误猜想法。

9.白盒测试分类：

路经测试〔点覆盖、边覆盖、路径覆盖〕、逻辑覆盖测试〔语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖〕。

10.路经测试的特征：

满足结构测试的最低要求、有利于安排循环测试。

11.2种OO集成测试策略：

基于线程的测试、基于使用的测试。

第九章软件维护

1.决定软件可维护性的因

2.软件副作用的类型：

修改编码的副作用、修改数据的副作用、修改文档的副作用。

3.软件配置管理能够系统的处理变更从而使得软件系统可以随时保持其完整性。

主要内容包括：

配置管理数据库、版本控制、变动控制。

4.什么是再工程：

将新技术和新工具应用于老的软件的一种较“彻底〞的预防性维护。

第十章软件复用

1.软件复用的定义:

（SR）定义为利用工程知识或方法，由一已存在的系统，来建造一新系统。

这种技术，可改良软件产品质量和生产率。

还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。

2.软件复用的目的是能更快、更好、本钱更低地生产软件制品。

3.按照可复用的粒度，软件制品从小到大分为以下几类：

源代码复用〔高级语言编写的源代码〕、软件体系结构复用〔已有软件的体系结构〕、应用程序生成器〔对整个软件体系结构、相应的子系统、特定的数据结构和算法〕、领域特定的软件体系结构的复用〔特定领域中存在的公共体系结构及其构件〕。

4.领域：

指的是一组具有相似或相近软件需求的应用系统所覆盖的功能区域。

领域工程：

通过领域分析（domainanalysis）找出最优复用，对它们进行设计和构造，形成为可复用构件，进而建立大规模的软件构件仓库的过程。

5.横向复用：

是指复用不同应用领域中的软件元素。

纵向复用：

是指在一类具有较多公共性的应用领域之间进行软件构件进行