🌈 个人主页：十二月的猫-CSDN博客
🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光
目录
1. 前言
2. 前景知识回顾
3. 章节概述和章节框架
4. 系统体系结构
4.1 设计过程
4.1.1 相关概念
4.1.2 系统结构设计全过程（如何完成系统结构设计）
4.1.3 分解（系统结构设计的核心方法）
4.2 设计过程中的若干问题
4.2.1 三种设计层次及其关系
4.2.2 几种体系结构风格
4.2.3 质量属性的几个概念
4.2.4 模块化与抽象层次
4.3 模块独立性
4.3.1 耦合 coupling
4.3.2 内聚 cohesion
1. 功能内聚（Functional Cohesion）
2. 顺序内聚（Sequential Cohesion）
3. 通信内聚（Communicational Cohesion）
4. 过程内聚（Procedural Cohesion）
5. 时间内聚（Temporal Cohesion）
6. 逻辑内聚（Logical Cohesion）
7. 偶然内聚（Coincidental Cohesion）
4.4 体系结构的评估和改进
4.4.1 故障树分析
4.4.2 错误预防和容错
4.4.3 设计复审（review）的两种方法：验证与确认
4.4.4 设计复审的重要性
5. 总结
1. 前言
在进入本篇文章前，大家可以按需求看看另四篇文章：
【软件工程】第一章·软件工程概述-CSDN博客
【软件工程】第二章·软件过程（过程与生命周期建模）-CSDN博客
【软件工程】第三章·计划和管理项目（详解活动图计算关键路径、最早开始时间、最晚开始时间、冗余时间）-CSDN博客
【软件工程】第四章·需求分析-CSDN博客
这几篇文章将让你对软件工程有一个整体的脉络，并在细节上有一定的把控。
本文参考书籍：软件工程 第4版（ [美] 莎丽·劳伦斯·弗里格（Shari Lawrence Pfleeger））
2. 前景知识回顾
首先想带大家先来简单复习一下前面的内容：
第一章·软件工程概述：
1、软件工程是什么——定义、方法、作用。
2、软件工程的前世今生——出现的问题（error、fault、failure）、应对方法（问题分析方法+系统化方法+工程化方法）。
3、软件工程的未来——Wasserman 规范（抽象、分析设计方法和符号描述系统、软件过程、软件体系结构、重用和复用、用户界面原始模型、测试代码、工具和集成环境）
第二章·软件过程与生命周期：
1、过程与生命周期是什么
- 过程是一系列有序的任务，涉及活动、资源和约束（过程不是步骤而是步骤的集合）。
- 生命周期是软件从概念、实现、交付到使用、维护的整个过程。软件开发全过程称为软件生命周期。
2、过程模型
- 种类：瀑布模型、原型化瀑布模型、V模型、原型化模型、阶段化开发模型、螺旋模型、敏捷方法模型
- 联系：
- 瀑布模型是基础。
- 原型化瀑布模型结合原型化模型与瀑布模型（设计阶段产生原型化模型，在测试阶段考虑是否返回）。
- V模型（将设计与测试之间都建立起通道）。
- 原型化模型（不是具体模型，是一种思想，每一个步骤都可以产生原型去分析）。
- 阶段化开发模型（开发版本和使用版本分离，分离导致需要选择迭代开发/增量开发/迭代进化开发/统一过程开发）。
- 螺旋模型（是迭代思想和原型化思想的结合）。
- 敏捷方法模型（撇弃原型化和迭代化带来的冗余，将目标转化为：快【尽早交付】、准【持续有价值的软件交付活动】、狠【直到客服满意】）（四大原则：个体和交互胜过过程和工具、可运行软件胜过面面俱到的文档、客户合作胜过合作谈判、响应变化胜过遵循计划）
- 核心思想：迭代思想、增量思想、原型化思想
第三章·计划和管理项目：
1、计划项目
- 时间计划：项目进度、项目活动、里程碑、活动图、最早开始时间、最迟开始时间、冗余时间、关键路径。
- 工作量计划：估（专家估算：Delphi技术、乐观悲观法、Wol技术）、算（算式公式：（a+bSc）m（X）、COCOMO模型：aKLOC^b）
2、管理项目
- 人员管理：人员技术、工作方式、项目组织安排（结构性与创造性、一个领导模式、忘我方法模式）
- 风险管理：什么是风险、风险管理活动（风险评价：风险识别、风险优先级、风险分析）（风险控制：风险降低、风险化解、风险管理计划）、风险降低（风险避免、假设风险、转移风险）、风险化解（6种风险的6种应对方式：产品过大、功能复杂、系统不支持、测试时间、产品控制、协同工作）
第四章·需求分析：
- 了解需求：需求是什么（需求是用户对软件系统期望行为的综合描述）、需求的类型（功能性需求、非功能性需求）、需求的特征（一致性、正确性、无二义性、完备性、可行性等）、需求的表示（UML图）
- 引出需求：风险承担者、引出需求的方式（会谈、特别关注、观察、查看文档）
- 需求前期处理：优先级划分、需求规范化（正式名字、唯一定义、量化描述）
- 需求下的约束：设计约束（之前的设计决策对现在决策的约束）、过程约束（现在技术和资源对决策的限制）
- 需求分析全过程：原始需求获取、问题分析、规格说明草稿、需求核准、软件规格说明书（SRS）
3. 章节概述和章节框架
明确一个点：Wasserman 规范（抽象、分析设计方法和符号描述系统、软件过程、软件体系结构、重用和复用、用户界面原型、测试、工具和集成环境）贯穿软件开发全过程。
章节联系：本章节就是Wasserman规范中的一个。在前面几章，自对软件工程有一个整体认识后，我们首先在抽象层面对软件问题本身有一个认识——计划管理软件项目。然后，我们又对软件过程有一个了解。最后走向需求分析，在需求分析中，我们学习了如何分析用户的需求，更好理解我们所要完成的任务。在明白任务后，我们着手开始建构软件的体系结构，这是我们第一次开始思考如何设计软件。
需求定义和需求分析之后的步骤是对系统进行设计，说明软件系统是如何构造的。对于较小规模系统需求以后就可以简单进入到数据结构和算法设计，进而实现该软件系统，但是构建较大规模系统，就需要将系统分解为规模可管理的子系统或模块，进而进行详细设计。
为了便于理解，我们可以这样说:软件工程的过程分为需求、设计、编码和测试（工程化方法讲软件开发过程），五六两章讲的是设计方面的内容，对于较大的系统，设计分为系统设计(第五章体系结构设计)和详细设计(第六章模块设计)，概要设计的内容为将一个复杂系统进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面，并设计应用系统的总体数据结构和数据库结构等，而详细设计则是根据概要设计赋予的局部任务和对外接口，设计模块算法、流程、状态转换等更为详细的内容。
设计分为：
- 系统设计（概要设计）（第五章的体系结构）
- 模块设计（详细设计）（第六章的考虑对象：面向对象方法将所有功能转为一个个模块，每一个模块有自己的任务以及提供的服务）
4. 系统体系结构
系统体系结构就是研究如何将系统分解为单元，以及单元之间如何相互关联。系统体系结构的研究就是设计的一部分——概要设计。
系统体系研究=概要设计（系统设计）=设计的一部分
本章后续提到的设计都是指体系结构设计
4.1 设计过程
4.1.1 相关概念
(1) 体系结构 Architecture: 一种软件解决方案，用于解释如何将系统分解为单元，以及单元如何相互关联，还包括这些单元的所有外部特性。
(2) 设计 Design: 将需求中的问题描述转变成软件解决方案的创造性过程.
(3) 例程设计 routine design: 通过对与相似问题的解决方案进行复用和调整来解决某个问题。
(4) 克隆 cloning: 借鉴现有的整个设计设置包括它的代码，对它做少许的调整来解决特定
(5) 参考模型 reference model: 用于特定应用领域中标准的、一般性的体系结构，指导我
们把系统分解成主要构件以及构件之间如何交互
(6) 体系结构风格 architectural style: 是已建立的、大规模的系统结构模式，有一系列定义好了的规则、元素和技术。体系结构不是完整的、细节化的解决方案，而是用于提供各种构建组合起来的方法模板。关注的是构件间各种不同的通信、同步或共享数据的方式。
(7) 设计模式 design pattern: 一种针对单个软件模块或少量模块而给出的一般性解决方案，它提供较低层次的设计决策。它是一个共同的设计结构的关键方面，包括对象和实例，角色和协作，责任分配。（例如：工厂模式、单例模式、适配器模式等）。
(8) 设计原则 design principle: 是良好设计的特征，也是能够把系统功能和行为分解成模块的指导方针。
(9) 设计公约 Design Convention: 一系列设计决策和建议的集合，用于提高系统某方面的设计质量。当一种设计公约发展成熟时，将会被封装成设计模式或体系结构风格，最后可能被内嵌为一种程序语言结构。
(10) 创新设计 innovation design: 与例程设计相反，用以创造全新解决方案
(11) 概念设计和技术设计是两个迭代的过程
概念设计 conceptual design 相当于系统设计，确切地告诉客户系统要做什么，即软
件架构和功能。
技术设计 technical design 相当于程序设计，一旦客户认可概念设计，系统构建人员就将概念设计转换为更为详细的文档，即技术设计，技术设计确切的告诉开发人员系统将如何运转，包括:主要的硬件组件及其功能；软件组件的层次和功能；数据结构和数据流。
概念设计强调的是系统功能，而技术设计描述的是系统将要采取的方式。
(12) 模块化 Modular: 只有当系统的每个活动都仅由对应的软件单元实现，并且每个软件单元的输入和输出都已经明确的被定义时，这个设计才是模块化的。
设计 = 系统设计+模块设计 = 概要设计+详细设计 = 概念设计+技术设计
4.1.2 系统结构设计全过程（如何完成系统结构设计）
(1) Modeling 建模:尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构风格。
(2) Analysis 分析:分析初步的体系结构，主要关注软件系统的质量属性性能、安全性、可靠性等、各种约束等等。关注系统级别决策。
(3) Documentation 文档化:确定各个不同的模型视图。
(4) Review 复审:检查文档是否满足所有需求。
(5) final output: SAD:Software Architecture Document 软件体系结构文档，用来和开发团队中其他人员交流系统级别设计决策的有力工具。
4.1.3 分解（系统结构设计的核心方法）
分解：是系统结构设计全过程中最重要的一步——建模中的核心思想
分解后产生的就是模块，模块化也就是分解的目的；抽象化和模块化紧紧联系
分解是把大的系统分解成为更小的部分使问题变得更易于处理，是一种自顶向下的方法；另一种自底向上的方法是将笑的模块以及小的构件打包成一个更大的整体，被认为其设计出来的系统更加易于维护。
六种分解方法：
(1) 功能性分解 Functional decomposition:按照功能和需求进行分解
(2) 面向特征的分解 Feature-oriented design:功能性分解的一种，为各个模块指定了各自的特征
(3) 面向数据的分解 Data-oriented decomposition :关注如何将数据分解成模块(4) 面向进程的分解 Process-oriented decomposition:将系统分解成为并发进程
(5) 面向事件的分解 Event-oriented decomposition:将事件分给不同的模块
(6) 面向对象的设计 Object-oriented design:将对象分配给模块
4.2 设计过程中的若干问题
4.2.1 三种设计层次及其关系
(1) 体系结构设计，相当于系统设计，将 SAS 中确定的系统能力和实现这些能力的系统构件关联起来。
(2) 代码设计 code：各个构件/模块的算法和数据结构设计。
(3) 可执行设计 executable：最底层的设计，包括内存分配，数据格式、位模式等。
这是一种自顶向下的设计，首先设计体系结构，然后进行代码设计，最后是可执行设计，具有可重复性，可以多次修改。
核心要点：
这与前面我提到的：设计 = 系统设计+模块设计 = 概要设计+详细设计 = 概念设计+技术设计 并不冲突。
严格来说这里的体系结构设计是广义的包括：系统设计和模块设计两部分。
4.2.2 几种体系结构风格
我们关注的是每种体系结构风格的组成元素、元素间交互特征和组中系统性质好坏等。
(1) 管道和过滤器：一种组件式设计,常用于语义分析、字典分析等设计。
管道 pipe：将数据从一个过滤器传输到下一个过滤器的连接器，不对数据做任何改变
过滤器 filter：数据转换构件，对输入数据进行转换。
(2) 面向对象设计：用于一般软件设计
(3) 客户-服务器 CS：服务器提供服务，客户通过请求/应答协议访问服务。例如浏览器就是采用这种结构。
(4) 对等网络 P2P，peer-to-peer:体系结构中，每个构件都只执行它自己的进程并且对于其他同级构建，每个构件本身既是客户端又是服务器。如文件共享网络。
(5) 发布-订阅：用于分组交换网络软件设计等等。事件驱动，基于构件之间对时间广播和反应实现交互。一个构件订阅感兴趣的事件，一旦该事件发生，另一个构件进行发布来通知订阅者。隐含调用 implicit invocation 就是一种常见的发布订阅体系结构。
(6) 信息库 repository：常用于信号处理、知识发现、模式识别系统等设计由中心数据存储以及其与其相关联的访问构件组成。其重要特性就是对于系统关键数据的中心式管理，如黑板类型信息库系统：包括黑板本身，知识源和控制。当黑板的状态发生变化时，知识源将作出响应。也就是访问数据的构件是被动的。
(7) 分层系统就是将系统的软件单元按层次划分，每一层为它的上层提供服务，同时又作为下层的客户。例如计网中的开放式系统互联 OSI。优点是高度的抽象以及相对容易增加和修改层，缺点是结构化系统的层次的难度以及系统性能会受到层之间的额外协调影响。
4.2.3 质量属性的几个概念
(1) 可修改性 modifiability 指更改软件系统的难易程度，是绝大部分体系结构风格的基础。对于某个特定改变，为了减少受直接影响的单元，要预测预期改变然后封装在各自的软件单元内、增加内举行、增加软件单元的通用性；为了减少受间接影响的单元，要降低耦合性增加接口设计的多重性。另外，可以设计自我管理软件，检测环境改变进而做出适当反应。
(2) 可维护性 Maintenability 是指理解、改正、改动、改进软件的难易程度
(3) 性能 performance 描述了系统速度和容量上的特点，主要包括响应时间（请
求反应时间）、吞吐量（处理请求速度）和负载（并发用户数）几项内容
提高性能的策略：
①提高资源利用率，如增加软件并行程度；复制数据以及分布式共享数据
②有效的管理资源分配，使用一些调度策略以达到响应时间最小化，吞吐量、资源利用率、公平最大化，高级或紧急事件优先处理等，如 FIFO
③降低对资源的需求，如设计适应性能要求的拓扑结构或允许有限变更等
(4) 安全性 security 是实现软件各种安全保密措施的有效性度量。
免疫力：系统阻挡攻击企图的能力，可通过更改体系结构保证系统安全特征、最小化系统安全漏洞提高免疫力
弹性：系统快速容易地从成功的攻击中恢复的能力。可通过功能分段使攻击影响最小化、增加快速恢复能力来提升。
(5) 可靠性 reliability 是软件产品在假设的环境下，按照规定的条件和规定的时间区间完成规定功能的能力。
主动故障检测：可以使用周期性检查或预测系统故障，如无法提供服务，提供错误服务，数据损坏，死锁等等；可以使用某种形式的冗余如 n 版本编程。
故障恢复：撤销事务，回退，备份，服务降级，实时修正，实时报告等等。
(6) 健壮性robust是系统在不正确的输入或意外的环境条件下依然保持正确工作的能力。可靠性与软件本身内容是否有错误有关，而健壮性与软件容忍错误或外部环境异常时的表现有关。要防御的设计系统，必须遵循互相怀疑策略，每个软件单元都假设其他软件单元含有故障；在检测故障时，与可靠性策略中的故障恢复基本类似。
(7) 易使用性 usability 是用户能够操作软件系统的容易程度。将用户界面放置于自己的软件单元方便于为不同类型用户定制；系统需要一个进程来监听一些用户发起的命令；系统需要维护一个环境模型来支持系统发起的活动要求。
(8) 商业目标
体系结构风格和设计模式的区别：
1. 定义层次不同：
体系结构风格（Architectural Style）：关注的是软件系统整体的结构与组织方式，强调系统架构的高层次设计。它定义了一组约束、组件和它们之间的交互方式。体系结构风格更侧重于系统整体的架构设计，指导系统如何组织和结构化。
举例：
- 客户端-服务器（Client-Server）：客户端和服务器分开，客户端发起请求，服务器处理请求并返回结果。
- 微服务（Microservices）：将系统分解成小的、独立的服务，每个服务实现特定的功能。
- 分层架构（Layered Architecture）：系统划分为多个层次，每一层负责不同的功能，层与层之间通过定义好的接口进行交互。
设计模式（Design Pattern）：是一种针对软件设计中的常见问题的可复用解决方案。设计模式提供了一种具体的方式来解决在特定情境下出现的设计问题。它更侧重于代码的设计和实现，通常应用于系统的某一模块或某一部分，而非系统的整体架构。
举例：
- 单例模式（Singleton Pattern）：确保一个类只有一个实例，并提供一个全局访问点。
- 观察者模式（Observer Pattern）：定义了一种一对多的依赖关系，使得当对象状态变化时，所有依赖者都会得到通知并自动更新。
- 工厂模式（Factory Pattern）：定义一个创建对象的接口，但由子类决定实例化哪个类。
2. 抽象层次不同：
体系结构风格主要是一个高层次的架构设计思想，它定义了系统如何被整体组织和划分。它描述了系统组件的结构、通信方式以及这些组件如何交互。
设计模式则是一个较低层次的设计方案，通常解决的是单个组件或模块内部的具体设计问题。设计模式是实现某个功能或解决某个设计问题的最佳实践，它更多地关注如何通过具体的类和对象来实现系统中的某个功能。
4.2.4 模块化与抽象层次
(1) 模块化设计 modularity 也称作关注点分离，是一种把系统中各不相关的部分进行分离的原则。在模块化的设计中，构件清晰地定义了输入和输出，设计目标明确，功能独立，可以做独立测试。
(2) 抽象 abstraction：对细节的隐藏称为抽象，是基于某种归纳水平的问题描述，是我们集中于问题的关系。当探讨或分析两个模块共享某数据时,模块各自的私有细节应隐藏。
(3) 模块都以某种不同层次结构的抽象的形式出现, 越上层、越早期的模块层次或框架是越抽象的设计。将模块化部件和抽象层次结合，顶层模块通过隐藏细节可以给出解决方案，其他层次模块显示主要职能和实施细节，就可以用不同的方式设计不同构件的能力。
系统结构设计的核心在于分解；分解的目的在于模块化。
因此模块化的质量相当重要，模块独立性就是模块化质量水平高低最好的衡量标准。
4.3 模块独立性
模块独立取决于两部分：内聚和耦合要记住耦合和内聚的概念、层次划分以及每一种基本分类的含义和实例.
4.3.1 耦合 coupling
耦合度是指两个软件之间的相互关联程度，耦合程度取决于模块之间的依赖关系的多少，可以划分为紧密耦合、松散耦合和非耦合。模块之间的依赖关系有：一个模块引用另一个模块、模块间传递数据量、某个模块控制其他模块的数量。为了使模块可以独立设计和修改，应尽可能减少耦合度。模块耦合有六个级别，从高到底依次为：
(1) 内容耦合 content：一个模块实际上修改了另一个模块，被修改的模块完全依赖于修改他的模块。可能的情况有：一个模块修改另一个模块内部数据项或代码，或分支转移到另一个模块。如 goto 语句
(2) 公共耦合 common：不同模块可以从公共数据存储区来访问和修改数据。
(3) 控制耦合 control：一个模块通过传递参数或返回代码来控制另一个模块的活动
(4) 标记/特征耦合 stamp：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制
(5) 数据耦合 data：模块间传递的是数据值，这是最受欢迎的一种耦合。如一个数值被当做参数传递给另一个模块，这个数值在另一个模块中只会参与计算而非控制。
(6) 非耦合 uncoupled：模块相互之间没有信息传递，如两个毫无关系的方法，但是一般完全没有耦合是不现实的。
面向对象的设计中模块间耦合度较低，面向对象设计目标之一就是实现松散耦合。
因此，可以说面向对象设计在系统体系结构设计层面质量比其他设计方式要高。
4.3.2 内聚 cohesion
内聚度是指模块内部各组成成分（如数据、功能、内部模块）的关联程度，内聚度越高，模块各成分间相互联系越密切，与总目标越相关。内聚分为低内聚和高内聚。下面内聚度从低到高进行介绍：
(1) 偶然内聚 coincidental：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。
(2) 逻辑内聚 logical：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。比如因为有相同的某一个计算步骤而放在一起的两个没有关系的计算。
例如一个用于计算全班学生
平均分和最高分的模块，无论计算哪种分数，都要经
过读入全班学生分数，进行计算，输出计算结果等步
骤。实际上除中间的一步须按不同的方法计算外，
前、后这两步都是相同的。把这两种在逻辑上相似的
功能放在一个模块中，就可省去程序中的重复部分)
(3) 时间内聚 temporal：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。
(4) 过程内聚 procedurally：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。
(5) 通讯内聚 communicational：各部分访问和操作同一数据集，如将来自于同一传感器的所有不相干数据取出这一模块。
(6) 顺序内聚 sequential：各部分有输入输出关系，操作统一数据集，并且操作有顺序。
(7) 功能内聚 functional：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。
(8) 信息内聚 information：功能内聚的基础上调整为数据抽象化和基于对象的设计面向对象设计的目的是高内聚
理解内聚的例子：
1. 功能内聚（Functional Cohesion）
功能内聚是最理想的内聚类型，它指模块内的所有元素都共同完成一个单一的功能。可以想象成一个咖啡机，它的设计目的就是为了冲泡咖啡，所有部件都是为了这一功能服务的。
2. 顺序内聚（Sequential Cohesion）
顺序内聚发生在一个模块中的元素输出是另一个元素的输入。比如，在汽车制造线上，一个工位负责安装轮胎，然后下一个工位是进行轮胎检验的，每个工位的任务都是顺序进行的。
3. 通信内聚（Communicational Cohesion）
通信内聚是指模块中的组件是为了操作同一数据集（例如数据库表）而工作的。例如，一个财务软件模块，它可以包括计算税收、生成财务报表等功能，这些功能都在处理同一批财务数据。
4. 过程内聚（Procedural Cohesion）
过程内聚是指模块中的元素是为了完成某个特定的过程而聚集的，但这些过程并非形成单一的功能。例如，一个文档处理模块可能会包括打开文件、格式化文本和打印文件的功能，这些功能都是按顺序执行的，但并不是为了完成一个独立的功能。
5. 时间内聚（Temporal Cohesion）
时间内聚是指模块中的功能是基于它们在同一时间执行的事实组合的。例如，程序启动时需要执行的一系列初始化功能，如配置内存、加载用户设置等，都是因为它们在相同的时期（启动时）执行。
6. 逻辑内聚（Logical Cohesion）
逻辑内聚是指模块中的元素聚合在一起是因为它们逻辑上类似，通常通过一个控制逻辑（如if-else结构）来选择执行哪个功能。比如，一个应用程序可以有一个打印模块，用于打印文本文件、图像或PDF，用户选择什么文件类型，就执行相应的打印任务。
7. 偶然内聚（Coincidental Cohesion）
偶然内聚是最低级的内聚形式，指模块中的元素毫无逻辑地放在一起。这就像是一个工具箱，里面既有锤子也有螺丝刀和胶带，这些工具之间没有直接的关系，只是碰巧放在一起。
4.4 体系结构的评估和改进
4.4.1 故障树分析
故障树：通过分解设计寻找可能导致实现的情形。根节点表示想分析的故障/失效，其他节点表示事件或者表示导致根节点失效所发生的故障。其中父节点用逻辑门操作表示，与门指二者必须同时发生才会使父节点发生；或门则是发生一个子节点就足以引发父节点。
通过故障树分析，我们可以获取一个割集树，割集指割集树中子节点的集合，表示引起父节点失效所需要的事件的最小集合通过图 5.2 可以看到引发 G1 的割集是图中四个叶子节点。
割集树：每个结点都表示一种可以引发故障的原因集合，越下层则原因集合越小（越具体）
4.4.2 错误预防和容错
(1) 正确区分错误、故障和失效并知道三者的关系（第一章）
(2) 主动进行故障检测：定期检查故障或预测故障，为此应给一个功能预留多个实现途径
(3) 被动故障检测：强化故障恢复
(4) 进行容错设计：当软件失败发生时,采取措施减少损失并将损害隔离开来, 在用户接受的条件下使系统继续运行 .
如何预防错误：
1、概念上理解错误（error）、故障（falut）、失效（failure）的区别。
2、主动检查故障以及修复故障：程序可靠性的一部分
4.4.3 设计复审（review）的两种方法：验证与确认
复审定义：检查文档是否满足所有功能及质量需求。
两种设计检验的方法：
(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确
(2) 确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。
(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。
4.4.4 设计复审的重要性
(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流
(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。
5. 总结
本文到这里就结束啦~~
目前【软件工程】系列已经完成：
【软件工程】第一章·软件工程概述-CSDN博客
【软件工程】第二章·软件过程（过程与生命周期建模）-CSDN博客
【软件工程】第三章·计划和管理项目（详解活动图计算关键路径、最早开始时间、最晚开始时间、冗余时间）-CSDN博客
【软件工程】第四章·需求分析-CSDN博客
持续更新中🎢🎢🎢
如果觉得对你有帮助，友友们可以点个赞，收个藏呀~
