记录督促自己的学习历程6

十二章

这个章节，主要是说明怎么定义功能性和非功能性的可依赖性和信息安全性需求，理解风险驱动的方法是如何识别的分析安全性、可靠性和信息安全性需求的，理解缺陷数如何帮助分析风险和导出安全性需求的，引入了对可靠性描述的度量以及是如何用这些亮度来描述可靠性需求，理解不同种类的可能在复杂系统中需要的信息安全性需求，了解对系统使用形式化的、数学的描述的优缺点。

通过华沙飞机的例子，可以知道，程序可能没有错误，但是软件描述的不完备可能导致极其特殊的情况下，系统的失败。可依赖性和信息安全性需求分为两种，1功能性需求，定义了系统应该包含的检查和修复措施，以及防止系统失败和外部攻击的保护性特征，2非功能性需求，定义了系统需要的可靠性和可用性。这里，需要区别的是这里的功能性非功能性需求和系统的功能性非功能性是不一样的概念， 体现最重要不同的是关于“不应该”的用法，在这里所指的功能性描述里面。最好用“不应该”来描述，这些“不应该”需求不能直接实现，这个样子的设计决策的例子是：决定在一个系统中用特别类型的设备。
可依赖性和信息安全性需求可以认为是保护性需求，它们描述了一个系统怎么保护自己不受内部缺陷破坏，组织系统失败对其运行环境造成损害，阻止来自系统运行环境的事故或攻击破坏系统，以及在失败时间发生时的功能恢复。一个风险驱动方法的需求描述应该考虑到：可能发生的危险时间，这些事件可能真正发生的概率，这样的一个时间可能引起的损失，以及损失可能波及的范围。然后根据危险时间可能造成损失的分析结果，建立信息安全性和可以依赖性需求。
风险驱动描述是安全性和信息安全性要求极高的系统的开发者广泛使用的方式。它注重哪些可能造成最大破坏或可能经常发生的事件。

一般性的风险驱动的描述过程主要是几个步骤：！风险识别2风险分析和分类3风险分解4风险降低，这几个步骤在下面思维导图里面表述得很清楚，对于大型系统来说，风险分析通常被分解为若干个阶段，1初步危险分析，2生命周期风险分析。3运行态风险分析，考虑系统用户界面因素以及操作人员操作失误的风险分析，而且，一旦用户界面设计决策作出，进一步的保护需求必须被加入，以上的这些阶段是必要的，因为在没有完整的系统实现信息基础上作出所有可依赖性和信息安全性决定是不可能的。必须引入系统检查来保证第三方组件时正确运行的，必须修改信息安全性需求，因为它们与一个现有系统提供的信息安全性特性 冲突，
这里出现在附录里面有一个IEC国际电工委员会，提到IEC的安全性管理的标准。IEC可以作为一个知识点做一个扩展。
安全性描述，安全性要求极高系统是指当系统失败时可能影响系统环境并导致在这个环境下人员伤亡的系统。安全性描述主要关注的是识别出能将系统失败发生概率降到最小的需求。
在导出不同的安全性需求中，你需要在安全性和功能性之间找到一个可接受的平衡来避免过度保护。
但是，构建安全系统的前提是要保证话费合理，换句话说就是要保持成本可控。
一般基于风险的描述过程活动，会映射到这些安全性描述过程（这里需要关注一下安全性描述过程，）1风险识别，2风险分析3风险分解4风险降低，风险降低基于风险分析的结果并识别安全性需求，这些可能是关于确保一个危险不会引起或导致事故，或如果一个事故发生了将相关的损坏最小化。

在安全要求极高的系统中，主要风险来自可能导致事故发生的危险，这里有提到胰岛素泵的例子是安全性要求极高的系统，再次需要强调，这里所指的都是系统工程，之前一直对系统工程不是很理解，包括社会技术系统，这里算是比较了解了。对于不太了解的概念没有必要停下脚步，在以后的学习中自然会理解。

危险评估过程注重理解危险发生的频率和危险发生所造成的后果，需要进行分析来理解一个危险是不是对系统或环境的严重威胁，这里，对于危险分析和分类过程的结果时可接受性报告，这里我认为是一个专用概念，风险包含意外发生的可能性和它的后果，主要分为三种风险类型：1不可容忍的风险2低于合理的实际水平ALARP的风险3可接受的风险，此类风险是那些相关联的事故通常引起很小的损失，危险评估过程包括估计风险可能性和风险的严重性。
危险分析是指发现安全性要求极高系统中危险根源的过程，找出什么时间或时间的组合是引起一个是引起一个系统失败的危险，主要是推理技术和归纳法，两种方法都可以用于危险分析。
至于危险分解和分析技术，包括审查和核对表技术、形式化分析技术、形式逻辑和缺陷树分析等，缺陷树危险分析方法很易于理解，并不需要专业领域知识，最开始要识别危险，下图，关于缺陷树分析的图很重要，主要就是由一个大的问题引申出多个子分类，这个是我自己的理解，这里要打一个着重符号，需要经常看一下，实际操作。
在识别出潜在的风险以及其根源后，我们要能够导出安全性需求以管理风险，确保不会发生各种食物，需要作出1危险避免2危险检测和排除3灾害限制。
系统的可靠性取决于硬件可靠性和软件的可靠性，以及操作员的可靠性，同时要包括补偿软件失败的需求，可能还要有相关的可靠性需求，以帮助解决检测和恢复硬件失败和操作员错误。
可靠性和安全性和信息安全性不一样，可靠性是可度量的系统属性，可靠性也是分非功能性和功能性需求两种，风险驱动的可靠性描述主要是1风险确认，2风险分析，3风险分解4风险降低。
总体来讲，可靠性可以描述为系统在一个指定的操作环境中运行时发生失败的概率，用度量来描述可靠性，可以用1请求失败的概率POFOD 2失败发生率ROCOF 3可用性AVAIL，系统的可用性反映出当需要它的时候它体统服务的能力，为品谷系统的可靠性，需要获取系统运行的数据，数据需求可能包括1对确定数量的系统服务请求统计系统失败的次数，这是用来测量POFOD的指标，2系统失败平均间隔时间，或者说是所事务处理的数目，以及总的时间或者是总的事务执行次数，这是用来测量ROCOF和MTTF的，3系统失败导致不能提供服务之后的维修和重启所用的时间，这是用来测量可用性的，可用性不仅取决于失败间隔时间，而且取决于系统恢复运行的时间。

非功能性的可靠性需求是对系统可靠性和可用性的要求作出的量化描述，使用前面讲述的度量之一来计算，导出量化可靠性描述有几个优点1决定可靠性需要的等级的过程有助于弄清楚信息持有者到底需要什么2评估何时可以停止测试一个系统，3它是评估系统可靠性的不同设计策略的方法，4如果一个外部管理者需要在进入一个服务之前许可系统，那么能说明已经叨叨一个要求的可靠性目标的证据在系统认证中很重要。为建立需要的系统可靠性等级，你必须要考虑到系统失败可能造成的相关损失，这里提到几个常用的度量，在上一节中有所提及，看来是十分重要的概念，需要仔细记忆一下才行，分辨是POFOD ROCOF AVIAL ，需要注意是这些度量都是描述可靠性的，因为可靠性是可以被度量的。
对于可靠性的过描述会导致很高的测试费用，这里提到了测试，我又想到了之前章节所讲到的测试和审查的异同，回忆了一下，主要区别在于审查可以从各个阶段对于系统进行检查，但是测试不行。
过描述的根本问题是可能在现实当中不可能证明达到一个很高的可靠性和可用性，可以通过一些步骤来避免 对系统可靠性过度描述1针对不同类型的失败定义可用性和可靠性需求，严重失败的发生概率应该比小的失败 发生的概率低，2针对不同类型的服务定义可用性和可靠性需求，影响最紧要服务的失败发生概率要较低，只有局部影响的失败的发生概率可以相对较高，因而你要限制对影响最紧要系统服务的量化的可靠性描述，3决定是否真正需要软件系统的高可靠性需求，或者是否系统可靠性目标可以通过其他方式达到。
下面就是关于上面三个步骤的例子，借用了一个ATM机的例子进行解释，

动能可靠性描述包括识别影响系统的可靠性的约束和特征的需求，对于可靠性经过量化描述的系统，这些功能性需求对于确保达到可靠性所要求的的水平是必须的，主要是三种功能性可靠性需求1检查需求，2恢复需求3冗余性需求。
系统的信息安全性需求描述与安全性需求有很多相似之处，对它们进行量化描述是不太现实的，信息安全性需求往往是“不应该”需求类型，它定义那些无法接受的系统行为，而不是定义系统功能，但是，信息安全性比安全性更加有挑战性的属性，主要是因为1党靠拢到安全性的时候，可以认为系统所安装的环境不是有敌意的2当系统失败发生并带来安全性的风险时，需要寻找导致失败产生的错误或疏忽，当故意的攻击导致系统失败时，找到根本原因可能更加困难，因为攻击者可能会试图掩盖系统失败的原因3通常关闭系统或者降低系统服务可以避免安全性相关的失败，这些做法是可以接受的，然而对系统的攻击可能是被称为拒绝服务的攻击，目的就是要关闭系统，关闭了系统就意味着攻击成功，4安全相关事件不是由一个聪明对手制造的，而是一个攻击者可以在一系列攻击中试探系统的防御，在他更加了解系统以及系统的反应的时候可以修正攻击的方式。这些区别意味着信息安全性需求成本一定比安全性需求成本高，下面累出了始终系统中的十种信息安全需求。

用于验证系统信息安全性需求有三个步骤，1初步的风险分析2生命周期风险分析3运行风险分析。
形式化方法是基于数学的软件开发方法，通过定义软件的一个模型，接着可以形式化地分析这些模型，并使用它作为一个形式化系统描述的基础，原则上讲，从形式化模型开始构造软件，并证明所开发的程序与这个模型时一致的，由此来消除由于程序错误造成的软件失败。
所有形式化开发过程都开始于形式化系统模型，把它作为系统的描述，由自然语言图和表格等表述组成，形式化描述对于设计的证明和软件的实现不仅仅是必不可少的，形式化描述总是作为计划驱动的软件过程的一部分。
开发形式化描述有许多优势，但是需要注意，形式化描述不适用敏捷开发。

第十三章

可依赖性工程，主要是讨论开发高可依赖性系统的过程和技术，了解系统可依赖性是怎么样通过使用冗余的和多样的组件实现的，知道可依赖性软件过程是怎么样支持可依赖性软件开发的，理解可能使用的不同的系统体系结构风格来实现软件的冗余性和多样性，了解应该在可依赖性系统工程中使用的好的编程实践，
软件工程技术的使用，更好的编程语言和更好质量的管理使得大多数软件的可依赖性得到了显著的提高，特殊的软件开发工具和技术通常增加了系统开发的话费，但是它们降低了系统失败的风险以及失败可能造成的损失。
可依赖性工程是关于在要求极高和非要求极高的系统中所采用的的技术。这个学虎山公园支持3个用在开发可依赖性软件方面的补充方法：1缺陷避免2缺陷检测3容错
但是，用错误避免和错误检测以及容错技术导致出现了一个投入收益递减的状态，软件开发公司默认他们的软件存在一些残余缺陷，允许缺陷的水平依赖于系统类型，塑封产品允许相对较高的缺陷水平，而要求极高的系统通常要求较低的缺陷密度。
可以接受的缺陷的基本原则是，当系统失败时，失败后果造成的损失比在系统发布之前发现和删除它们的费用要少。
要求极高系统的开发过程不仅仅是关于制造一个可依赖的系统的污染难题，它必须同时制造出证据来让监管者相信系统是可依赖的，这里我认为很重要，因为需要制造出证据来让别人相信系统是可依赖的，这个地方没有举例子，需要后期解决一下，制造一个证据要花很大比例的开发费用，所以要求极高的系统很昂贵重要原因之一，这是其中一个原因。
冗余性和多样性是增强任何类型系统的可依赖性的基本策略，冗余性意味着系统中包含多余的能力可以在系统失败的时候发生作用，多样性以为着冗余的系统组件时属于不同种类的，这样就会增加它们不会以完全一样的方式失败的机会。
我们使用冗余性和多样性来增加我们日常生活中的可依赖性，灯泡例子挺好，设计用来增强可依赖性的软件系统可能包括提供与系统中的其他组件相同功能的冗余组件，这些组件在主组件失败的时候被选择加入系统。
在可用性要求高的系统中，冗余的服务常常被使用，多样性和冗余性可能同样用于获得一个可依赖的过程，这是通过确保过程活动不依赖于单个过程或方法而实现。这样增强了软件的可依赖性。
获得软件的多样性不是简单的，多样性和冗余性使得系统更加复杂并且通常难以理解。所以目前有两种思维方式，一种认为越简单越好，一种则是觉得需要足够的冗余性和多样性。
当然两种都同时存在。
可依赖软件过程是用来开发可依赖软件的软件过程，公司使用了可依赖过程可以保证这个过程能的到正确执行和文档化，对于外部管理者来说，应用可依赖过程的证据能令他们相信在软件开发中已经使用了最有效的的软件工程实践，过程必须被明确地定义并且是可重现的1明确定义的过程就是用已定义的过程模型来驱动软件生产过程，在过程中必须有数据收集说明过程模型中所有必要的步骤都得到了执行2可重复的过程是一个不依赖于个别解释和判断的过程。
可依赖过程利用冗余性和多样性来获得可靠性，我们必须有完善定义的质量管理和变更管理过程。需要注意的是敏捷方法并不是很适合可依赖性过程 ，敏捷方法专注在于软件开发而不关心如何将已经做好的东西写成文档，敏捷方法经常用相对非正式的方法来实现变更和质量管理，用基于计划的方法来开发可依赖系统时，创建文档能让外部管理者和其他外部信息持有者都可以理解，通常是首选方法，尽管如此，敏捷方法的益处同样可以适用于要求极高的系统中。很有可能开发出多种适合要求极高的系统工程的敏捷方法。

可依赖性系统开发应该基于一个可依赖性过程，然而，尽管你可能需要一个可依赖性过程来创建可依赖系统，其本身并不足以保证可依赖性，同样需要为可依赖性设计一个系统体系结构，尤其是当需要容错机制的时候，就要求系统体系结构必须设计成包含冗余组件和机制，能够允许控制可以从一个组件到另一个组件进行切换，
可依赖性系统体系结构最简单的实现是带复制的服务器，两个或者多个服务器完成同样的任务，也就是备份服务器，这种带复制的服务器方法广泛使用在事务处理系统，很容易维护要处理的事务处理的多个拷贝。
带复制的服务器提供冗余性，单并不经常提供多样性，软件多样性和冗余性可以被实现为多种不同的体系结构风格。
保护性系统是一种与其他系统相关联的专用系统，通常是对一些过程的控制系统，附带的或者例子很有代表性，保护性系统软件可以比控制被保护过程的软件简单得多，保护性系统的唯一功能是监视操作并确保紧急情况下系统被带回安全状态。
自监控系统体系结构是指系统设计成监视其自身的操作并在问题探测到的时候采取某些行动，这是通过在不同的通道计算并比较计算的输出来实现的。
为了能够很好的探测硬件和软甲你缺陷，自监控系统必须被设计成1在每一种通道上使用的硬件是多样的2在不同的用到上使用不同的软件，这种体系结构可以用于计算的正确性非常重要单可用性并不是至关重要的情况下。

N-版本编程，我刚刚开始看到这个题目是一脸懵的，自监控系统体系结构是采用多版本编程提供软件冗余性和多样性的系统的例子，这个多版本编程的概念源自硬件系统中的三重组合冗余性TMR，这个概念已经在构建容许硬件失败的系统中用了很多年，这个东西，硬件的话，让我想到了现在CPU常用的温度过高保护系统，现在还不知道对不对，之后看看再说，留一个疑问在这里。
这个容错方法依赖于大多数硬件失败的原因是组件失败造成的而不是设计缺陷造成的。
借鉴硬件的多版本增多冗余性的方法，软件上也用相同的思路，在一个公用描述下，同一个软件系统由多个小组实现，这些版本在不同的计算机上执行，使用一个投票系统比较它们的输出，不一致的输出或者未能及时产生的输出被拒绝掉。
总体来说，我认为就自监控和多版本两种方法，主要区别在于软件两种方法的可用性和可靠性之间轻重的问题。
所有以上的容错体系结构都依赖于软件的多样性以获得容错功能，这一点基于的假设是，对于描述的不同实现之间是相互独立的，它们不应该包含同样的错误，这样也就不会以同样的方式同时失败。为了保持软件多样性，将会分不同开发者编写，不能交流
采购系统对的公司可能包含明确的多样性政策，比如1需求中明确要求使用不同的设计方法2规定成都要由不同的编程语言实现3要求对系统的开发要使用不同的工具和不同的开发环境4明确地要求在实现的某些部分用不同的算法。
上面所说的有一个前提就是不同的开发者都应该根据一个详细的系统描述工作，而这个描述是从系统的需求描述中导出的。
但是通过多版本增加可依赖性的额外开发费用是否值得，对于很多系统来说，这样的额外花销可能是不合理的。对于失败代价高的系统中，这种模式才能有空间执行。

有一套已经被接受的好的编程实践，它们相当普遍而且可以减少在交付的系统中的缺陷，这里书里面提到了几个知道准则，1限制程序中信息的可见性，2检查所有输入的有效性，3为所有的一场提供处理4最小化使用容易出错的结构5提供重启能力6检查数组边界
7当调用外部组件时加入超时处理功能8为每一个代表现实世界值的常量命名
对于检查输入，有几个重点1范围检查2位数检查3表现检查4合理性检查
这里提到了对于异常进行处理的一些方法，一般要做一件或者几件1向更高层组件发送信号报告一个异常一件发生，并提供异常类型信息，2实现一些代替处理来替换原始准备的处理，3传递控制到能处理异常的运行时支持系统

对于指导准则四，提到了几个由于编程语言结构和编程技术本质上容易犯的错，需要尽量少用潜在容易犯错的结构有1无条件分之2浮点数3指针4动态内存分配5并行6递归7中断8继承9别名10无界数组11默认输入的处理
这里，这一章提到很多关于编程方面需要规避的错误和减少错误发生的方法，虽然我现在不能使用的理解，后面在学习编程语言的时候会用到，所以，这里要做一个重点符号，之后用到的时候能及时找到。