第一章 绪论
1. 每 18 个月芯片的性能和速度均提高一倍,每隔 12 年软件生产大约提高一倍。
2. 软件:是能够完成预定功能和性能的可执行的计算机诚信度。包括使程序正常执行所需的数据,以及有关描述程
序操作和使用的文档。即:软件 = 程序 + 文档
3. 软件的特征:
软件的开发不同于硬件设计、不同于硬件制造、不同于硬件维修。
4. 软件危机出现的原因:
软件维护费用的急剧上升,直接威胁计算机应用的扩大;
软件生产技术进步缓慢,是家居软件危机的重要原因。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
5. 软件工程学的范畴:
软件开发技术(软件开发方法学、软件工具、软件工程环境)、软件工程管理(软件管理学、软件经济学、度量学)。
6. 软件工程:是指导计算机软件开发和维护的工程学科。它采用工程的概念、原理、技术和方法来开发与维护软件,
目的是为了实现按照预期的进度和经费完成软件生产计划,同时提高软件的生产率和可靠性。
7. 软件的发展:大体经历了 程序、软件、软件产品 3 个阶段。
8. 工具 和 方法 是软件开发技术的 2 大支柱。
9. 3 种编程泛型:
过程式编程泛型、面向对象编程泛型、基于构件技术的编程泛型
10. 面向对象程序设计中,数据和操作被封装在一个对象中,对象之间则是通过消息相互联系。
11. 构件:标准化/规格化的对象类。
12. 常用变成力度的大小来比较 3 种编程泛型的差异。
粒度由小到大依次是:过程式编程范式、面向对象编程范式、基于构件的编程泛型。
13. 软件工程的分化:
传统软件工程:结构化分析-》结构化设计-》面向过程编码-》软件测试
面向对象软件工程:OO 分析与对象抽取-》对象详细设计-》面向对象的编码与测试
基于构件的软件工程(以可复用构件和测试工具为后盾):
领域分析和测试计划定制-》领域设计-》建立可复用构件库-》按‘构件集成模型’查找与集成构件
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)
结构化设计(工具:SC 图)
初始设计模型(初始 SC 图)
------》分析模型(分层 DFD 图)+SRS
(映射)------》初始设计模型(初始 SC 图)
(优化)------》最终设计模型(最终 SC 图)
4. 结构化分析的基本步骤:自顶向下,功能分解(分层 DFD)、由后向前,定义数据和加工(DD, PSPEC)、根据需要,
分析复杂数据和动态模型(E-R 图,CFD,CSPEC,STD)、编写软件需求规格说明书 SRS。
SA 需求分析的两项基本任务:建立系统分析模型、编写 SRS。
SD 阶段把分析模型中的 DFD 图转换为 最终 SC 图。
5.
6. 分析模型组成:功能模型、数据模型、行为模型 3 种。
7. 抽象 和 分解 是结构化分析的主要指导思想,细化的实质是分解。分解 和 细化 是软件设计的策略。
8.
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 集成测试策略:基于线程的测试、基于使用的测试。
第九章 软件维护