软件工程 (重点大全)

软件定义及特性

软件是程序，以及开发，使用和维护程序所需的所有文档。是有应用程序、系统程序面向用户的文档及面向开发者的文档四部分组成。

● 软件是一种逻辑产品，具有无形性；

● 软件产品的生产主要是研制；主要是脑力劳动；

● 软件不存在磨损和老化问题，但存在退化问题；

● 软件产品的成本非常昂贵，其开发方式目前尚未完全摆脱手工生产方式；

● 软件具有“复杂性”，其开发和运行常受到计算机系统的限制。

软件工程的基本原则

● 必须认识软件需求的可变动性，以便采取适当措施来保证产品能最好地满足用户要求。在软件设计中，通常要考虑模块化、抽象与信息隐蔽、局部化、一致性等原则。

● 稳妥的设计方法将大大地方便软件开发，以达到软件工程的目标。软件工具与环境对软件设计的支持颇为重要。

● 软件工程项目的质量与经济开销直接取决于对它所提供支持的环境、工具、开发过程、技术的质量与效用。

● 只有在强调对软件过程有效管理的情况下，才能实现有效的软件工程。

软件危机？原因？

“软件危机”(Software Crisis)的出现是由于软件的规模越来越大，复杂度不断增加，软件需求量增大。而软件开发过程是一种高密集度的脑力劳动，软件开发的模式及技术不能适应软件发展的需要。致使大量质量低劣的软件涌向市场，有的花费大量人力、财力，而在开发过程中就夭折。软件危机主要表现在两个方面：

(1) 软件产品质量低劣，甚至开发过程就夭折。(2) 软件生产率低，不能满足需要。

瀑布模型将软件开发活动中的各项活动规定为依线性顺序连接的若干阶段，形如瀑布流水，最终得到软件系统或软件产品。它简单易用，在消除非结构化软件、降低软件的复杂性、促进软件开发工程化方面起了很大的作用。但在软件开发实践中也逐渐暴露出它的缺点。它将一个充满回溯的软件开发过程硬性分割为几个阶段，无法解决软件需求不明确或者变动的问题。

增量模型是一种非整体开发的模型。根据增量的方式和形式的不同，分为基于瀑布模型的渐增模型和基于原型的快速原型模型。该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。

快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。

螺旋模型将瀑布模型和增量模型结合起来，并加入了风险分析。螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期可分为4个工作步骤：制定计划、风险分析、实施工程、客户评估。

软件生存周期各阶段的主要任务

● 可行性研究与计划(确定系统的目标和规模，分析项目的可行性)；

● 需求分析与规格说明(明确系统的规格和要求)；

● 设计(包括概要设计和详细设计，将系统分解为模块)；

● 编程(用程序语言实现每个模块，简单容易)；

● 测试(发现并改正错误，分为模块测试、集成测试和系统联调三级)；

● 运行维护(扩充功能、纠错等)。

软件开发方法

● 结构化开发方法

面向数据流的开发方法，它的基本原则是功能的分解与抽象。适用于大型数据处理系统。

特点：快速、自然、方便。工作模型是瀑布模型。指导思想：自顶向下、逐步求精

● 原型化开发方法

核心是花费少量代价建立一个可运行的系统，使用户及早获得学习的机会。强调软件开发人员与用户的不断交互，通过原型的演进不断适应用户任务改变的需求。它是一个循环的模型。速成原型法按以下步骤循环执行：

①快速分析。②构造原型（用户界面原型、功能原型、性能原型）。③运行和评价原型。④修改与改进。

● 面向对象开发方法

对问题领域进行自然分割，以更接近人类正常思维的方式建立问题领域的模型。以便对客观的信息实体进行结构和行为的模型，从而使设计的软件更直接地表现问题的求解过程。以对象作为最基本的元素，是分析和解决问题的核心。

软件需求的基本任务：

● 确定系统的综合要求：确定系统功能、性能、运行要求；将来可能提出的要求

● 分析系统的数据要求：数据要求；数据处理要求

● 导出系统的逻辑模型：系统的逻辑模型与开发方法有关。

● 修正系统的开发计划：通过需求分析对系统的成本及进度有了更精确的估算，可进一步修改开发计划，最大限度地减小软件开发风险。

需求工程包括哪些基本活动？各项基本活动的主要任务是什么？

⑴获取需求。深入实际，在充分理解用户需求的基础上，获取足够多的问题领域的知识，积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合解决领域问题的用户需求。需求获取的方法一般有问卷法、面谈法、数据采集法、用例法、情景实例法以及基于目标的方法等。

⑵需求分析与建模。对已获取的需求进行分析和提炼，进行抽象描述，建立目标系统的概念模型，需求概念模型的要求包括实现的独立性:不模拟数据的表示和内部组织等；需求模拟技术又分为企业模拟、功能需求模拟和非功能需求模拟等。进一步对所建立的模型（原型）进行分析。需求模型的表现形式有自然语言、半形式化(如图、表、结构化英语等)和形式化表示等三种。

⑶需求规格说明。对需求模型进行精确的、形式化的描述，为计算机系统的实现提供基础。

⑷确认需求。以需求规格说明为基础输入，通过符号执行、模拟或快速原型等方法，分析和验证需求规格说明的正确性和可行性，确保需求说明准确、完整地表达系统的主要特性，就是对需求规格说明与用户达成一致。其主要任务是冲突求解，包括定义冲突和冲突求解两方面。常用的冲突求解方法有：协商、竞争、仲裁、强制、教育等，其中有些只能用人的因素去控制。

⑸需求管理。在整个需求工程过程中，贯穿了需求管理活动。需求管理主要包括跟踪和管理需求变化，支持系统的需求演进。由于客户的需要总是不断（连续）增长的，但一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化(变化)就成为软件管理的首要问题。对于传统的变化管理过程来说，其基本成分包括软件配置、软件基线和变化审查小组。当前的发展是软件家族法，即产品线方法。多视点方法也是管理需求变化的一种新方法，它可以用于管理不一致性，并进行关于变化的推理。进化需求是十分必要的。

如何画分层数据流图？有哪些基本原则？

原则是：至顶而下，逐层分解(画分层数据流图)。逐层分解的画法可以控制每一层的复杂度。顶层：将整个系统作为一个加工，描述系统边界(输入与输出)。中间层：将某个加工分解为一组子加工，其中的子加工还需进一步分解。底层：由不再进行分解的基本加工组成。

基本原则有：数据守恒与数据封闭原则；加工分解的原则；子图与父图“平衡”的原则；合理使用文件的原则。

功能需求：它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。它与软件系统的类型、使用系统的用户等相关，有时需要详细描述系统的功能、输入/输出、异常等，有时还需要声明系统不应该做什么。

非功能需求常常指不与系统功能直接相关的一类需求，主要反映用户提出的对系统的约束，与系统的总体特征有关，如可靠性、反应时间、存储空间等。

数据流图（Data Flow Diagram，DFD）是描述系统中数据流程的图形工具，它描述了将系统的逻辑输入转换为逻辑输出所需的加工处理过程。

软件设计阶段的主要任务是将分析阶段获得的需求说明转换为计算机中可实现的系统。包括:软件体系结构的设计、用户界面的设计、数据结构的设计、算法的设计。

软件设计阶段的任务具体分为三部分：

● 确定软件结构，划分子系统模块

好的软件结构可以使软件的开发过程流畅自如，同时也能为软件的部署带来好处。合理的模块划分可以降低软件开发的复杂度，同时也提高软件的可复用性。

● 确定系统的数据结构

数据结构的建立对于信息系统而言尤为重要。要确定数据的类型、组织、存取方式、相关程度及处理方式等。

● 设计用户界面

作为人机接口的用户界面起着越来越重要的作用，它直接影响到软件的寿命。

①深度：表示软件结构中从顶层模块到最底层模块的层数。

②宽度：表示控制的总分布。

③扇出数：指一个模块直接控制下属的模块个数。

④扇入数：指一个模块的直接上属模块个数。

一个好的软件结构的形态准则是：顶部宽度小，中部宽度最大，底部宽度次之；在结构顶部有较高的扇出数，在底部有较高的扇入数。

模块独立性：指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他模块接口是简单的。即具有独立性的模块应该是具有专一功能，模块之间无过多的相互作用的模块。

耦合性是指软件结构中模块相互连接的紧密程度，是模块间相互连接性的度量。

内聚性表示一个模块内部各种数据和各种处理之间联系的紧密程度，它是从功能的角度来度量模块内的联系。

信息隐蔽：每个模块的实现细节对于其他模块来说是隐蔽的，也就是说，模块中所包含的信息（数据和过程）不允许其他不需要这些信息的模块使用。有利于提高模块的内聚性。

模块分解的最终目的：将系统“分而治之”，以降低问题的复杂性，使软件结构清晰，易阅读、易理解，易于测试和调试，因而也有助于提高软件的可靠性。

模块分解标准

按照“降低块间联系，提高块内联系”的设计总则对模块进行分解。

(1) 尽可能建立功能模块；(2) 消除重复功能；(3) 模块的作用范围与控制范围，即当作用范围为控制范围的子集时，才能获得较低的块间联系；(4) 模块的大小适当；(5) 模块的扇入/扇出数不宜太多。

也可以用软件独立性的两个定性指标来度量模块分解的标准：

一是耦合性。用于描述模块之间联系的紧密程度。从三个方面衡量块间联系大小：①方式(直接或间接）②类型（数据型、控制型、混合型）③数量（数量越大，块间联系越紧密。

二是内聚性。用于描述模块内部联系的紧密程度。它是从功能的角度来度量模块内的联系。显然,块内联系愈紧,即内聚性愈强,模块独立性愈好。功能型模块独立性最好。

面向对象的分析包括哪些主要活动？所建立的分析模型包括哪些类型的模型？

面向对象的分析过程分为论域分析和应用分析。论域分析过程是抽取和整理用户需求并建立问题域精确模型的过程。应用分析是将论域分析建立起来的问题论域模型，用某种基于计算机系统的语言来描述。

面向对象的分析具体包括以下活动：

①获取用户基本需求。通常使用用例（User Case）来收集和描述。

②标识类和对象。包括标识类及对象的属性和操作。

③定义类的结构和层次。通常有一般与特殊( Generalization—Specialization)结构，整体与部分(Whole—Part)结构。

④建立类(对象)之间的关系，用“对象-关系模型”描述系统的静态结构。

⑤建立对象—行为模型，描述系统的动态行为。

所建立的分析模型包括：

①基本模型。是一个类图(class diagram)，是以直观的方式表达系统最重要的信息。OOA基本模型的三个层次分别描述了：系统中应设哪几类对象，每类对象的内部构成，对象与外部的关系。

②主题图(subject)。又称为子系统(subsystem)，是将一些联系密切的类组织在一起的类的集合。按照粒度控制原则，将系统组成几个主题，便于理解。

③交互图(interaction diagram) 是用例与系统成分之间的对照图。

主题图和交互图又称为补充模型。

扩展、包含扩展（extend）关系是对基本用例在对某些“扩展点”的功能的增加。通过向被扩展的用例添加动作来扩展用例。包含（include）关系表示一个元素为了实现或完成其全部的功能，需要用到已存在的另一个模型元素，本质上是一种使用关系。

状态图、协作图、活动图、顺序图作用

状态图(State Diagram)用来描述一个特定对象在其生存周期或在某段时间内的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的改变。例如订单的状态变化等，在实时系统中用得较多，还可以用于辅助设计用户界面。

顺序图(Sequence Diagram) 清晰地描述一组对象之间动态的交互关系、时间的约束关系，着重描述对象间消息传递的时间顺序，所以顺序图在实时系统中被大量使用。

当参与交互的对象数目增加，交互关系复杂时用顺序图描述会显得杂乱，协作图(Collaboration Diagram)从另一个角度来更好地描述相互协作的对象间的交互关系和链接(Link)关系。着重体现交互对象间的静态链接关系和协作关系。协作图也可以从顺序图生成。

活动图(Activity Diagram)是由状态图变化而来的，从系统任务的观点来看，系统的执行过程是由一系列有序活动组成的。活动图可以有效地描述整个系统的流程，描述了系统的全局的动态行为，且只有活动图是唯一能够描述并发活动的UML图。

顺序图与协作图都是交互图，它们有何不同？所描述的主要系统特征是什么？

顺序图(Sequence Diagram) 重点描述某些对象间消息传递的时间顺序，对象间的通信和交互通过在对象的生命线之间传送的消息来表示。还常给出消息的说明信息及消息之间的时间限制及一些约束信息等。但当参与交互的对象数增加，交互关系复杂时难于表达清楚对象之间的交互关系。

协作图(Collaboration Diagram) 则着重体现交互对象间的静态链接关系和协作关系，不强调执行事件的顺序，而是强调为了完成某个任务，对象之间通过发送消息实现协同工作关系。可以有效地描述当参与对象数较多时的交互关系。

状态图与活动图异同？在建立系统模型时，应该如何使用这两类模型？

答：活动图(Activity Diagram)是由状态图变化而来的,它们各自用于不同的目的。状态图着重描述了对象的状态变化以及触发状态变化的事件。但是，从系统任务的观点看系统，它是由一系列有序活动组成的，活动图是从活动的角度描述系统任务，并且可以描述系统任务中的并发活动。活动图描述了系统中各种活动的执行顺序，刻画一个方法中所要进行的各项活动的执行流程。活动图显示动作及其结果，着重描述操作实现中完成的工作以及用例或对象内部的活动。

此外，在状态图中状态的变迁通常需要事件的触发，而活动图中一个活动结束后将立即进入下一个活动。

以例5-5中图5.22“资源管理用例图”为例，说明<>和<>的区别。

答：在图5.22中，用例“删除资源”和“更新资源”与用例“查找资源”之间是<>的关系，<>本质上是一种使用关系，当一个用例包含另一个用例时，这两个用例之间就构成了使用关系。说明“删除资源”和“更新资源”的操作都需要首先“查找资源”。

扩展<>是向一个用例中加入一些新的动作后构成了另外一个用例，后者是继承前者的一些行为得来的。图 5.22中，对用例“更新资源”中增加动作“清除技能”，得到用例“从资源中清除技能”，增加动作“指定技能”，得到用例“把技能指定给资源”，因此，用例“更新资源”与“从资源中清除技能”和“把技能指定给资源”之间的关系是<>。等价分类法的基本思想

根据程序的输入特性，将程序的定义域划分为有限个等价区段——“等价类”，从等价类中选择出具有“代表性”的用例，即测试某个等价类的代表值就等价于对这一类其他值的测试。如果某个等价类的一个输入数据(代表值)测试中查出了错误，说明该类中其他测试用例也会有错误。

自顶向下渐增与自底而上渐增各有何优、缺点

①自顶向下渐增优点：能够尽早发现系统主控方面的问题，并尽早测试系统结构的问题。缺点：需要编写桩模块，由于下属模块往往不止一个，也不止一层，加之模块接口的复杂性，桩模块很难模拟各下层模块之间的调用关系，也无法验证桩模块是否完全模拟了下属模块的功能。因此很难尽早查出底层容易出错的复杂模块中的错误，所以导致过多的回归测试。

②自底向上渐增优点：需要编写驱动模块。驱动模块是模拟主程序或者调用模块的功能，处于被测试模块的上层，

所以驱动模块只需模拟向被测模块传递数据，接收或打印从被测模块返回的数据等功能，比编写桩模块容易。还能够尽早查出底层涉及较复杂的算法和实际的I/O模块中的错误。缺点：只有当系统所有模块全部组装完成，才能看到系统完整的结构，才能测试系统的主控功能。

渐增式与非渐增式有何区别？为什么通常采用渐增式？

非渐增式是将所有的模块一次连接起来，简单、易行，节省机时，但测试过程中难于查错，发现错误也很难定位，测试效率低。渐增式是将模块一个一个地连入系统，每连入一个模块，都要对新子系统进行测试。这种组装测试方案虽然用机时多，但比较非渐增式容易查出错误及进行错误定位，有利于查出模块接口部分的错误，测试效率高。因此通常采用渐增式。

α测试和β测试

α测试是在开发机构的监督下，在确认测试阶段后期由个别用户对软件进行测试，目的是评价软件的FLURPS(功能、局域化、可使用性、可靠性、性能和支持性)，注重界面和特色。β测试是在进行了α测试的基础上，由支持软件预发行的客户对FLURPS进行测试，主要目的是测试系统的可支持性，是在软件产品正式发布前的测试。

黑盒法与白盒法的区别是什么？各自运用在什么情况下？

白盒法测试又称结构测试或逻辑驱动测试。必须考虑程序内部结构和内部特性，针对特定条件或与循环集设计测试用例，对软件的主要逻辑路径进行测试。一般主要用于模块测试。

黑盒法测试又称功能测试或基于规格说明的测试。这种方法是从用户观点出发，测试时把被测程序当作一个黑盒，不考虑程序内部结构和内部特性，测试者只知道该程序输入和输出之间的关系或程序的功能的情况下，依靠能够反映着这一关系和程序功能需求规格的说明书，来确定测试用例和推断测试结果的正确性。一般用于集成测试、确认测试及功能测试、系统测试等。

软件测试基本步骤

⑴单元测试。完成每个模块的测试，尽可能发现模块内部的错误。单元测试主要采用白盒测试法。

⑵集成测试。把已测试过的模块按照一定顺序组装起来，构成软件系统。主要采用黑盒测试法。但对发现错误较多的新子系统，还可能采用白盒法进行回归测试。

⑶确认测试：检验所开发的软件能否满足所有功能和性能需求的最后手段，通常均采用黑盒测试法。

⑷系统测试：完成确认测试以后，检验它能否与系统的其他部分（如硬件，数据库及操作人员）协调工作，需要进行系统测试。

⑸验收测试：检验软件产品质量的最后一道工序是验收测试。与前面讨论的各种测试活动的不同之处主要在于它突出了客户的作用，同时软件开发人员也应有一定程度的参与。

测试目的：开发工作的前期不可避免地会引入错误，测试的目的是为了发现和改正错误，这对于某些涉及人的生命安全或重要的军事、经济目标的项目显得尤其重要。

白盒测试：①语句覆盖：选择足够的测试用例，使得程序中每个语句至少都能被执行一次。

②判定覆盖：执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值。

③条件覆盖：执行足够的测试用例，使得判定中的每个条件获得各种可能的结果。

④判定/条件覆盖：执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个判定取到各种可能的结果。

⑤条件组合覆盖：执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。

黑盒测试：等价划分类、边值分析法、错误推测法、因果图法、正交实验设计法、判定表驱动法、功能测试。

驱动模块（driver）－－模拟主程序功能，用于向被测模块传递数据，接收、打印从被测模块返回的数据。

桩模块（stub）－－又称为假模块，用于模拟那些由被测模块所调用的下属模块功能。