软件工程 课堂测验 选择填空

系统流程图用图形符号表示系统中各个元素，表达了系统中各个元素之间的 信息流动

喷泉模型是一种以用户需求为动力，以 对象 为驱动的模型。

软件生存周期中最长的是 维护 阶段。

变换流的DFD由三部分组成，不属于其中一部分的是 事务中心

软件需求规格说明书的内容不应该包括 对算法的详细过程描述

为解决一个复杂问题，往往采取的策略是 自顶向下、逐步分解

需求分析阶段不适用于描述加工逻辑的工具是 流程图
解释：
通常会使用用例图来描述系统的功能和角色之间的交互，使用需求文档和用户故事来详细描述各个功能需求和用户需求
流程图主要用于展示系统的操作流程和控制逻辑，它更适合用于系统设计和开发的阶段

结构化设计方法在软件开发中，用于 软件概要设计

网站系统是一个典型的 瘦客户端/服务器结构

增量模型是一种 非整体开发 模型。

属于软件设计的基本原理是 模块化

对于分层的DFD，父图与子图的平衡指子图的输入、输出数据流同父图相应加工的输入、输出数据流 必须一致
解释：
以下是为什么平衡必须保持一致的几个原因：
数据完整性：平衡确保了数据的完整性。如果子图的输入和输出数据流与父图不一致，就会导致数据丢失或错误，破坏了系统中数据的连贯性和完整性。
功能正确性：平衡可以确保功能正确性。系统的每个子图代表一个特定的功能模块，子图的输入数据流是该模块的输入，输出数据流是该模块的输出。如果子图的输入和输出数据流与父图不一致，就无法正确执行功能，导致系统功能错误或不完整。
信息传递：平衡有助于确保信息正确传递。父图的输出数据流是子图的输入数据流，这意味着父图传递给子图的信息必须与子图所期望的一致。如果输入数据流不一致，子图可能无法正确理解和处理来自父图的信息。
逻辑一致性：平衡可以保持逻辑的一致性。父图和子图之间的平衡要求输入和输出数据流的命名和定义在整个系统中保持一致。这有助于减少歧义和混乱，提高系统的可理解性和可维护性。

数据词典中有四类条目，分别是 数据流、 数据项、 数据存储、 加工。

划分模块时，一个模块的 作用范围应在其控制范围内

与计算机科学的理论研究不同，软件工程是一门 工程性 学科。

软件工程的三要素是 方法、工具、过程

可行性研究具体步骤的最后一步是 编写可行性报告

准确地解决“软件系统必须做什么”是 需求分析 阶段的任务。

瀑布模型存在的问题是 缺乏灵活性

好的软件结构应是 低耦合、高内聚

分层DFD是一种比较严格又易于理解的描述方式，它的顶层图描述了系统的 输入与输出
解释：
在分层DFD中，系统的顶层称为“顶层图”或“0级图”，它表示系统的总体功能和数据流。顶层图可以进一步分解为多个子图，每个子图代表一个具体的功能模块。子图可以继续分解为更低层次的子图，以达到更细粒度的描述。

结构化程序设计的一种基本方法是 逐步求精法
解释：
结构化程序设计是一种以模块化和层次化为基础的软件设计方法，旨在提高程序的可读性、可维护性和可测试性。
逐步求精是法指将复杂的问题分解为一系列更小的、可处理的子问题。通过逐步求精，可以将复杂的任务转化为一系列简单的、容易实现和验证的子任务。这种自底向上的方法可以提高程序设计的可控性和可靠性。

需求分析阶段产生的最重要的文档是 需求规格说明书

程序的三种基本控制结构是 顺序、选择、重复
解释：
选择有：switch、if
重复有：while、for

结构化设计以 数据流图 为基础映射成软件结构。
解释：
数据流图（Data Flow Diagram，简称DFD）是一种用于描述系统功能和数据流动的图形工具。它是一种图形化的、层次化的系统分析方法，用于表示系统内部的数据流动、处理过程和数据存储。
数据流图通过使用不同的符号和图形元素，以图形化的方式描述了系统的功能和数据流动，有助于分析系统的结构和逻辑关系。
数据流图主要包含以下几个元素：
外部实体（External Entity）：外部实体表示与系统进行交互的外部对象，如用户、其他系统或设备等。外部实体可以是数据流图的输入源或输出目标。
进程（Process）：进程表示系统内部的功能模块或处理过程，它接受输入数据流，进行处理，并产生输出数据流。进程通常用简单的动词短语来描述其功能。
数据流（Data Flow）：数据流表示数据在进程之间流动的路径。数据流可以是输入数据流，从外部实体输入系统；也可以是输出数据流，从系统输出到外部实体；还可以是内部数据流，用于在系统内部不同的进程之间传递数据。
数据存储（Data Store）：数据存储表示系统内部用于存储数据的位置，如数据库、文件或内存等。数据存储通常用一个矩形框表示。

程序的三种控制结构的共同特点是 只有一个入口和出口
解释：
顺序结构表示程序按顺序执行，从结构的入口开始顺序执行每一条语句，直到结构的出口。
选择结构（如if语句）根据条件的真假选择不同的路径执行，但无论选择哪个分支，都只有一个入口和一个出口。
重复结构（如循环语句）表示一段代码块会被重复执行，但仍然只有一个入口和一个出口。

UML 是软件开发中的一个重要工具，它主要应用于 基于对象的面向对象方法
解释：
UML最初就是为了支持面向对象方法而开发的，因此它主要用于描述和设计基于对象的系统结构、行为和交互。
UML提供了多种类型的图表，主要包括以下几种：
结构图：如类图、对象图、组件图、部署图等，用于描述系统的静态结构和组件之间的关系。
行为图：如用例图、活动图、状态图、时序图等，用于描述系统的行为、交互和动态变化过程。
交互图：如时序图和通信图，用于描述对象之间的消息传递和交互过程。
构建图：如包图、部署图，用于描述系统的物理构建和部署情况。

面向对象的动态模型中，每张状态图表示 某一个类 的动态行为
解释：
面向对象的动态模型中，每张状态图代表着某一个类的动态行为，展示了对象在不同状态下的行为转换和事件响应。

白盒法又称为逻辑覆盖法，主要用于 单元测试
解释：
白盒测试：白盒测试是一种基于代码内部结构和逻辑的测试方法，测试人员需要了解被测试软件的内部结构和实现细节。在白盒测试中，测试人员会针对代码的逻辑路径、条件和数据流进行测试，以确保程序的每个逻辑路径都得到覆盖，并且所有的分支和条件都被正确执行。
逻辑覆盖测试：逻辑覆盖测试是白盒测试的一种具体实践，它侧重于测试代码中的各种逻辑情况，例如条件语句的真假分支、循环的执行次数等。逻辑覆盖测试旨在确保代码中的所有逻辑条件和情况都得到覆盖和测试，以验证程序在不同情况下的正确性和稳定性。
主要用于单元测试：单元测试是软件测试中的一种级别，用于验证程序中的最小可测试单元（通常是函数或方法）的正确性。白盒测试和逻辑覆盖测试通常用于单元测试阶段，以确保被测试的代码在逻辑上是正确的，并且覆盖了所有可能的路径和情况。
因此，白盒测试（逻辑覆盖测试）主要用于单元测试阶段，通过深入了解代码的内部逻辑和结构来验证程序的正确性。这种测试方法有助于发现代码中隐藏的逻辑错误和边界情况，提高软件的质量和稳定性。

面向对象的主要特征除了对象唯一性、封装和继承外，还有 多态性

对象模型的描述工具是 类图
解释：
类图的基本元素：
类（Class）：类是对象模型中的基本构建单元，用于表示具有相似属性和行为的对象的集合。在类图中，类通常以矩形框表示，框内包含类的名称。
属性（Attribute）：属性表示类的特征或状态，例如对象的数据成员。在类图中，属性通常以名称和类型的形式列在类的顶部。
方法（Method）：方法表示类的行为或操作，即对象可以执行的操作。在类图中，方法通常以名称和参数列表的形式列在类的中部。
关联（Association）：关联表示类之间的关系，即一个类与另一个类之间的连接。关联可以是双向的，也可以是单向的。在类图中，关联通常以实线连接类之间，并可以添加角色名称来描述关联的含义。
继承（Inheritance）：继承表示类之间的继承关系，其中一个类（子类）可以继承另一个类（父类）的属性和方法。在类图中，继承关系通常用带箭头的实线表示，箭头指向父类。
接口（Interface）：接口定义了一组方法，表示某个类或对象所能提供的服务。在类图中，接口通常以带有<>标记的矩形框表示。
类图的使用：
类图用于可视化和描述面向对象系统的结构，可以帮助开发人员更好地理解系统的设计和架构。
类图可以用于指导编码过程，帮助开发人员明确各个类的属性、方法和关系，从而更高效地实现系统功能。
类图还可以用于沟通和交流，开发团队可以通过类图共享和讨论系统设计，以确保大家对系统的理解一致。

在考察系统的一些涉及时序和改变的状况时，要用动态模型来表示。动态模型着重干系统的控制逻辑，它包括两个图:一个是事件追踪图，另一个是 状态图。
解释：
事件追踪图（Event Trace Diagram）：
事件追踪图用于描述系统在特定事件序列下的行为和相互作用。它展示了系统中各个对象之间的消息传递和交互过程，以及这些交互是如何随时间推移而发生的。
在事件追踪图中，通常会标识出事件的发生顺序，包括事件的触发、对象之间的消息传递和处理过程等。通过事件追踪图，可以清晰地了解系统在特定事件序列下的行为和交互方式，有助于发现潜在的问题和优化系统设计。
状态图（State Diagram）：
状态图用于描述对象在其生命周期内所经历的不同状态以及状态之间的转换规则。它展示了系统中各个对象的状态变化以及导致状态变化的事件或条件。
在状态图中，通常会使用状态框表示对象可能处于的状态，以及使用转换箭头表示对象在不同事件或条件下从一个状态转换到另一个状态。状态图可以帮助人们理解系统中对象的行为模式，并可用于指导系统逻辑的设计和实现。

黑盒测试是从 用户 观点的测试，白盒测试是从 开发人员 观点的测试。
解释：
黑盒测试（Black Box Testing）：
黑盒测试是一种基于软件外部功能和需求规格的测试方法，测试人员无需关注软件内部的实现细节和代码结构，而是将软件看作一个黑盒子，只关注输入和输出之间的关系。
在黑盒测试中，测试人员根据软件的需求规格、用户手册或其他文档，设计测试用例并执行测试，以验证软件在各种输入条件下是否能正确输出预期的结果。
黑盒测试主要关注功能性、性能、用户界面等方面的测试，以确保软件符合用户的需求和预期行为。
白盒测试（White Box Testing）：
白盒测试是一种基于软件内部结构和代码逻辑的测试方法，测试人员需要深入了解软件的内部实现，包括代码结构、逻辑路径、数据流等方面。
在白盒测试中，测试人员可以查看和分析软件的源代码，并设计测试用例来覆盖不同的代码路径和逻辑分支，以验证软件的正确性、可靠性和安全性。
白盒测试通常关注代码覆盖率、路径覆盖率、逻辑覆盖等指标，以发现可能存在的程序错误、逻辑缺陷或安全漏洞。

面向对象技术中，对象是类的实例。对象有 3 种成分：封装、属性、方法 (或操作)。
解释：
封装（Encapsulation）：
封装是面向对象编程的核心概念之一，通过将数据和对数据的操作封装在对象内部，实现了数据的隐藏和保护。对象将数据和相关的操作封装在一起，外部只能通过对象提供的接口来访问和操作数据。
封装能够隐藏对象内部的实现细节，使得对象的使用者只需要关注对象提供的公共接口，而不需要了解对象内部的具体实现。这提高了代码的可维护性和可复用性，并提供了更好的软件模块化和组织方式。
属性（Properties）：
对象的属性是描述对象状态的特征或数据。属性可以是各种类型的数据，如整数、字符串、布尔值等。对象的属性表示对象当前的状态和特征。
例如，对于一个"人"类的对象，属性可以包括姓名、年龄、性别等。这些属性描述了人对象的基本信息。
方法（Methods）或操作（Operations）：
对象的方法是对象可以执行的操作或行为。方法定义了对象的行为和功能，用于实现对象的各种操作和逻辑。
方法可以对对象的属性进行读取、修改或执行其他操作。通过调用对象的方法，可以实现对对象内部状态的处理和控制。
例如，对于一个"人"类的对象，方法可以包括吃饭、睡觉、工作等。这些方法定义了人对象可以执行的不同行为。
通过封装、属性和方法，对象实现了数据和行为的封装，使得对象成为一个独立的、具有特定功能和行为的实体。

黑盒测试方法根据 软件要完成的功能 设计测试用例。

面向对象的分析方法主要是建立3 类模型，即 对象模型、动态模型、功能模型
解释：
对象模型
对象模型是对软件系统中涉及的实体或对象进行建模的过程，它主要描述了系统中各个对象的属性和行为。在对象模型中，每个对象都有其自身的属性和方法，并且对象之间可以相互协作、交互。
动态模型
动态模型描述了软件系统中各个对象之间的时序关系以及对象的状态转换。动态模型主要包括用例图、活动图、状态图等模型，用于描述对象之间的交互和行为。
功能模型
功能模型描述了系统的功能和操作，它主要包括数据流图和功能分解图。数据流图表示系统中数据的流动和处理过程，而功能分解图则描述了系统的层次结构和功能划分，从而帮助开发人员更好地理解和实现系统的功能。

面向对象分析的首要工作是建立 问题的对象模型

成功的测试是指运行测试用例后 发现了程序错误
软件测试的目的是 发现软件的错误

影响软件可维护性的主要因素不包括 可用性
解释：
当他讨论软件可维护性的时候，软件本身已经处于可用状态，故而不需要讨论软件的可用性

软件工程针对维护工作的主要目标是提高软件的可维护性，降低 维护的工作量
解释：
降低维护的工作量是指通过改进软件设计和实现，使得未来对软件系统的维护工作更加高效、更少繁琐。这包括减少维护过程中需要花费的时间和人力成本，提高维护过程中的生产率和效率。
相比之下，降低维护的效率或代价更多地关注的是当前维护活动的具体成本和效率问题。而软件工程更关注的是在软件整个生命周期内，通过提高软件的可维护性，从根本上减少未来维护所需的工作量和成本，使得软件系统更加容易被理解、修改和扩展。
因此，软件工程更注重的是通过提高软件的可维护性来减少未来维护的工作量，以此来确保软件系统长期的健康发展，而非只关注当前维护活动的效率或成本。

软件测试可能发现软件中的 错误，但不能证明软件 没有错误。

功能模型中所有的 数据流图 往往形成一个层次结构，在这个层次结构中一个数据流图的过程可以由下一层数据流图做进一步的说明。
解释：
层次结构的数据流图以顶层数据流图开始，描述系统的整体功能。随后，顶层数据流图中的各个功能可以进一步展开为更详细的子功能，形成下一层数据流图。这些子功能可以是对更具体的功能进行拆分，或者是对某个功能的更详细描述。
通过层次结构，每个数据流图都可以展示系统的某个特定层次的功能和过程。顶层数据流图提供了对整个系统的宏观视角，而下一层数据流图则提供了对系统各个部分或功能的更详细的了解。
层次结构的好处在于，它能够将系统的功能和过程按照层级进行组织，使得系统的复杂性得到了分解和管理。同时，通过每个数据流图之间的嵌套关系，可以实现对系统不同层次的功能的逐步细化和明确化。
总结来说，数据流图中的层次结构可以让我们逐层展开对系统功能和过程的描述，从宏观到微观逐步细化，使得系统的功能和过程更加清晰可见。每个数据流图都可以由下一层数据流图进一步解释，帮助我们更好地理解和设计系统。

封装 是把对象的属性和操作结合在一起，构成一个独立的对象，其内部信息对外界是隐藏的，外界只能通过有限的接口与对象发生联系。

面对对象设计阶段的主要任务是系统设计和 对象设计
解释：
系统设计和对象设计是紧密相关的，系统设计提供了整体框架和指导，为对象设计提供了上下文和约束条件。对象设计则是在系统设计的基础上，对具体的对象进行深入的设计和实现。系统设计和对象设计相互交织，通过迭代和反馈，逐步完善和优化系统的设计。
系统设计
是指对整个软件系统进行高层次的设计，从整体上考虑系统的结构、功能和性能等方面。系统设计关注的是系统的整体框架和组织结构，以及系统与外部环境的交互。在系统设计阶段，需要确定系统的模块划分、模块之间的协作关系、数据流和控制流等。系统设计的目标是确保系统的功能和性能得到满足，并且为后续的对象设计提供基础。
对象设计
是在系统设计的基础上，进一步对系统中的各个对象进行详细设计。对象设计关注的是如何将系统的功能划分为各个对象，并定义对象的属性、行为和关系。在对象设计阶段，需要考虑对象的接口、内部实现、对象之间的关联和依赖关系等。对象设计的目标是确保每个对象都具有清晰的责任和职责，并且能够有效地协作和交互。

使用软件时提出增加新功能，就必须进行 完善性 维护
解释：
完善性维护包括以下主要活动：
分析用户需求：开发团队需要与用户进行沟通和交流，深入理解用户提出的新功能需求，并将其转化为具体的软件系统要求。
设计修改方案：基于用户需求，开发团队需要进行系统设计，确定如何添加新功能或改进现有功能。这可能涉及对系统架构、模块划分、数据结构等方面的调整。
修改代码：开发团队根据设计方案对软件系统的源代码进行修改。这可能包括添加新的代码模块、修改现有的代码逻辑、调整数据流和控制流等。
单元测试：在进行修改后，开发团队需要进行单元测试，验证修改后的功能是否符合预期，并确保不会引入新的错误或问题。
综合测试：修改后的软件系统需要进行综合测试，以验证整体功能和性能是否满足用户需求，并与其他模块进行集成测试。
发布和部署：完成维护后，开发团队将修改后的软件系统发布和部署，使用户可以使用新功能或改进的版本。
完善性维护是软件开发过程中不可或缺的一环。通过增加新功能和改进现有功能，软件系统可以不断适应用户需求的变化，并提供更好的用户体验和价值。同时，完善性维护也需要注意对现有功能的稳定性和兼容性的保护，以确保修改不会破坏原有的功能和系统稳定性。

不是面向对象的特征的是 过程调用
解释：
面向对象的特征：封装、继承、多态、对象唯一性

软件测试的目的是尽可能发现软件中的错误，通常 单元测试 是代码编写阶段可进行的测试，它是整个测试工作的基础。

按照软件配置管理的原始指导思想，受控制的对象应是 软件配置项
解释：
软件配置管理（Software Configuration Management）：软件配置管理是指对软件开发过程中的各种软件配置项（包括代码、文档、库文件、测试数据等）进行有效管理的过程。它涉及对软件版本、变更、发布等方面的管理，旨在确保软件开发过程的可控性和可靠性。

用例图 是从用户使用系统的角度描述系统功能的图形表达方法。
解释：
用户导向：用例图以用户为中心，从用户的角度来描述系统的功能需求。它关注的是用户与系统之间的交互和功能需求，能够清晰地展示用户在何种情境下使用系统以及系统如何响应用户的需求。
易于理解和沟通：用例图使用简洁的符号和图形来表示系统的功能，易于理解和沟通。通过用例图，可以直观地了解系统的功能范围、用户角色和用例之间的关系，便于项目团队、用户和开发人员之间的沟通和交流。
需求分析和验证：用例图可以作为需求分析的工具，帮助团队明确用户需求和功能要求。通过对用例进行详细的描述和验证，可以帮助发现系统设计中可能存在的问题和缺陷，从而提高系统的质量和可靠性。
可扩展性：用例图可以根据实际需求进行扩展和调整。在需求变更或系统升级的过程中，可以通过添加、修改或删除用例来反映新的功能需求或系统改进，保持用例图的实效性和可用性。

类图 是表达系统类及其相互联系的图示，它是面向对象设计的核心，是建立状态图、协作图和其他图的基础。
解释：
描述系统结构：类图可以清晰地描述系统中的类及其相互联系，包括类之间的继承、关联、聚合等关系。通过类图，可以直观地了解系统的结构和组成，帮助开发人员理解和分析系统的设计。
建立对象模型：类图可以将系统中的类抽象成对象，并描述对象之间的关系和行为。通过类图，可以建立系统的对象模型，帮助开发人员理解对象之间的交互和依赖关系，从而进行系统的设计和实现。
支持面向对象设计原则：类图是支持面向对象设计原则的重要工具之一。例如，通过继承关系可以实现代码的重用和扩展性，通过关联和聚合关系可以描述对象之间的关联和依赖关系，通过接口可以定义对象的公共接口等。类图能够帮助开发人员遵循面向对象设计原则，提高系统的可维护性和可扩展性。
基础图形：类图是建立其他图形的基础，如状态图、协作图、序列图等。这些图形可以进一步描述系统的行为和交互，通过类图作为基础，可以更加直观和清晰地表示系统的设计和实现。

软件维护的副作用是指 因修改软件而造成的错误

通过执行对象的操作可以改变对象的属性，但它必须通过 消息 的传递。
解释：
封装性：面向对象设计的一个核心原则是封装性，即将数据和操作封装在对象内部。对象的内部状态（属性）应该被保护起来，只能通过对象的操作（方法）来改变。通过消息的传递，外部的对象可以向目标对象发送请求（消息），而目标对象可以根据接收到的消息来执行相应的操作，从而改变自身的属性。这种方式保护了对象的内部状态，实现了封装性。
隐藏实现细节：通过消息的传递，对象之间的通信是通过定义的接口进行的，而不需要了解对象的具体实现细节。这样可以隐藏对象的内部细节，使得系统更加模块化和灵活。当对象的实现发生变化时，只需要保持接口不变，其他对象仍然可以通过发送消息来与目标对象进行交互，不需要修改调用者的代码。
解耦合：通过消息的传递，对象之间的通信是松耦合的，彼此之间不直接依赖或知道对方的具体实现。对象只需要知道如何发送消息和如何处理接收到的消息即可，而不需要关心消息的具体来源或去向。这样可以降低对象之间的依赖关系，提高系统的灵活性和可维护性。
多态性：通过消息的传递，不同类型的对象可以接收相同的消息并做出不同的响应，实现多态性。这意味着对象可以以统一的方式进行交互，而不需要知道具体是哪个对象在执行操作。这样可以更好地支持系统的扩展和变化，新的对象可以通过实现相同的接口来处理相同的消息。

易用性 不是人们常用的评价软件质量的因素之一
解释：
人们常用的评价软件质量的四个因素是可理解性、可靠性、可维护性、可用性

白盒测试法是根据程序的 内部逻辑 来设计测试用例的方法。
补充：
白盒测试法（White-box Testing）也被称为结构测试、透明盒测试、逻辑驱动测试。