【软件工程复习】

第1章 软件工程概述

1.2软件工程

​ 1983年IEEE给出的定义：“软件工程是 开发、运行、维护和修复软件的系统方法 ”

1.4软件生存期

软件开发和运行维护由三个时期组成：

1. 软件定义时期
2. 软件开发时期
3. 运行维护时期

里程碑指可以用来标识项目进程状态的事件

1.5软件工程方法概述

​ 软件工程方法学包含三个要素：方法、工具和过程。

1.5.1传统方法

​ 传统方法也称为生命周期方法或结构化范型。

​ 它采用结构化技术来完成软件开发的各项任务。

​ 每个阶段的开始和结束都有严格的标准，对于任何两个相邻的阶段而言，前一个的结束标准就是后一个的开始标准。

​ 每个阶段结束前都必须有正式评审。

​ 优点：在适应软件开发的全过程以一种有条不紊的方式进行，保证了软件质量。

​ 缺点：在适应需求变化的方面不够灵活，缺乏面向行为和面向数据的二者的有效结合。

1.6 软件工具概述

1.6.4 常见软件工具介绍

测试工具：

• 程序单元测试工具
• 组装测试工具
• 系统测试工具

1.7 软件工程知识体系及知识域

SWEBOK指南的目的是确认软件工程学科的范围，并为支持该学科的本体知识提供指导。

SWEBOK的修订内容：

• 在知识域 “软件工程模型与方法” 的子知识域 “软件工程方法” 中增加了 “敏捷方法” 这一知识点。
• 明确列出了4个基础类知识域：软件工程经济学、计算基础、工程基础和数学基础。
• 增加了知识域 “软件工程专业实践”，他所包括的子知识域有 “职业特性” “群组动力学与心理学” “沟通技能”

第2章 软件生存期模型

2.1 瀑布模型

​ 具有顺序性和依赖性

​ 实际的瀑布模型是带有 “反馈环” 的，当发现前面阶段的错误时，沿图中的反馈线返回进行修正之前的错误再回来继续完成之后的任务。

​ 瀑布模型的一个变体，称为 V模型

​ 自顶向下 的开发方法

优点：

• 可强迫开发人员采用规范化的方法。
• 严格规定每个阶段必须提交的文档
• 每个阶段都需要验证

缺点：

• 完全依赖于书面的规格说明，导致最后开发的产品很难真正满足用户的需要。
• 瀑布模型只适用于 项目开始 时需求已经确定的情况。

2.2 快速原型模型

​ 快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品功能的一个子集。

​ 优点：

• 有助于满足用户的真实需求
• “快！”
• 按照线性顺序进行。

2.3 增量模型

​ 在较短的时间里面 快速构造核心产品，提供核心的功能。

​ 能够在较短的时间内向用户提交一些有用的工作产品。

2.4 螺旋模型

​ 需要有一定的风控 并且 有原型。

​ 要求开发人员有丰富的风险评估经验和专业知识。

​ 原型：原型是指在项目的初期阶段，快速开发出一个功能有限但能够展示基本思路的产品或系统模型。在螺旋模型中，通常在每个迭代周期结束时，都会生成一个原型，便于开发团队和用户进行验证与反馈。通过原型，团队可以更早地发现问题，并根据反馈进行调整和改进。

​ 结合来看，这句话的意思是，采用螺旋模型开发时，项目需要有一定的风险控制措施，并且要在每个开发阶段或迭代周期中生成一个原型，以帮助验证设计的可行性，并根据反馈进行调整。

2.5 喷泉模型

​ 迭代 面向对象

2.6 统一过程

​ RUP

​ 不可以做开发公司的第一个软件产品

​ 统一过程的6个核心工作流： 业务建模、需求、分析与设计、实现、测试和部署。

​ 统一过程的4个阶段：初始阶段、细化阶段、构造（或称构建）阶段和移交阶段。

2.7 基于构件的开发模型

​ 新公司

2.8 敏捷过程

极限编程：（eXtreme Programming, XP）是使用最广泛的敏捷过程

使用了面向对象方法，包含了策划、设计、编码和测试4个框架活动的规则和实践。

第3章 软件需求获取与结构化分析方法

3.1 需求获取与需求分析阶段的任务

1. 需求获取的任务：

   • 发现和分析问题，并分析问题的原因/结果关系。
   • 与用户进行各种方式的交流，并使用调查研究方法收集信息。
   • 按照三个成分即： 数据、 过程 和 接口观察问题的不同侧面。
   • 讲获取到的需求文档化，形式有用例、决策表、决策树等。

2. 需求获取应该遵循的原则：

   1. 深入浅出的原则。
   2. 以流程为主线的原则。

3.2 结构化分析方法

​ 结构化分析方法是一种建模技术。 该模型的核心是 数据字典。

​ 围绕这个核心有三种图：

• **数据流图（DFD）：**描述数据在系统中如何被传送或变换，描述如何对数据流进行变化的功能，用于功能建模。
• 实体—关系图（ER）： 描述数据对象及数据对象之间的关系，用于数据建模。
• 状态-迁移图（STD）： 描述系统对外部事件如何响应、动作，用于行为建模。

3.2.1功能建模

1. 数据流图的基本图形符号

​ 2. 环境图

​ 环境图也称为顶层数据流图（或0层数据流图），它仅包括一个数据处理过程，也就是要开发的目标系统。

*

3.2.2 数据建模

3. 关系

3.2.3 行为建模

在需求分析中，应该建立起软件的行为模型。状态转换图通过描绘系统的状态及引起系统状态转化的事件来表示系统的行为。

初态（初始状体）、终态（最终状态）、中间态。

初态用实心圆表示

终态用牛眼图表示

中间态用圆形矩阵表示

3.2.5 加工规格说明

1. 决策表： 由4个部分组成， 左上部分是条件莊、左下部分是动作莊、右上部分是条件项、右下部分是动作项。
2. 决策树

3.3 系统需求规格说明

3.3.1 软件需求规格说明模板

​ 1. 软件需求规格说明： SRS

​ 2. 数据需求说明： DRD

3.5 需求管理

3.5.1 需求跟踪

第4章 结构化设计方法

4.1 软件设计的概念及原则

4.1.2 软件设计的原则

​ 1. 分而治之

​ 2. 模块独立化

​ 3. 提高抽象层次

​ 4. 复用性设计

​ 5. 灵活性设计

4.2 结构化设计

4.2.3 模块结构及表示

​ 模块：

​ 结构图：

• 扇入（Fan-in）：表示有多少其他模块调用当前模块，即其他模块对该模块的依赖。
  • 高扇入意味着该模块是核心模块，很多其他模块依赖它，通常是系统的功能性核心。
• 扇出（Fan-out）：表示当前模块调用了多少其他模块，即当前模块对其他模块的依赖。
  • 高扇出意味着当前模块的功能比较复杂，依赖于多个其他模块，可能增加系统的复杂度和耦合度。

4.3 体系结构设计

4.3.2 典型的数据流类型和系统结构

交换型数据流与交换型系统结构图

• 取得数据
• 交换数据
• 给出数据

2. 事务型数据流与事务型系统结构图

​ 接受一个事务，根据事务处理的特点和性质，选择分派一个适当的处理单元，再给出结果。

​ 吧分派任务的部分叫做事务处理中心。

4.3.5 模块间的耦合和内聚

• 耦合：耦合是指一个模块与其他模块之间的依赖程度。高耦合表示一个模块与其他模块之间的依赖性较强，修改一个模块可能导致其他模块也需要进行修改，增加了系统的复杂度。

​

• **内聚：**内聚是指一个模块内部各个部分之间的关联程度。模块内的各个元素应该尽可能地紧密地合作，完成一个单一的、明确的功能。

在这里插入图片描述

4.3.6 软件模块结构的改进方法

（1） 模块功能的完善化

（2） 清楚重复功能，改善软件结构

（3） 模块的作用范围应该在控制范围之内

（4） 尽可能减少高扇出结构，随着深度增大扇入

​ 模块的扇出数是指模块调用子模块的个数。如果一个模块的扇出数过大，意味该模块过分复杂，需要协调。

​ 而且如果模块的扇出数过大，将使得结构图的宽度过大，宽度越大，结构图越复杂。

​ 比较合适的扇出数为 2~5 ， 最多不要超过9。

​ 模块的扇出数过小，例如总是1，则会导致结构图的深度增加。

​ 通常上层的扇出比较高，中层扇出比较少，底层公用模块的扇入比较高。

（5） 避免或减少使用病态连接

• 直接病态连接 （模块A直接从模块B内部取出数据，或吧某些数据直接送到模块B）

• 公共数据域病态连接 （模块A和模块B通过公共数据与，直接传送或接受数据，而不是通过它们的上级模块，使耦合增加）

• 通信模块连接 （模块A和模块B通过通信模块TABLEIT传送数据）
  

  （6） 模块的大小要适中

4.4 接口设计

4.4.1 接口设计概述

​ 接口设计主要包括3个方面：

• 模块或软件构件间的接口设计
• 软件与其他软硬件系统之间的接口设计
• 软件与人之间的交互设计

4.4.2 人机交互界面

用户类型:

• 外行型
• 初学型
• 熟练型
• 专家型

4.6 过程设计

就是详细设计

自顶向下、逐步求精的优点：

​ 1） 自顶向下、逐步求精方法复合人们解决复杂问题的普遍规律，可提高软件开发的成功率和生产率

​ 2） 用先全局后局部、先整体后细节、先抽象后具体的逐步求精的过程开发出来的程序具有清晰的层次结构

​ 3） 程序自顶向下，逐步细化，分解成树形结构。

4.7 软件设计规格说明

GB/T 8567—2006《计算机软件文档编制规范》中有关软件设计的文档有 3 种。

即《软件设计说明（SDD）》、《数据库设计说明（DBDD）》、《接口设计说明（IDD）》。

第5章 面向对象方法与UML

**定义：**面向对象 = 对象 + 类 + 继承 + 消息通信

5.1 面向对象的概念与开发方法

5.1.1 对象

​ 对象是包含世界物体特征的抽象实体，它反映了系统为之保存信息和与它交互的能力。

​ 对象是一些属性及服务的封装体。

​ 对象 = 数据 + 作用于这些数据上的操作

​ 用矩形表示对象，并将带有下划线的对象名放在矩形内

​ 对象名有下列3种表示格式：
​ 1） 第一种格式是对象名在前，类名在后，中间用冒号连接。 如：对象名：类名

​ 2） 第二种格式是 ：类名

​ 3） 第三种格式是 对象名

​ 可以将程序中的对象分为5类： 物理对象、角色、事件、交互、规格说明。

5.1.2 类与封装

​ 1）类

​ 2）封装

​ 目的：在于将对象的使用着和设计者分开，使用者不必知道行为实现的细节，只需要使用设计者提供的操作来访问对象

​ 定义：清楚的边界、接口、受保护的内部实现

​ 3） 继承

​ 子类可重写父类继承的方法

​ 4） 多态

​ 编写一个个的过程或函数，不能重名。

​ 一个程序种同名的不同方法共存的情况。

​ 5） 消息通信

​ 消息是一个对象向另外一个对象传递的信息。有4类：

• 发送对象请求接受对象提供服务；
• 发送对象激活接受对象
• 发送对象询问接受对象
• 发送对象仅传送信息给接收对象

​ 消息的使用类似于函数调用，消息中指定了接收消息的对象、操作名和参数表

UML简介

​ UML（Unified Modeling Language 统一建模语言）

5.3 UML的事物

​ 可分为结构事务、行为事务、分组事务、注释事务。

结构事务包括类、主动类、接口、对象、用例、参与者、协作、构件和节点。

UML中的分组事物就是包。

5.4 UML的关系

依赖、关联、泛化和实现。

**依赖：**用的虚线箭头，从源事物指向目标事物

**关联：**描述两个或多个类之间的关系，分为普通关联，限定关联，关联类，聚合和复合。

​ 1 ：1个实例

​ 0… * 或 * ： 0到多个实例

​ 0… 1 ：0到1个实例

​ 1+ 或 1… * ： 1到多个实例

聚合： 也称为聚集，是一种特殊的关联，描述整体和部分之间的结构关系。比如出现“包含，组成”等就是聚合。还有共享聚合和复合聚合。如果聚合关系中部分类的实例可同时参与多个整体类实例的构成，则该聚合称为共享聚合。

泛化： 就是一般类和特殊类之间的继承关系，特殊类具有一般类的信息，还加了一些其他信息。

实现： 就是泛化关系和依赖关系的结合。

第6章 面向对象分析

6.1 面向对象分析概述

6.1.2 面向对象分析的3中模型

​ 面向对象分析模型由3种独立的模型构成：用例模型、对象模型、交互模型

6.3 建立对象模型

6.3.1 对象模型的5个层次

复杂问题的对象模型由下述5个层次组成：主题层、类-对象层、结构层、属性层和服务层。

第7章 软件体系结构与设计模式

7.1 软件体系的基本概念

7.1.1 什么是体系结构

7.1.2 体系结构模式、风格和框架的概念

​ 风格是一种带有倾向性的模式。

7.3 特定领域的软件体系结构

有两种领域相关的体系结构模型：类属模型和参考模型。

​ **类属模型：**是从许多实际系统中抽象出来的一般模型，封装了这些系统的主要特征。

​ **参考模型：**描述了理想化的包含了系统应具有的所有特征的软件体系结构。

7.4 分布式系统结构

7.4.2 客户机/服务器体系结构

​ C/S结构有3个主要组成部分：

​ 1）服务器 2） 客户机 3）网络

​ 二层C/S体系结构：

​ **1）瘦客户机模型：**数据管理部分和应用逻辑都在服务器上执行，客户机只负责表示部分。

​ 2）胖客户机模型： 服务器只负责对数据的管理，客户机实现应用逻辑和与系统用户的交互。

​ **三层C/S体系结构：**表示层、应用逻辑层和数据层。

7.5 体系结构框架

7.5.1 模型-试图-控制器

​ MVC 强调将用户输入、数据模型和数据表示的方式分开设计。

​ 一个交互式应用系统由**模型（Model）、视图（View）和控制器（Controller）**3个部件组成。

7.6 设计模式

1. 抽象工厂模式 (Abstract Factory)

介绍：
抽象工厂模式提供一个接口，用于创建一组相关或相互依赖的对象，而无需指定它们具体的类。适用于需要通过多个工厂来创建不同类型的对象时。

适用场景：

• 系统中有多个产品族，每个产品族包含一组相关的产品。
• 需要确保客户端始终使用相同系列的产品对象，且每个系列中的产品是相互兼容的。

例子：
假设开发一个跨平台的UI库，其中包括Windows、Mac和Linux版本的UI控件。你可以为每个平台创建一个具体的工厂类（WindowsFactory、MacFactory等），并通过抽象工厂来确保平台间的控件兼容。

---

2. 单例模式 (Singleton)

介绍：
单例模式确保一个类只有一个实例，并提供一个全局访问点。适用于需要共享全局资源时，确保只有一个实例存在。

适用场景：

• 系统中需要一个全局唯一的实例，如日志记录器、配置管理器或数据库连接池。

例子：
一个应用程序需要日志功能，不管程序运行多少次，日志类都应该只有一个实例，用于统一记录所有日志信息。这避免了重复创建多个日志实例。

饿汉式单例模式在类加载时就立即创建实例，确保线程安全，因为实例在类加载时就已经存在，避免了多线程访问时的竞争问题，但缺点是即使实例可能从未被使用，系统也会提前创建它，浪费内存资源。

懒汉式单例模式则是在首次访问时才创建实例，避免了饿汉式的内存浪费问题，但由于实例的创建时机不确定，为了保证线程安全，需要加锁。常见的加锁机制有 同步方法（锁住整个方法），或者 双重检查锁定（在创建实例前先检查一次，减少加锁的开销）。双重检查锁定能在实例未创建时加锁，创建后则避免重复加锁，提高性能，但使用时需要注意 volatile 关键字的使用，确保实例创建的正确性。

---

3. 外观模式 (Facade)

介绍：
外观模式提供一个统一的接口，简化复杂子系统的使用。它将复杂的子系统操作隐藏在一个简单的接口后面，便于客户端使用。

适用场景：

• 客户端需要与多个子系统进行交互，但不想暴露复杂的实现细节。
• 需要简化外部接口，减少系统间的耦合度。

例子：
在一个复杂的银行系统中，用户只需通过一个简单的“银行服务”接口完成存款、查询余额和转账操作，而不需要直接与账户、存款、查询等多个子系统打交道。

---

4. 适配器模式 (Adapter)

介绍：
适配器模式通过将已有的类的接口转换为客户端所期望的接口，从而使两个不兼容的接口能够协同工作。

适用场景：

• 系统需要与多个不同接口的类交互，但不能直接修改这些类。
• 当现有的类与系统不兼容时，需要通过适配器进行转换。

例子：
如果你正在开发一个支付系统，系统原本只支持支付宝和微信支付，但为了兼容一个新的支付方式（例如Apple Pay），你可以创建一个适配器，将Apple Pay的接口转换为系统原本的支付接口，使其能够正常工作。

---

5. 职责链模式 (Chain of Responsibility)

介绍：
职责链模式通过将请求沿着处理链传递，直到某个处理者处理该请求。它避免了请求发送者与处理者的紧密耦合。

适用场景：

• 多个对象可能处理某个请求，但请求的发送者不需要知道由哪个对象处理。
• 请求的处理可以按顺序传递，直到找到适合的处理者。

例子：
在客户支持系统中，客户的请求可以按顺序依次传递给不同的支持人员。例如，初步的查询可以由客户服务代表处理，复杂的问题由技术支持人员处理，最后如果仍未解决，可能由经理来处理。

---

6. 中介者模式 (Mediator)

介绍：
中介者模式将一组对象的交互关系封装在一个中介者对象中，从而减少对象之间的依赖，使它们通过中介者进行沟通。

适用场景：

• 系统中多个对象之间有复杂的交互关系，但希望减少对象间的依赖。
• 希望集中管理对象之间的协调与通信。

例子：
在一个航空系统中，飞行员与空中交通管制员、地面控制、飞机之间需要频繁沟通。通过中介者模式，所有的通信通过中央的“空中交通控制中心”进行，从而避免了各个对象之间的直接通信。

---

7. 观察者模式 (Observer)

介绍：
观察者模式定义了一种一对多的依赖关系，当一个对象状态发生变化时，所有依赖于它的对象都会自动得到通知并更新。

适用场景：

• 一个对象的状态改变时，所有依赖于它的对象都需要得到通知并做出响应。
• 多个对象之间需要共享状态变化，尤其是在事件驱动系统中。

例子：
在天气预报应用中，多个用户可能订阅了天气更新。当天气变化时，系统会通知所有订阅者，以便他们获得最新的天气信息。这里，天气对象是“被观察者”，而用户是“观察者”。

第8章 面向对象设计

8.1 面向对象设计过程与准则

8.1.2 面向对象设计准则

​ （1）模块化 （2）抽象 （3） 信息隐藏 （4） 弱耦合 （5）强内聚 分为：服务内聚、类内聚、一般-特殊内聚

8.8 对象设计

对象设计过程包括

​ **使用模式设计对象：**设计者选择合适设计模式，复用已有，提高系统灵活性。

​ 接口规格说明

​ **对象模型重构：**目的是改进对象设计模型，提高该模型的可读性和扩展性。

​ **对象模型优化：**改进，提高性能。

第9章 软件实现

程序效率： 代码效率分为：全局效率、局部效率、时间效率、空间效率。

第10章 软件测试方法

10.1 软件测试的基本概念

10.1.1 什么是软件测试

​ 软件测试是为了发现错误而执行程序的过程。

10.1.2 软件测试的目的和原则

​ 目的：
​ - 测试是程序的执行过程，目的在于发现错误。
​ - 一个好的测试用例在于能发现至今未发现的错误。
​ - 一个成功的测试是发现了至今未发现的错误的测试。

10.1.3 软件测试的对象

​ 所谓确认，是一系列的活动和过程，其目的是想证实在一个给定的外部环境中软件的逻辑正确性。

​ 所谓验证， 则试图证明在软件生存期各个阶段以及阶段间的逻辑协调性、完备性和正确性。

10.1.6 白盒测试与黑盒测试

黑盒测试： 已知产品的功能设计规格，可以通过测试证明每个实现了的功能是否符合要求。

白盒测试： 已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求。

10.2 白盒测试的测试用例设计

10.2.2 语句覆盖

​ 使得每一个可执行语句至少执行一次。

10.2.3 判定覆盖

​ 使得程序中每个判断的取真分支和取假分支至少经历一次。

10.2.4 条件覆盖

​ 使得程序中的每个判断的每个条件的可能取值至少执行一次

10.2.5 判定-条件覆盖

​ 使得判断中的每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果都至少执行一次。

10.2.6 条件组合覆盖

​ 使得每个判断的所有可能的条件取值组合至少执行一次。

10.3 基本路径覆盖

环路复杂度V（G）：

​ 1） 环路复杂性定义为控制流程图中的区域数。

​ 2） 设E为控制流图的边数，N为图中的节点数，则： V（G） = E - N + 2

​ 3） 设 P 为控制流图中的判定节点数，则： V（G） = P + 1

10.4 黑盒测试的测试用例设计

10.4.2 边界值分析

10.5 软件测试的策略

​ 3）路径测试 白盒

​ 5）边界测试 黑盒

10.5.2 组装测试

​ 1） 一次性组装方式

​ 2） 增殖式组装方式

	1. 自顶向下，采用桩模块
	1. 自底向上，不再使用桩模块
	1. 混合增殖式测试

10.5.3 确认测试

确认测试就是有效性测试（黑盒测试）

**α测试：**由一个用户在开发环境下进行的测试。

**β测试：**由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。

10.6.2 人工测试方法

​ 人工测试的方法主要有：桌面检查、代码审查和走查。

10.7.2 脚本技术

10.7.3 自动化测试框架及测试流程

第11章软件维护

11.6 软件的维护性

11.6.1 软件维护性定义

​ 软件的维护性包含以下的子特性：
​ 1. 易分析性
​ 1. 易变更性
​ 1. 稳定性
​ 1. 测试性
​ 1. 维护性符合性

第12章

12.3 软件过程成熟度

12.3.1 什么是软件过程成熟度

​ 软件过程成熟度是软件工程改进的一个重要概念，它是指：一个特定软件过程得到清晰的定义、管理、测量、控制以及有效的程度。

12.4 软件能力成熟度模型

12.4.1 CMM与SEI

12.4.3 CMM族和CMMI

CMMI模型的两种表示

CMMI对于软件过程的改进提供了两种不同的途径，即 连续式表示和分级式表示

分级式表示的成熟度等级，它所设置的成熟度等级共有5个。

12.5 软件过程改进

12.5.1 软件过程改进的IDEAL模型

美国卡内基·梅隆大学的软件工程研究所提出了IDEAL，由五个阶段构成：启动阶段、诊断阶段、建立阶段、行动阶段、提高阶段。

第13章

13.1 软件项目管理概述

13.1.2 软件项目管理设计的几个方面

​ 软件项目管理涉及的几个主要方面是人员、产品、过程和项目，即所谓4P（People，Product，Process，Project）。

填空题

1. 软件工程的核心目标是__________，即通过良好的工程方法提高软件的质量和开发效率。
   答案：软件质量
   注释：软件工程的核心目的是提高软件质量，通过系统化的工程方法（如设计、测试、管理）确保软件的可维护性、可靠性等。
2. 在软件开发生命周期中，__________阶段主要是需求分析和设计，定义系统的功能和架构。
   答案：需求分析
   注释：需求分析阶段的目标是明确客户的需求，并且基于这些需求进行系统的设计。它是开发过程的起点，决定着后续所有工作的方向。
3. 在软件工程中，__________模型通过将开发过程分为多个迭代周期，使得开发者可以更灵活地应对需求变化。
   答案：敏捷开发
   注释：敏捷开发是一种强调灵活、快速迭代、响应变化的开发模式。与传统的瀑布模型不同，它将开发分为小的周期（如每两周一次迭代），便于快速调整和改进。
4. 在面向对象的设计中，__________用于描述系统中的对象及其相互关系，通常通过UML类图来表示。
   答案：类
   注释：类是面向对象编程的基本单位，表示一组具有相同属性和方法的对象。UML类图用来表示类及其之间的关系，如继承、关联等。
5. __________是一种用于确定软件系统架构和设计决策的技术文档，它通常在软件开发的初期阶段产生。
   答案：架构设计文档
   注释：架构设计文档是软件开发过程中至关重要的文档之一，通常在项目的设计阶段进行制定，它定义了系统的整体结构和关键设计决策。
6. 在软件工程中，__________是一种为了确保软件质量和功能正确性而进行的验证工作，它通常由不同的测试阶段组成。
   答案：软件测试
   注释：软件测试是确保软件功能正确性、质量和性能的关键活动。它包括单元测试、集成测试、系统测试、验收测试等多个阶段。
7. __________模型是一种将软件开发过程划分为多个连续阶段的传统软件开发模型，这些阶段依次进行，前一个阶段完成后才能进入下一个阶段。
   答案：瀑布模型
   注释：瀑布模型是软件开发中的一种传统开发模型，它将开发过程分为需求分析、设计、编码、测试等阶段，每个阶段的结果需要完全完成才能进入下一个阶段。
8. __________原则是指在软件设计中，应该尽量减少不同模块之间的依赖性，使得模块能够独立变化。
   答案：低耦合
   注释：低耦合是面向对象设计中的一个重要原则，指的是不同模块或类之间的依赖关系要尽量减少。这样能够提高系统的可维护性和可扩展性。
9. 在软件开发中，__________用于表示系统需求、设计、代码及其行为的相互关系，是支持软件开发和维护的重要工具。
   答案：文档
   注释：文档在软件开发中起到记录需求、设计、实现和测试过程的重要作用。它帮助团队成员之间共享信息，并且在软件维护阶段提供必要的参考。
10. __________是指开发人员在代码开发过程中，通过将自己编写的代码与现有代码集成，确保功能正常并修复潜在缺陷的过程。
    答案：持续集成
    注释：持续集成是一种软件开发实践，指开发人员频繁地将代码集成到共享的代码库中。每次集成都伴随着自动化测试，以便尽早发现和解决问题。

好的，以下是另外 10 道软件工程填空题，并附上答案和注释：

填空题

1. 在软件开发过程中，__________用于控制软件项目的进度、成本和质量，确保项目按时交付。
   答案：项目管理
   注释：项目管理涵盖了对项目进度、预算、质量和资源的规划、执行和监控，确保软件项目按预定目标顺利完成。
2. __________分析是指对软件的需求进行详细分解和建模，通常使用用例图、类图等工具来表达需求。
   答案：需求
   注释：需求分析是软件工程中的第一步，涉及到对客户需求的准确理解和详细定义。它通过不同的建模工具帮助开发团队清晰了解需求。
3. __________是一种软件设计原则，旨在将代码的功能划分为多个小模块，每个模块独立完成特定的功能。
   答案：单一职责原则
   注释：单一职责原则（SRP）是面向对象设计中的一个重要原则，主张每个类或模块应该只负责一项功能，从而提高代码的可维护性和可扩展性。
4. 在软件项目管理中，__________是对项目目标、任务和风险的评估，通常在项目启动阶段进行。
   答案：可行性分析
   注释：可行性分析帮助团队评估项目的技术可行性、经济可行性和操作可行性，确保项目在开始前是现实可行的。
5. 在面向对象编程中，__________是一种将公共功能提取到基类中的技术，使得子类可以继承这些功能。
   答案：继承
   注释：继承是面向对象编程的重要特性，允许子类继承父类的属性和方法，实现代码复用和功能扩展。
6. 在软件开发过程中，__________通常用于跟踪和管理软件中的错误和缺陷，确保它们能够及时被修复。
   答案：缺陷跟踪
   注释：缺陷跟踪是软件质量保证的一部分，它通过管理缺陷的报告、修复和验证过程，确保软件达到预期的质量标准。
7. __________模式用于确保一个类只有一个实例，并提供一个全局访问点，避免了实例化多次。
   答案：单例模式
   注释：单例模式确保类的唯一实例，并通过一个全局的访问点提供对该实例的访问。它通常用于需要全局共享资源的场景，如配置管理和数据库连接。
8. 在软件测试中，__________测试是指在软件开发的初期进行的测试，通常由开发人员进行，用于检测单个模块的功能是否正常。
   答案：单元测试
   注释：单元测试是软件开发中的一个基本测试阶段，重点是验证单个模块或函数的正确性，通常由开发人员进行。
9. __________是一种通过模拟实际用户操作来测试软件系统行为的测试方法，常用于验证系统的功能性和用户体验。
   答案：功能测试
   注释：功能测试用于检查软件系统是否按照需求正确工作，通常包括界面测试、功能验证等，确保软件符合用户需求。
10. __________是一种通过将多个独立的子系统封装在一起，使它们能够与外部系统进行协作的设计模式。
    答案：外观模式
    注释：外观模式为复杂系统提供一个简化的接口，将多个复杂的子系统操作封装在一个统一的接口中，简化了客户端的使用

好的，以下是整理后的 10 个填空题及答案：

1. 软件是____、数据及相关文档的完整集合。

答案：程序
解释：软件不仅包括程序代码本身，还包括与其相关的数据（如配置文件、数据库）以及设计文档、用户手册等其他文档。

2. 决定软件可维护的因素有以下 5 个：可理解性、可测试性、___、可修改性和可重用性。

答案：可扩展性
解释：软件的可维护性与其可理解性、可测试性、可扩展性、可修改性和可重用性紧密相关。

3. 目前使用最广泛的软件工程方法学，分别是传统方法学和___。

答案：敏捷方法学
解释：传统方法学（如瀑布模型）强调过程的顺序性，而敏捷方法学则更加灵活，注重快速迭代和响应需求变化。

4. 瀑布模型由__驱动。

答案：需求
解释：瀑布模型按照严格的顺序执行，每个阶段都基于前一个阶段的输出，需求是驱动整个过程的基础。

5. RUP将软件生命周期分为 4 个连续的阶段，分别是____、精化阶段、构建阶段和______。

答案：初始阶段、交付阶段
解释：RUP（统一过程）方法将开发过程分为初始阶段、精化阶段、构建阶段和交付阶段，每个阶段具有明确的目标和任务。

6. 数据流图中的元素包括数据源/终点、交换数据的处理、___和数据流。

答案：数据存储
解释：数据流图描述了系统中数据的流动，包括数据源/终点、处理过程、数据存储和数据流。

7. 在数据字典中，1(数字)4描述的数据范围是_____。

答案：从 1 到 4
解释：数据字典中通常用类似 “1(数字)4” 的表示来描述数据的值域或取值范围。

8. 面向对象实现主要包括两项工作：将面向对象设计结果翻译成某种程序语言书写的面向对象程序；________。

答案：面向对象程序的测试与调试
解释：面向对象实现过程包括将设计转化为代码，并对代码进行测试和调试，确保系统功能正确。

9. 常用的软件成本估计方法由_________、任务分解技术和自动估计成本技术组成。

答案：类比估算
解释：常用的成本估算方法包括类比估算、任务分解和自动估计技术，类比估算通过参考类似项目来进行预测。

10. 测试单个类的方法主要有随机测试、_______和基于故障的测试。

答案：边界值测试
解释：测试单个类的方法包括随机测试、边界值测试和基于故障的测试，边界值测试关注输入数据的极限值和临界值。

1. 程序的三种基本控制结构是

答案：顺序结构、选择结构、循环结构
解释：程序的三种基本控制结构是顺序结构（按顺序执行）、选择结构（根据条件判断执行路径）、循环结构（重复执行某一段代码，直到满足特定条件）。

2. 软件测试中，白盒法通过分析程序的（）来设计测试用例

答案：内部结构
解释：白盒测试关注程序的内部结构和实现逻辑，通过分析代码的控制流、数据流等信息来设计测试用例。

3. 软件生命周期中花费最多的阶段是什么

答案：维护阶段
解释：在软件生命周期中，维护阶段通常占据了大部分的时间和成本，因为它涉及到修复缺陷、应对需求变化、优化性能等。

4. 以下哪个模型不属于我们常说的面向对象建模的 3 种模型范围

答案：D. 功能模型
解释：面向对象建模通常包括对象模型、动态模型和结构模型，而功能模型更多用于功能驱动的开发方法。

5. 确认测试主要涉及的文档是（）

答案：A. 需求规格说明书
解释：确认测试是用来验证软件是否满足需求规格说明书中定义的需求，因此需求规格说明书是主要文档。

6. 模块的内聚性最高的是（）

答案：D. 功能内聚
解释：功能内聚是指模块内部的所有元素都集中在执行一个具体功能上，是内聚性最强的类型。

7. 详细设计的目的是确定整个系统的（）

答案：B. 功能及模块结构
解释：详细设计的目的是根据需求分析结果，确定系统的具体实现方式、功能分配和模块结构。

8. 详细设计的结果基本决定了最终程序的（）

答案：D. 可维护性
解释：详细设计的结果直接影响程序的可维护性，因为合理的模块划分和结构设计能使程序易于理解和维护。

9. 模块彼此传递的信息中有控制信息，这种合称为（）

答案：D. 控制耦合
解释：控制耦合是指模块之间传递控制信息（如标志位），这种信息决定模块的执行方式。

10. 软件（）是程序在给定的时间点，按照规格说明书的规定成功地运行的概率

答案：B. 可靠性
解释：可靠性是指软件在给定时间内、特定条件下能按规格说明书要求成功运行的能力或概率。

以下是你提供的判断题整理及答案：

1. 分层的 DFD 图可以用于可行性分析阶段，描述系统的物理结构，对不对

答案：错
解释：分层的数据流图（DFD）主要用于描述系统的功能性需求和数据流动，而不是物理结构。它在可行性分析阶段的作用是帮助理解系统的功能，而不是描述系统的物理结构。

2. Jackson 图只能表达程序结构，不能表达数据结构，对不对

答案：错
解释：Jackson图可以用于描述数据结构和程序结构，特别适用于描述数据流和控制流之间的关系。因此，它不仅能够表达程序结构，还能表达数据结构。

3. 开发软件时投入人员越多、时间越短，对不对

答案：错
解释：这是一个典型的"布鲁克斯定律"（Brooks’s Law），即增加开发人员并不一定能加快开发进度，反而可能因为人员间的协调和沟通成本增加，导致进度延误。开发进度取决于团队的协作效率，而不仅仅是人员的数量。

4. 自顶向下的测试方法的特点是，不需要存根程序，对不对

答案：错
解释：自顶向下测试方法通常需要使用存根程序（Stub）来模拟尚未完成的模块。存根程序用来填充被测试模块尚未实现的部分，以便可以进行上层模块的测试。

5. 完成测试后，为缩短源程序长度而删除注解，不影响维护，对不对

答案：错
解释：删除注解会影响程序的可维护性，因为注解提供了代码的解释和注释，帮助开发人员理解代码的设计思路和实现逻辑。删除注解可能导致将来对代码的理解变得更加困难，从而影响维护工作。

6. 面向对象方法中继承耦合越松散越好，对不对

答案：对
解释：面向对象的设计中，继承关系应该保持松散耦合。继承耦合越松散，模块之间的依赖性越小，系统的可扩展性和可维护性就越高。过于紧密的继承关系可能导致代码的可重用性降低，且修改一个类可能影响到许多子类，增加了维护的难度。

7. 只有质量差的软件才需要维护，对不对

答案：错
解释：即使是高质量的软件也需要维护。软件维护不仅包括修复缺陷，还包括适应新的需求、环境变化以及性能优化等。因此，维护是软件生命周期的一部分，而不仅仅是质量差的软件所需。

8. 设计得好的软件，结构通常顶层扇出比较高，中层扇出比较少，底层扇入到公共模块中去，对不对

答案：对
解释：一个设计得好的软件系统通常具有高层模块负责大范围的抽象与控制，扇出较高，而中层和底层模块专注于具体实现，扇出较少。底层模块通过扇入方式访问公共模块，这样有助于减少重复代码和增强代码的可重用性。

9. Beta 测试由用户在开发者的场所进行，并且在开发者对用户的指导下进行测试，对不对

答案：错
解释：Beta 测试通常是在开发者的场所之外进行，由实际用户在真实环境中使用软件并反馈问题。Beta 测试是产品发布前的用户测试，用户在开发者指导下进行测试的描述更符合Alpha 测试。

10. 一张状态图中可以有多个初态，多个终态，对不对

答案：对
解释：在状态图中，一个系统可能存在多个初态和终态。多个初态表示系统可以从不同的初始状态开始，而多个终态表示系统可以达到不同的最终状态。状态图的设计允许系统有多个可能的起始和终止条件。

1. 采用边界值分析法设计的测试用例

对于函数 f(x,y)f(x, y)，其中 x∈[100,200]x \in [100, 200]， y∈[10,50]y \in [10, 50]，采用边界值分析法（Boundary Value Analysis）来设计测试用例时，我们主要关注的是区间的边界值和其临近值。边界值分析的原理是测试用例应集中在边界及其附近的值。

边界值分析法设计的测试用例：

• x 的边界值：
  • 最小值：x=100x = 100
  • 最大值：x=200x = 200
  • 临界值：x=101x = 101 和 x=199x = 199（即分别是最小值加1和最大值减1）
• y 的边界值：
  • 最小值：y=10y = 10
  • 最大值：y=50y = 50
  • 临界值：y=11y = 11 和 y=49y = 49（即分别是最小值加1和最大值减1）

测试用例：

测试用例编号	x 值	y 值	备注
TC1	100	10	边界值最小值
TC2	200	10	边界值最大值，y=10
TC3	100	50	边界值最小值
TC4	200	50	边界值最大值
TC5	101	10	临界值测试
TC6	199	10	临界值测试
TC7	100	11	临界值测试
TC8	200	49	临界值测试
TC9	150	30	中间值测试

这些测试用例覆盖了所有的边界值和临界值，确保在这些极端情况时函数行为是正确的。

---

2. 什么是软件危机？软件危机通常有哪些表现？

软件危机的定义：

软件危机是指随着计算机技术的发展，软件系统的规模和复杂性急剧增加，传统的开发方法和工具无法满足对高质量、高可靠性软件的需求，导致了大量的开发、维护、管理困难，甚至失败，给企业和社会带来严重影响的现象。

软件危机的表现：

• 软件项目超期：开发周期过长，项目常常无法按时完成。
• 预算超支：开发成本超出预算，造成企业经济损失。
• 软件质量差：程序出现大量的缺陷，系统不稳定，容易崩溃，用户体验差。
• 软件维护困难：随着软件系统的复杂度增加，维护变得异常困难，甚至无法有效地修复和更新系统。
• 需求变化频繁：随着市场需求的快速变化，软件系统难以适应需求的变更，导致开发过程中多次修改。
• 人才短缺：由于软件开发涉及的技术和知识越来越复杂，缺乏足够的高素质开发人员和管理人员。

---

好的，我已经根据你提供的信息更新了第三问的答案，以下是常见的软件过程模型及其优缺点：

3. 常见的软件过程模型及其优缺点

1. 瀑布模型（Waterfall Model）

• 优点

  ：

  • 简单易理解：瀑布模型是一种线性过程，易于理解和实施。
  • 明确的阶段：每个阶段都有明确的目标和成果，便于管理和控制。
  • 文档化：每个阶段都需要文档输出，便于后期的回溯和维护。

• 缺点

  ：

  • 缺乏灵活性：一旦进入某个阶段后，难以返回修改，缺乏对需求变化的适应性。
  • 难以处理不明确的需求：项目初期需要明确的需求，若需求模糊或不完整，后期很难修正。
  • 晚期测试：测试通常在开发完成后才开始，可能导致问题在后期发现，修复成本高。

2. 快速原型模型（Rapid Prototyping Model）

• 优点：
  • 快速反馈：通过创建原型让用户尽早体验产品，获得快速反馈，帮助明确需求。
  • 减少需求不明确性：通过原型演示帮助客户明确需求，避免需求模糊。
  • 提高用户满意度：用户能尽早看到产品的功能和界面，提升客户满意度。
• 缺点：
  • 可能产生不完美的原型：原型的质量可能会影响系统的最终实现，导致不完整或不高效。
  • 高成本：多次的原型开发可能导致资源浪费，增加开发成本。
  • 无法适应复杂系统：适合小规模、功能明确的项目，对于大型复杂系统难以操作。

3. 增量模型（Incremental Model）

• 优点

  ：

  • 逐步交付：系统可以分阶段逐步交付，先交付核心功能，再添加其他功能。
  • 适应需求变化：可以根据用户反馈及时调整，适应需求变化。
  • 早期交付可用版本：开发过程中早期可以得到可运行的部分系统，增加客户满意度。

• 缺点

  ：

  • 可能会重复工作：一些模块可能在不同增量中多次开发和测试。
  • 需要高水平的管理：需要精确的规划和管理，以确保各个增量模块能够无缝集成。

4. 螺旋模型（Spiral Model）

• 优点：
  • 风险管理：通过每个迭代阶段的风险评估和反馈，能够有效管理风险。
  • 灵活性高：适应需求变化，并且能够逐步改进和扩展。
  • 早期识别问题：通过持续的反馈，能够在早期识别问题并进行修正。
• 缺点：
  • 复杂性高：每个阶段都需要详细的风险评估和文档支持，增加了管理复杂性。
  • 高成本：持续的风险评估和反馈可能导致项目成本和时间开销较大。

5. 喷泉模型（Fountain Model）

• 优点：
  • 灵活性强：像瀑布模型一样按阶段进行，但开发人员可以在多个阶段之间自由地回溯和前进。
  • 强调并行开发：可以并行进行各个开发阶段，减少整体时间。
• 缺点：
  • 缺乏严格的阶段划分：由于阶段之间可以自由回溯，可能导致缺乏清晰的流程控制。
  • 难以管理：多个并行活动可能导致管理上的困难，尤其是对于大型项目。

6. 统一过程（Unified Process, UP）

• 优点：
  • 迭代开发：统一过程采用迭代和增量开发，能够灵活应对需求变化。
  • 关注架构设计：强调软件架构的重要性，有助于提高系统的可扩展性。
  • 客户反馈：通过多个迭代周期，客户可以在每个阶段提供反馈，改进产品。
• 缺点：
  • 实现复杂：过程框架较为复杂，需要较高的项目管理能力和成熟的开发团队。
  • 需要高水平的文档化：每个迭代阶段都需要较多的文档支持，增加了开发的文档负担。

7. 基于构件的开发模型（Component-Based Development, CBD）

• 优点：
  • 重用现有组件：可以利用已有的软件组件，降低开发成本和时间。
  • 提高开发效率：使用现成的构件可以加快系统开发速度。
  • 系统可扩展性强：组件化设计使得系统更易于扩展和维护。
• 缺点：
  • 组件质量难以保证：使用第三方组件时，可能会遇到质量问题或兼容性问题。
  • 依赖于组件市场：需要依赖成熟的组件市场，如果缺乏合适的组件，则可能无法实现预期效果。

8. 敏捷过程（Agile Process）

• 优点：
  • 快速响应变化：敏捷开发特别适合需求变化频繁的项目，能够在短时间内迭代更新。
  • 客户参与度高：通过频繁的客户反馈，保证开发与用户需求一致。
  • 提高团队协作：强调团队成员之间的协作与沟通，增强团队的灵活性和响应能力。
• 缺点：
  • 文档较少：敏捷开发强调快速交付和客户反馈，可能导致文档不够完整，影响长期维护。
  • 不适合大型项目：对于大型复杂项目，敏捷可能难以有效组织和管理。
  • 需要高水平的团队能力：敏捷要求团队成员有较高的技能水平和自我管理能力，缺乏经验的团队可能难以成功实施。