第1章

1.1什么是计算机软件h2>

计算机软件是指计算机系统中的程序及其文档。程序是计算机任务的处理对象和处理规则。文档是了解程序的阐述资料

1.2计算机软件的特点h2>

• 软件开发成本和进度难以准确估算
• 软件是被开发和设计的，没有明显的制造过程。开发成果复制即可，但维护工程量大
• 软件没有机械磨损和老化问题

1.3软件的分类

• 系统软件（编译程序、操作系统）
• 支撑软件（数据库管理系统、软件开发工具等）
• 应用软件

1.4软件语言的分类

1. 需求定义语言。（书写软件需求定义。PSL）
2. 功能性语言（书写软件功能规约。广谱语言、z语言）
3. 设计性语言。（书写软件设计规约。PDL）
4. 程序设计语言。（书写计算机程序。高级、低级）
5. 文档语言。（书写计算机软件文档。z、obj）

1.5什么是软件工程h2>

• 将系统化、严格约束的、可量化的方法应用于软件开发、运行和维护，即将工程化应用于软件
• 对1中所述方法的研究

1.6软件工程的基本原则

1. 选取适宜的开发风范
2. 采取合适的设计方法
3. 提供高质量的工程支持
4. 有效的软件工程管理

1.7软件的生命周期阶段

1. 计算机系统工程阶段。任务：确定软件的总体要求和范围。进行成本估算、进度安排和可行性分析
2. 需求分析阶段。解决软件开发做什么的问题
3. 设计阶段。系统设计和详细设计。系统设计：设计软件系统的体系结构，也包括软件系统的组成成分、各个成分的功能和接口、成分之间的连接和通信，数据库。详细设计：各个部分的实现细节，包括数据结构和算法
4. 编码。
5. 测试。单元测试、集成测试、确认测试和系统测试
6. 运行和维护。软件运行阶段，对投入运行的软件进行维护

1.8简述CMM的5个等级

1. 初始级。软件过程特点是无秩序、甚至是混乱的
2. 可重复级。建立了基本的项目管理过程来跟踪成本、进度和功能特性
3. 已定义级。将管理和工程活动文档化、标准化，并综合成该组织的标准软件过程。
4. 已管理级。收集对软件过程和产品质量的详细度量值，对软件过程和产品有定量的理解和控制
5. 优化级。新思想、新技术促使过程不断改进

1.9软件过程模型及其特点

1. 瀑布模型。特点：上一阶段的结果作为下一阶段的输入。客户的需求也常常变化。
2. 演化模型。

• 增量模型。将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的增量版本，后一个版本是对前一个版本的修改和补充。
• 原型模型。预期系统的一个执行版本，反映系统性质。快速、低成本地构建原型。
• 螺旋模型。将原型实现和瀑布模型结合，增加风险分析。

     3.喷泉模型。支持面向对象开发的过程模型。

1.10CASE（计算机辅助软件工程）工具

第2章 系统工程

2.1简述系统工程的任务

1、识别用户需求

识别用户对基于计算机系统的总体要求，标识系统的功能和性能范围

2、系统建模和模拟

（1）硬件系统建模。确保计算机系统的安全性、可靠性、性能等

（2）软件系统建模。系统软件可分解为若干个子系统。描述各软件子系统的功能、性能等

（3）人机接口模型。描述人如何与基于计算机系统进行交互，用户环境、活动、交互语法语义等

（4）数据模型。用了哪些数据库管理系统

3、成本估算及进度安排

4、可行性分析

5、生成系统规格说明

2.2基于计算机系统的元素

软件、硬件、人员、数据库、文档、规程（每个系统元素或其外部相关流程的具体步骤）

第三章 需求工程

软件需求是指用户对目标软件在功能、行为、性能、设计约束等方面的期望

3.1需求工程分为哪些阶段，描述各阶段任务h2>

1. 需求获取。通过与用户进行交流，对现有系统的观察以及对任务进行分析，确定系统或产品的限制性描述
2. 需求分析和协商。
3. 系统建模
4. 需求规约
5. 需求验证
6. 需求管理

3.2软件需求包含

功能、性能、用户或人的因素、环境、界面、文档、数据、资源使用、可行性、软件成本和开发进度、其他

3.3软件需求分析的操作性原则和需求工程的指导性原则是什么h2>

• 必须能够表示和理解问题的信息域
• 必须能定义软件将完成的功能
• 必须能表示软件的行为（作为外部事件的结果）
• 必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节
• 分析过程应该从要素信息移向细节信息

3.4软件需求规约主要包含的内容

1. 引言：陈述软件目标，基于计算机的系统语境进行描述
2. 信息描述：给出软件必须解决的问题的系统描述，记录信息内容、信息流和信息结构
3. 功能描述：描述解决问题所需的每个功能
4. 行为描述：描述作为外部事件和内部事件的控制特征的软件操作
5. 检验标准：描述系统成功的检验标志
6. 参考书目
7. 附录：补充信息、表格数据、算法描述等

第四章 设计工程

4.1 软件设计任务

1. 数据/类设计
2. 体系结构设计
3. 接口设计
4. 部件级设计

4.2软件设计过程

1. 指定规范
2. 体系结构和接口设计
3. 数据/类设计
4. 部件级设计
5. 编写设计文档
6. 设计评审

4.3软件设计原则

• 抽象与逐步求精
  • 抽象：抽出事务的本质特征，暂不考虑实现细节
  • 逐步求精：为了集中精力主要问题，尽量推迟对细节的考虑，实际上是一个细化过程，与抽象互补
• 模块化：实际上是系统分解和抽象的过程，将软件安装规定的原则，划分为较小的、相互独立但又相互联系的部件。
  • 模块：数据说明、可执行语句等程序对象的集合，可以通过名字来访问。如函数、对象类、构件等
• 信息隐藏：将模块的实现细节隐藏起来，每个客户只能通过接口来了解该模块，而所有的实现都隐藏起来

4.4什么是模块独立性

  在设计程序模块时，使得模块实现独立的功能并与其他模块的接口简单，符合信息隐蔽的原则，模块之间的关联和依赖程度尽可能小。

指标：内聚度和耦合度

4.5软件设计规约

第五章 结构化分析与设计

结构化方法包括：结构化分析、结构化设计和结构化程序设计。

5.1结构化分析

过程

1. 理解当前现实环境，获取当前系统的具体模型（物理模型）
2. 从当前系统的具体模型抽象出当前系统的逻辑模型
3. 分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型
4. 为目标系统的逻辑模型作补充

1. 发现需求
2. 求精：对初步需求反复多次求精
3. 建模：用图像符 将需求刻画出来
4. 规格说明
5. 复审

5.1.1结构化分析模型的描述形式

工具：数据字典、数据流图、实体关系图、状态转换图

5.1.2数据流图

作用：描述输入数据流到输出数据流的变换，用于对系统功能建模

包含元素：数据流、加工、文件、数据源、数据宿

分层，画法看示例

5.1.3数据字典–定义数据流和数据存储

作用：与数据流图相结合，对数据流、文件、数据项、加工、源或宿，进行详细说明描述，形成软件的逻辑模型

其中，对于数据加工的说明可用：结构化语言或判定表或判定树

5.1.4分层数据流图的画法

1. 画出系统的输入和输出。
   1. 确定源和宿
   2. 确定加工
   3. 确定数据流
   4. 顶层数据流通常没有文件
2. 画出系统内部，将顶层图的加工分为若干个子加工
3. 画出加工内部图

5.1.5分层数据流图的审查

一致性和完整性

1. 一致性
   1. 父图和子图平衡。任何一张数据流图子边界上的输入输出数据流必须与其父图对应加工的输入输出保持一致
   2. 数据守恒。所有输出数据流都是从该加工的输入数据流中获得，或加工产生的。
   3. 局部文件。分析数据流图中一个文件应该画在哪些DFD中
   4. 一个加工的输出数据不能和输入数据同名
2. 完整性
   1. 每个加工至少一个输入数据流，一个输出数据流
   2. 每个文件至少有一个加工读取
   3.  每层分层图中数每个数据流和文件名称必须一致
   4. 每层的每个加工都应有一个加工规约（小说明）

5.1.6分解数据流图的分解程度原则

1. 7+-2
2. 分解应自然，概念上合理清晰
3. 在不影响DFD易理解性下，适当增加子加工数量，减少层数
4. 上层分解快，下层慢
5. 分解要均匀

5.2结构化设计

任务：将结构化分析得到的数据流图映射成软件体系结构

系统设计：将系统分解成成模块，确定每个模块的功能接口（模块名称、输出参数、返回值）以及调用关系

详细设计：对模块实现细节的设计

工具：结构图

5.2.1结构图的基本组成

• 模块
  • 内部特征：模块内部数据和完成其功能的程序代码
  • 外部特征：模块的接口（模块名称、输出参数、返回值）和模块的功能
• 调用：模块之间的调用关系
• 数据：模块调用时需传递的参数

5.2.2结构化设计的策略

1. 改造程序结构图，降低耦合度，提高内聚度
2. 避免高扇出，并随着深度增加，力求高扇入
3. 模块的影响范围应该在模块的控制范围内
4. 降低模块接口的复杂程度和冗余程度，提高一致性
5. 模块的功能应是可预测的，避免对模块施加过多的限制。
6. 尽可能单入口单出口设计

5.2.3结构化设计的步骤

1. 初步建立结构图
2. 对结构图进行改进
3. 书写设计文档
4. 设计评审

5.3数据流图映射到结构图的步骤

1. 复审和精华数据流图
2. 确定数据流图的类型。事务型还是变换型
   1. 变换型：有明确的输入、变换、输出
   2. 事务型：数据流沿着输入路径到达事务中心，根据输入数据流的类型执行不同的动作路径
3. 将DFD图映射成结构图
4. 改进结构图

5.3.1变换分析

变换流：信息沿着输入路径进入系统，并将输入信息的外部形式经过加工变成内部形式，内部形式的信息通过变换中心的处理，沿着输出路径后变成输出信息，送到系统外。

步骤

1. 划分输入流和输出流的边界，确定变换中心
2. 进行第一级划分
   1. 主控模块。整个系统的功能
   2. 输入控制模块
   3. 变换控制模块
   4. 输出控制模块
3. 进行第二级分解
   1. 输入控制模块的分解
   2. 输出控制模块的分解
   3. 变换控制模块的分解
4. 标注输入输出信息

5.3.2事务分析

事务流：数据流沿输入路径到达一个书屋中心，事务中心根据输入数据的类型在若干条动作路径中选一条来执行。

步骤

1. 确定事务中心
2. 将DFD映射成事务型结构图
3. 分解每条动作路径所对应的结构图

第六章 面向数据结构的分析与设计

原则：使程序结构与问题结构（数据结构）相对应

特点：

• 简单易学、形象直观、可读性好
• 便于表示层次结构
• 适用于小型数据处理系统

步骤：

1. 分析并确定输入和输出数据结构的逻辑结构，并用Jackson图画出
2. 找出输入数据与输出数据中对应关系的数据元素
3. 从描述数据结构的Jackson图导出描述程序结构的Jackson图
4. 列出所有操作和条件，并将它们分配到程序结构图的适当位置
5. 用伪码表示

第七章 面向对象方法基础

面向对象=对象+分类+继承+通过消息的通信

7.1什么是对象是类之间有什么关系strong>

对象：对象是一组具有相同状态的一组操作的集合，对状态（属性）和操作的封装

类：是一组具有相同属性和相同操作的对象集合。

关系：一个类中的每个对象都是类的一个实例。类和对象的关系类似于 （变量类型 变量）

7.2什么是继承strong>

继承是类之间的一种基本关系，在继承关系中，子类可以继承父类的所有属性和操作，同时，子类还可以定义自己的特有属性和操作。

7.3什么是消息h2>

要求某个对象执行某样操作的规格说明

• 接收消息的对象 
• 消息名
• 0或多个变元

7.4什么是多态是动态绑定h2>

多态：在类等级不同层次可以共享一个方法名，不同层次每个类按照各自需要实现这个方法。

重载：在同一作用域内，参数特征不同的函数可使用相同的名字。

重写和重载：重载是定义相同的方法名，参数不同，重载是在一个类中。重写是子类重写父类的方法，重写是子类与父类之间；重载是编译时的多态性，重写时运行时的多态性。

动态绑定：是指在程序运行时才将消息所请求的操作与实际操作的方法进行连接

7.5面向对象的分析过程

1. 获取客户对系统的需求
2. 标识类与对象。表示类以及类的属性和操作
3. 定义类的结构和层次。
   1. 一般-特殊结构。交通工具-汽车
   2. 整体-部分结构。汽车-轮胎
4. 建造对象-关系模型。该模型描述了系统的静态结构，指出类之间的关系。
5. 建立对象-行为模型。系统的动态行为，指明系统如何响应外部事务。

7.6面向对象的设计过程

1. 系统设计
   1. 将分析模型划分成子系统
   2. 标识问题本身的并发性，并为子系统分配处理器
   3. 任务管理设计
   4. 数据管理设计
   5. 资源管理设计
   6. 人机交互设计
   7. 子系统间通信
2. 对象设计
   1. 对象描述
   2. 设计数据结构和算法
3. 消息设计：使用对象间的协作和对象-关系模型，设计消息模型
4. 复审：对设计模型进行复审

7.7UML有哪些视图h2>

第八章 面向对象建模

8.1用况建模

8.1.1什么是执行者是用况h3>

执行者：是指与系统交互的人或系统。与系统交互就是向系统发送信息或者接收信息，或者与系统交换信息

用况：一个用况指被执行者感受的一个完整的功能

• 用况总是被执行者启动的，执行者必须直接或间接地指示系统去执行用况
• 用况向执行者提供值，这些值是可识别的
• 用况是完整的，一个用况必须是一个完整的描述

8.1.2用况建模步骤

1. 定义系统
2. 确定执行者
3. 确定用况
4. 描述用况
5. 定义用况间的关系
6. 确认模型

8.1.3用况描述

用况名称：

参与的执行者：

前置条件：一个合法用户已经登录到这个系统

事件流：

• 基本路径：运转正常时的路径，是一系列没有分支和选择的简单陈述句
• 可选路径：不同于基本路径而允许不同是事件序列的路径

8.1.4 UML用况图的关系

关联 执行者与他所参与的一个用况之间的通信路径

扩展 扩展的用况到基本用况的一种关系，指出扩展的用况所定义的行为如何插入到基本用况所定义的行为中。扩展的用况通过模式化方式增量地修改基本用况

包含 从基本用况到另一个用况的一种关系，指出包含用况定义的行为被包含在基本用况所定义的行为中

用况泛化 特殊用况可继承一般用况

8.2静态建模

描述系统中包含的类以及类之间的关系

类图：描述类之间的静态关系——类名、属性名、操作

8.2.1CRC技术，一种标识类的技术

1、标识类

• 标识候选对象
• 筛选候选对象
• 对象的分类

2、标识责任

责任是与类相关的属性和操作。就是类所知道的或要做的任何事情

1. 标识属性
   • public 所有看到这个类的都能看到该属性
   • protected 这个类或它的子孙类都能看到该属性
   • private 只有这个类本身可以看到这个属性
   • Package 在同一个包中的任何类都可看到该属性
2. 定义操作

• 以某种方式操作数据（增删查改）
• 完成某种计算的操作
• 为控制事件的发生而监控对象的操作

4、复审CRC

8.2.2类之间的关系

关联 类实例间连接的描述

依赖 二个模型元素之间的一种关系 P158

泛化 更特殊描述与更一般描述之间的一种关系，多用于继承和多态类型的声明

实现 类继承接口，实现接口功能

8.3动态建模

描述系统的动态行为，显示对象在系统运行的不同时期的动态交互。状态转换图、活动图、通信图或协作图来建模

8.3.1状态转换机图

通常对类描述的补充，说明类对象可能的状态，以及哪些事情导致状态的改变。状态机图描述了对象的动态行为，是一种对象生存周期模型。

8.3.2活动图

活动是展示整个计算步骤控制流的结点和流程的图。执行的步骤可以是并发的和顺序的。活动定义被展示在活动图中。

8.3.3顺序图

用来描述对象间的交互行为，顺序图关注于消息的顺序，即对象间消息发送和接收的顺序。

8.3.4通信图

展示了围绕组合结构的各部分或协作的各角色而组织的一种交互。

8.4物理体系结构建模

8.6.1构件图

第九章 基于构件的软件开发

9.1什么是构件h2>

构件是某系统中有价值的、几乎独立的并可替换的一个部分，具有良好定义的体系结构语境内满足某种清晰的功能。

9.2构建的软件开发过程

9.2.1领域工程开发步骤

进行领域分析，产生领域模型和领域基准体系结构，并确定领域中潜在的可复用构件，然后进行构件的可变性分析，构件可复用构件，并存入构件库。

1. 领域分析
2. 建立领域特定的基准提信息结构模型
3. 标识候选构件
4. 泛化和可变性分析
5. 构件重构
6. 构件测试
7. 构件包装
8. 构件入库

9.2.2应用系统工程的步骤

进行应用系统分析，设计应用系统的体系结构，然后使用可复用构件开发应用系统，同时对构件的复用情况进行评价，以补充和改进构件库

1. 建立应用系统的体系结构模型
2. 寻找候选构件
3. 评价和选择合适的构件
4. 构件的修改和特化
5. 开发未被利用的部分
6. 构件的组装
7. 集成测试
8. 评价被复用的构件，并推荐可能的新构件

第十一章 人机界面设计

11.1设计问题

• 系统响应时间
• 用户求助设施
• 错误信息处理
• 命令标记

11.2黄金原则

1. 让用户拥有控制权
2. 减少用户的记忆负担
3. 保持界面一致

第十三章 软件测试

13.1测试目的

• 测试是为了发现错误而执行程序的过程
• 一个好的测试是这很可能找到迄今为止尚未发现的错误
• 一个成功的测试是揭示了迄今为止尚未发现的错误

13.2白盒测试

将测试对象看作一个透明的盒子，测试人员根据程序的内部实现逻辑结构以及有关信息设计测试用例。

13.2.1逻辑覆盖测试

语句覆盖：被测程序的每个可执行语句都至少被执行一次

判定覆盖：被测程序的每个判定条件的所有可能结果都至少出现一次

条件覆盖：被测程序中每个判定中的每个条件的所有可能结果都至少执行一次

判定条件覆盖：被测程序中每个判定条件的所有可能结果都至少出现一次并且每个判定中的每个条件的所有可能结果都至少执行一次

条件组合覆盖：被测程序中每个判定中的条件结果所有的可能组合都至少执行一次

路径覆盖：被测程序每条可能执行到的路径都至少经过一次

13.2.2基本路径测试

控制流图：

独立路径：程序中至少引进一个新的处理语句序列或一个新条件的任意路径，在流图中，独立路径至少包含一条该路径之前未曾到过的边。

13.3黑盒测试

依据需求规约，将程序看作一个黑色的盒子，不关注内部逻辑结构和特征，只检查程序功能是否符合规格说明

等价类划分法：将所有可能输入的数据划分成若干个等价类，在每个等价类中选取一个有代表性的数据作为测试数据

边界值划分法：选取位于输入输出边界范围附近的数据作为测试用例

因果图法：考虑输入条件的组合关系，考虑了输出条件对输入条件的依赖关系，即因果关系

13.4测试策略

13.4.1单元测试—-编码阶段

任务：又称模块测试，着重对软件设计的最小单元——软件构件或模块进行测试。单元测试根据设计描述，对重要的控制路径进行测试，以发现构件或模块内部的错误。常常使用白盒测试。

13.4.2集成测试—设计阶段

任务：又称组装测试，经单元测试后的模块需要集成为系统软件，集成测试是对集成后的系统软件进行测试，主要来揭露设计阶段产生的错误

13.4.3确认测试—需求分析阶段

任务：软件经过集成测试后需经过确认测试才可以交付使用。确认测试通常采用黑盒测试。

a测试：是 由一个用户在开发者的场所进行的，软件在开发者对用户的指导下进行测试

b测试：是由软件的最终用户在一个或多个场所进行的，开发者不在现场。

13.4.4系统测试—系统工程阶段

任务：对整个基于计算机的系统进行一系列测试。

恢复测试、安全保密性测试、压力测试、性能测试

第十四章 web工程

14.1Webapp的开发特点

• 经常以增量的方式开发
• 变换经常发生
• 期限较短

第十五章 软件维护与再工程

第十六章 软件项目管理

16.1什么是软件项目管理p>