本章分享的1.4节的重要考点内容相对来说还是比较多的，里面包括需求、设计、测试等软件工程的内容，同学们学完前几篇文章的分享会发现，第一章与计算机领域的知识的衔接程度还是非常紧密的。我经常会听到很多面授课学员在学习第一章的时候跟我说“第一章记不住，太难了，想放弃”，其实我可以这么说第一章是比较难，就以1.4节为例，大部分同学应该都是计算机相关专业毕业的学员，大家在大学的时候一定知道软件工程这个专业，试想一下，软件工程专业的同学用三到四年的时间学习软件工程的相关知识，我们的教材只是用一个小节进行讲解，所有的知识点只要背下来考试就会没问题。而且你幸运的看到了这篇文章，你会发现本篇文章对书中不考的知识点进行筛选精化，将原先要背的几十页甚至几百页的内容最终形成几千字的文字，大家就更不应该退缩了，更应该好好学习了。下面我们继续分享
1.4软件工程
1.4.1需求分析
1、需求是多层次的， 包括业务需求、用户需求和系统需求。
(1) 业务需求。业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。
(2) 用户需求。用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。
(3) 系统需求。系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
2、质量功能部署(QFD)是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。
(1) 常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
(2) 期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
(3) 意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能(但通常是软件开发人员很乐意赋予系统的技术特性实现这些需求用户会更高兴，但不实现也不影响其购买的决策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以(出于成本或项目周期的考虑)选择不实现任何意外需求。
3、常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等
4、一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
使用SA方法进行需求分析，其建立的模型的核心是数据字典。在实际工作中，一般使用实体联系图(E-R图) 表示数据模型，用数据流图(DFD) 表示功能模型，用状态转换图(STD) 表示行为模型。E-R图主要描述实体、属性，以及实体之间的关系;DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能; STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作(例如，处理数据等)。
5、软件需求规格说明书(SRS)是需求开发活动的产物，其中规定SRS应该包括以下内容。
(1)范围(2)引用文件(3)需求(4)合格性规定(5)需求可追踪性(6)尚未解决的问题(7) 注解(8)附录
6、需求验证也称为需求确认，其活动是为了确定以下几个方面的内容。
(1) SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
(2) SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
(3) 需求是完整的和高质量的。
(4)需求的表示在所有地方都是一致的。
(5)需求为继续进行系统设计、实现和测试提供了足够的基础。
在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS进行技术评审。
7、从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。
8、UML用关系把事物结合在一起，主要有下列四种关系:
(1) 依赖: :依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
(2) 关联:关联描述一组对象之间连接的结构关系。
(3) 泛化:泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
(4) 实现:实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
9、UML 2. 0包括14种图，分别列举如下:
(1)类图:类图描述一组类、接口、协作和它们之间的关系。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。
(2)对象图:对象图描述一组对象及它们之间的关系。
(3) 泛化:泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
(4) 实现:实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
9、UML 2. 0包括14种图，分别列举如下:
(1)类图:类图描述一组类、接口、协作和它们之间的关系。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。
(2)对象图:对象图描述一组对象及它们之间的关系。
(3) 构件图:构件图描述一个封装的类和它的接口、端口， 以及由内嵌的构件和连接件构成的内部结构。
(4) 组合结构图:组合结构图描述结构化类(例如，构件或类)的内部结构，包括结构化类与系统其余部分的交互点。
(5)用例图:用例图描述一组用例、参与者及它们之间的关系。
(6)顺序图(也称序列图) :顺序图是一一种交互图，交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
(7) 通信图:通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图强调的是时序，通信图强调的是对象之间的组织结构(关系)。
(8) 定时图(也称计时图) :定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。
(9) 状态图:状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。
(10) 活动图:活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它强调对象间的控制流程。
(11) 部署图:部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。
(12)制品图:制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。
(13) 包图:包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。
(14)交互概览图:交互概览图是活动图和顺序图的混合物。
10、UML视图: 5个系统视图:
(1) 逻辑视图:逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
(2) 进程视图:进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一-次执行实例，描述了并发与同步结构。
(3)实现视图:实现视图对组成基于系统的物理代码的文件和构件进行建模。
(4)部署视图:部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
(5) 用例视图:用例视图是最基本的需求分析模型。
11、00A模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是00A和00D的区别之所在。00A的任务是“做什么00D的任务是“怎么做”。面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。
12、SA (结构化分析)方法采用功能分解的方式来描述系统功能，在这种表达方式中，系统功能被分解到各个功能模块中，通过描述细分的系统模块的功能来达到描述整个系统功能的目的。
13、类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等
(1) 关联关系。关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关系，而不表示两个类之间的关系。
(2) 依赖关系。两个类A和B，如果B的变化可能会引起A的变化，则称类A依赖于类B。
(3) 泛化关系。泛化关系描述了一- 般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化。
(4)共享聚集。共享聚集关系通常简称为聚合关系，它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体”，“部分”与“整体”的生命周期可以不相同。
(5)组合聚集。组合聚集关系通常简称为组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命周期相同，“部分” 随着“整体M的创建而创建，也随着“整体”的消亡 而消亡。
(6) 实现关系。实现关系将说明和实现联系起来。接口是对行为而非实现的说明， 而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。
1.4.2软件架构设计
1、解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。软件架构设计的一个核心问题是能否达到架构级的软件复用。
2、软件架构分为数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。
(1) 数据流风格:数据流风格包括批处理序列和管道/过滤器两种风格。
(2) 调用/返回风格:调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。
(3) 独立构件风格:独立构件风格包括进程通信和事件驱动的系统。
(4)虚拟机风格:虚拟机风格包括解释器和基于规则的系统。
(5) 仓库风格:仓库风格包括数据库系统、黑板系统和超文本系统。
3、软件架构评估可以只针对一个架构，也可以针对一组架构。在架构评估过程中，评估人员所关注的是系统的质量属性。
4、敏感点是一个或多个构件(和/或构件之间的关系)的特性，权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
5、从目前已有的软件架构评估技术来看，可以归纳为三类主要的评估方式，分别是基于调查问卷(或检查表)的方式、基于场景的方式和基于度量的方式。这三种评估方式中，基于场景的评估方式最为常用。
6、基于场景的方式主要包括:架构权衡分析法(ATAM)、 软件架构分析法(SAAM)和成本效益分析法(CBAM)中。 在架构评估中，一般采用刺激、环境和响应三方面来对场景进行描述。刺激是场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过架构对刺激作出反应的。
7、基于场景的方式分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。这一评估方式考虑到了所有与系统相关的人员对质量的要求，涉及的基本活动包括确定应用领域的功能和软件架构之间的映射，设计用于体现待评估质量属性的场景，以及分析软件架构对场景的支持程度。
1.4.3软件设计
1、软件设计分为结构化设计与面向对象设计。
2、结构化设计SD是--种面向数据流的方法，它以SRS和SA阶段所产生的DFD和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。SD分为概要设计和详细设计两个阶段
3、在SD中，需要遵循一个基本的原则:高内聚，低耦合
4、面向对象设计00D是00A方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。
5、设计模式是前人经验的总结，它使人们可以方便地复用成功的软件设计。根据处理范围不同，设计模式可分为类模式和对象模式。根据目的和用途不同，设计模式可分为创建型模式、结构型模式和行为型模式三种。创建型模式主要用于创建对象;结构型模式主要用于处理类或对象的组合;行为型模式主要用于描述类或对象的交互以及职责的分配。
1.4. 4软件工程的过程管理
1、阶段式模型
2、连续式模型
1.4.5软件测试及其管理
1、每个测试用例应包括名称和标识、测试追踪、用例说明、测试的初始化要求、测试的输入、期望的测试结果、评价测试结果的准则、操作过程、前提和约束、测试终止条件。期望的测试结果、评价测试结果的准则、操作过程、前提和约束、测试终止条件。
2、软件测试方法可分为静态测试和动态测试。静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试一般采用桌前检查、代码走查和代码审查。
3、动态测试是指在计算机上实际运行程序进行软件测试，一般采用白盒测试和黑盒测试方法。白盒测试也称为结构测试，主要用于软件单元测试中。它的主要思想是，将程序看作是一个透明的白盒，测试人员完全清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例。白盒测试方法主要有控制流测试、数据流测试和程序变异测试等。另外，使用静态测试的方法也可以实现白盒测试。例如，使用人工检查代码的方法来检查代码的逻辑问题，也属于白盒测试的范畴。白盒测试方法中，最常用的技术是逻辑覆盖，即使用测试数据运行被测程序，考察对程序逻辑的覆盖程度。主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖等。
4、黑盒测试也称为功能测试，主要用于集成测试、确认测试和系统测试中。黑盒测试将程序看作是一个不透明的黑盒，完全不考虑(或不了解)程序的内部结构和处理算法。一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。
5、软件测试可分为单元测试、集成测试、确认测试、系统测试、配置项测试和回归测试等类别。
(1)单元测试。单元测试也称为模块测试。
(2) 集成测试。集成测试的目的是检查模块之间，以及模块和已集成的软件之间的接口关系。
(3)确认测试。确认测试主要用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度，通常包括以下类型。
内部确认测试。内部确认测试主要由软件开发组织内部按照SRS进行测试。
Alpha测试和Beta测试。对于通用产品型的软件开发而言，Alpha测试是指由用户在开发环境下进行测试，通过Alpha测试以后的产品通常称为Alpha版;Beta测试是指由用户在实际使用环境下进行测试，通过Beta测试的产品通常称为Beta版。一般在通过Beta测试后，才能把产品发布或交付给用户。
验收测试。验收测试是指针对SRS，在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。
(4)系统测试。系统测试的对象是完整的、集成的计算机系统，系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。
(5)配置项测试。配置项测试的对象是软件配置项，配置项测试的目的是检验软件配置项与SRS的一致性。
(6) 回归测试。回归测试的目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。回归测试的对象主要包括以下四个方面。
未通过软件单元测试的软件，在变更之后，应对其进行单元测试。
未通过配置项测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试和配置项测试。
未通过系统测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试、配置项测试和系统测试。
因其他原因进行变更之后的软件单元，也首先应对变更的软件单元进行测试，然后再进行相关的软件测试。
6、与传统的结构化系统相比，00系统具有三个明显特征，即封装性、继承性与多态性。正是由于这三个特征，给00系 统的测试带来了一系列的困难。
7、常用的软件调试策略可以分为蛮力法、回溯法和原因排除法三类。软件调试与测试的区别主要体现在以下几个方面。
(1) 测试的目的是找出存在的错误，而调试的目的是定位错误并修改程序以修正错误。
(2) 调试是测试之后的活动，测试和调试在目标、方法和思路.上都有所不同。
(3)测试从一个已知的条件开始，使用预先定义的过程，有预知的结果;调试从一-个未知的条件开始，结束的过程不可预计。
(4)测试过程可以事先设计，进度可以事先确定;调试不能描述过程或持续时间。
8、软件测试的管理包括过程管理、配置管理和评审工作。
(1)过程管理。过程管理包括测试活动管理和测试资源管理。软件测试应由相对独立的人员进行。软件测试人员应包括测试项目负责人、测试分析员、测试设计员、测试程序员、测试员、测试系统管理员和配置管理员等。
(2)配置管理。应按照软件配置管理的要求，将测试过程中产生的各种工作产品纳入配置管理。由开发组织实施的软件测试，应将测试工作产品纳入软件项目的配置管理;由独立测试组织实施的软件测试，应建立配置管理库，将被测试对象和测试工作产品纳入配置管理。
(3)评审。测试过程中的评审包括测试就绪评审和测试评审。测试就绪评审是指在测试执行前对测试计划和测试说明等进行评审，评审测试计划的合理性和测试用例的正确性、完整性和覆盖充分性，以及测试组织、测试环境和设备、工具是否齐全并符合技术要求等;测试评审是指在测试完成后，评审测试过程和测试结果的有效性，确定是否达到测试目的，主要对测试记录和测试报告进行评审。
1.4.6软件集成技术
1、企业应用集成EAI包括表示集成、数据集成、控制集成和业务流程集成等多个层次和方面。当
然，也可以在多个企业之间进行应用集成。
(1)表示集成也称为界面集成，是黑盒集成，无须了解程序与数据库的内部构造。常用的集成
技术主要有屏幕截取和输入模拟技术。
(2) 数据集成是白盒集成
(3)控制集成也称为功能集成或应用集成，是在业务逻辑层上对应用系统进行集成的。集成处可能只需简单使用公开的API (应 用程序编程接口)就可以访问，当然也可能需要添加附加的代码来实现。控制集成是黑盒集成。控制集成与表示集成、数据集成相比，灵活性更高。表示集成和数据集成适用的环境下，都适用于控制集成。但是，由于控制集成是在业务逻辑层进行的，其复杂度更高一些。
(4) 业务流程集成
业务流程集成也称为过程集成，这种集成超越了数据和系统，它由一系列基于标准的、统一数据格式的工作流组成。当进行业务流程集成时，企业必须对各种业务信息的交换进行定义、授权和管理，以便改进操作、减少成本、提高响应速度。
(5) 企业之间的应用集成
EAI技术可以适用于大多数要实施电子商务的企业，以及企业之间的应用集成。EAI使得应用集成架构里的客户和业务伙伴都可以通过集成供应链内的所有应用和数据库实现信息共享。也就是说，能够使企业充分利用外部资源。
请大家认真学习1.4节的，为了能够快速准确的找到我的文章大家可以关注我，我会每天进行更新。