免费智能真题库 > 历年试卷 > 系统架构设计师 > 2009年下半年 系统架构设计师 下午试卷 论文
  第4题      
  知识点：   结构化设计   软件架构   测试方法   可靠性   可靠性测试   可靠性设计   模块化   软件工程   软件可靠性设计   软件设计   软件设计阶段   设计阶段   预测

 
目前在企业中，以软件为核心的产品得到了广泛的应用。随着系统中软件部分比例的不断增加，使得系统对软件的依赖性越来越强，对软件的可靠性要求也越来越高。软件可靠性与其他质量属性一样，是衡量软件架构的重要指标。
软件工程中己有很多比较成熟的设计技术，如结构化设计、模块化设计、自顶向下设计等，这些技术为保障软件的整体质量发挥了重要作用。在此基础上，为了进一步提高软件的可靠性，通常会采用一些特殊的设计技术，即软件可靠性设计技术。
在软件可靠性工程体系中，包含有可靠性模型与预测、可靠性设计和可靠性测试方法等。实践证明，保障软件可靠性最有效、最经济、最重要的手段是在软件设计阶段采取措施进行可靠性控制。
 
问题：4.1   请围绕“软件可靠性设计与应用”论题，依次从以下三个方面进行论述。
1. 概要叙述你参与实施的软件开发项目以及你所承担的主要工作。
2. 简要叙述影响软件可靠性的因素有哪些。
3. 阐述常用的软件可靠性设计技术以及你如何应用到实际项目中，效果如何。
 
 
 

   知识点讲解    
   · 结构化设计    · 软件架构    · 测试方法    · 可靠性    · 可靠性测试    · 可靠性设计    · 模块化    · 软件工程    · 软件可靠性设计    · 软件设计    · 软件设计阶段    · 设计阶段    · 预测
 
       结构化设计
        结构化设计包括架构设计、接口设计、数据设计和过程设计等任务。它是一种面向数据流的设计方法，是以结构化分析阶段所产生的成果为基础，进一步自顶而下、逐步求精和模块化的过程。
        在结构化方法中，模块化是一个很重要的概念，它是指将一个待开发的软件分解成为若干个小的简单部分——模块。每个模块可以独立地开发、测试。这是一种复杂问题的“分而治之”原则，其目的是使程序的结构清晰、易于测试与修改。
        具体来说，模块是指执行某一特定任务的数据结构和程序代码。通常将模块的接口和功能定义为其外部特性，将模块的局部数据和实现该模块的程序代码称为内部特性。在模块设计时，最重要的原则就是实现信息隐蔽和模块独立。模块通常具有连续性，也就意味着作用于系统的小变动将导致行为上的小变化，同时规模说明的小变动也将影响到一小部分模块。
               抽象化
               对软件进行模块设计的时候，可以有不同的抽象层次。在最高的抽象层次上，可以使用问题所处环境的语言描述问题的解法。而在较低的抽象层次上，则宜采用过程化的方法。抽象化包括对过程的抽象、对数据的抽象和对控制的抽象。
               （1）过程的抽象。在软件工程过程中，从系统定义到实现，每进展一步都可以看做是对软件解决方案的抽象化过程的一次细化。在从概要设计到详细设计的过程中，抽象化的层次逐渐降低，当产生源程序时到达最低的抽象层次。
               （2）数据抽象。数据抽象与过程抽象一样，允许设计人员在不同层次上描述数据对象的细节。
               （3）控制抽象。控制抽象可以包含一个程序控制机制而无须规定其内部细节。
               自顶向下，逐步求精
               将软件的架构按自顶向下方式，对各个层次的过程细节和数据细节逐层细化，直到用程序设计语言的语句能够实现为止，从而最后确立整个架构。最初的说明只是概念性地描述了系统的功能或信息，但并未提供有关功能的内部实现机制或有关信息的内部结构的任何信息。设计人员对初始说明仔细推敲，进行功能细化或信息细化，给出实现的细节，划分出若干成分。然后再对这些成分，施行同样的细化工作。随着细化工作的逐步展开，设计人员就能得到越来越多的细节。
               信息隐蔽
               信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单一的设计模块中，并且尽可能少地暴露其内部的处理过程。通常会将困难的决策、可能修改的决策、数据结构的内部连接，以及对它们所做的操作细节、内部特征码、与计算机硬件有关的细节等隐蔽起来。
               通过信息隐蔽可以提高软件的可修改性、可测试性和可移植性，它也是现代软件设计的一个关键性原则。
               模块独立
               模块独立是指每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系最简单。保持模块的高度独立性，也是在设计时的一个很重要的原则。通常用耦合（模块之间联系的紧密程度）和内聚（模块内部各元素之间联系的紧密程度）两个标准来衡量，我们的目标是“高内聚、低耦合”。
               模块的内聚类型通常可以分为7种，根据内聚度从高到低的排序如下表所示。
               
               模块的内聚类型
               模块的耦合类型通常也分为7种，根据耦合度从低到高排序如下表所示。
               
               模块的耦合类型
               除了满足以上两大基本原则之外，通常在模块分解时还需要注意：保持模块的大小适中；尽可能减少调用的深度；直接调用该模块的次数应该尽量多，但调用其他模块的次数则不宜过多；保证模块是单入口、单出口的；模块的作用域应该在模块之内；功能应该是可预测的。
 
       软件架构
        随着嵌入式技术的发展，特别是在后PC时代，嵌入式软件系统得到了极大的丰富和发展，形成了一个完整的软件体系，如下图所示。这个体系自底向上由3部分组成，分别是嵌入式操作系统、支撑软件和应用软件。
        
        嵌入式系统的软件架构
        嵌入式操作系统（Embedded Operating System，EOS）由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务，其他大部分的功能则由支撑软件完成。
        嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲，软件的开发环境大部分在通用台式计算机和工作站上运行，但从逻辑上讲，它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中，如智能手机、个人数字助理等。
        嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。
 
       测试方法
        根据是否执行软件，将软件测试方法分为静态测试和动态测试。动态测试是建立在程序的执行过程中，根据是否要求了解被测对象的内部，分为黑盒测试和白盒测试。
               静态测试和动态测试
                      静态测试
                      静态测试方法包括检查单和静态分析方法，对软件文档的静态测试方法主要是以检查单的形式进行文档审查，而对软件代码的静态测试方法一般采用代码审查、代码走查和静态分析的形式进行。
                      静态分析是一种对代码的机械性和程序化的特性分析方法。一般包括控制流分析、数据流分析、接口分析和表达式分析。
                      代码审查是检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审。
                      代码走查是由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，按照程序的逻辑，逐步运行测试用例，查找被测软件缺陷。代码走查应由测试人员集体阅读讨论程序，是用“人脑”执行测试用例并检查程序。
                      对于规模较小、安全性要求很高的代码也可进行形式化证明。静态分析常需要使用软件工具进行。
                      静态测试的特点有：不必设计在计算机上执行的测试用例；可充分发挥人的逻辑思维优势；不需特别条件，容易开展；发现错误的同时也就定位了错误，不需作额外的错误定位工作。
                      动态测试
                      动态测试是建立在程序的执行过程中，根据是否对被测对象内部的了解，分为黑盒测试和白盒测试。
                      黑盒测试是一种按照软件功能说明设计测试数据的技术，不考虑程序内部结构和编码结构，也不需考虑程序的语句及路径，只需了解输入／输出之间的关系，依靠这一关系和软件功能说明确定测试数据，判定测试结果的正确性。黑盒测试又称功能测试、数据驱动测试或基于需求的测试。
                      白盒测试是一种按照程序内部逻辑结构和编码结构设计测试数据的技术，可以看到程序内部结构，并根据内部结构设计测试数据，使程序中的每个语句、每个条件分支、每个控制路径的覆盖情况都在测试中受到检验。白盒测试又称结构测试、逻辑测试或基于程序的测试。
                      动态测试的特点有：实际运行被测程序；必须设计测试用例来运行；测试结果分析工作量大，测试工作费时、费力；投入人员多、设备多，处理数据多，要求有较好的管理和工作规程。
                      在软件动态测试过程中，应采用适当的测试方法，实现测试要求。配置项测试和系统测试一般采用黑盒测试方法；部件测试一般主要采用黑盒测试方法，辅助以白盒测试方法；单元测试一般采用白盒测试方法，辅助以黑盒测试方法。
               黑盒测试
               黑盒测试方法一般采用功能分解、等价类划分、边界值分析、判定表、因果图、随机测试、猜错法和正交试验法等。
                      功能分解
                      功能分解是将需求规格说明中每一个功能加以分解，确保各个功能被全面地测试。功能分解是一种较常用的方法。
                      步骤如下：
                      （1）使用程序设计中的功能抽象方法把程序分解为功能单元。
                      （2）使用数据抽象方法产生测试每个功能单元的数据。
                      功能抽象中程序被看成一种抽象的功能层次，每个层次可标识被测试的功能，层次结构中的某一功能有由其下一层功能定义。按照功能层次进行分解，可以得到众多的最低层次的子功能，以这些子功能为对象，进行测试用例设计。
                      数据抽象中，数据结构可以由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集。程序的每一个输入和输出量的取值集合用数据抽象来描述。
                      等价类划分
                      等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试用例。
                      步骤如下：
                      （1）划分有效等价类：对规格说明是有意义、合理的输入数据所构成的集合。
                      （2）划分无效等价类：对规格说明是无意义、不合理的输入数据所构成的集合。
                      （3）为每一个等价类定义一个唯一的编号。
                      （4）为每一个等价类设计一组测试用例，确保覆盖相应的等价类。
                      边界值分析
                      边界值分析是针对边界值进行测试的。使用等于、小于或大于边界值的数据对程序进行测试的方法就是边界值分析方法。
                      步骤如下：
                      （1）通过分析需求规格说明，找出所有可能的边界条件。
                      （2）对每一个边界条件，给出满足和不满足边界值的输入数据。
                      （3）设计相应的测试用例。
                      对满足边界值的输入可以发现计算错误，对不满足的输入可以发现域错误。该方法会为其他测试方法补充一些测试用例，绝大多数测试都会用到本方法。
                      判定表
                      判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件组合的取值及其相应要执行的操作构成规则，条目中的每一列是一条规则。
                      条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试用例。
                      建立并优化判定表，把判定表中每一列表示的情况写成测试用例。
                      该方法的使用有以下要求：
                      （1）需求规格说明以判定表形式给出，或是很容易转换成判定表。
                      （2）条件的排列顺序不会影响执行哪些操作。
                      （3）规则的排列顺序不会影响执行哪些操作。
                      （4）每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
                      （5）如果某一规则的条件的满足，将执行多个操作，这些操作的执行与顺序无关。
                      因果图
                      因果图方法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试用例。
                      步骤如下：
                      （1）分析需求规格说明，引出原因（输入条件）和结果（输出结果），并给每个原因和结果赋予一个标识符。
                      （2）分析需求规格说明中语义的内容，并将其表示成连接各个原因和各个结果的“因果图”。
                      （3）在因果图上标明约束条件。
                      （4）通过跟踪因果图中的状态条件，把因果图转换成有限项的判定表。
                      （5）把判定表中每一列表示的情况生成测试用例。
                      如果需求规格说明中含有输入条件的组合，宜采用本方法。有些软件的因果图可能非常庞大，根据因果图得到的测试用例数目非常多，此时不宜使用本方法。
                      随机测试
                      随机测试指测试输入数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难，多用于可靠性测试和系统强度测试。
                      猜错法
                      猜错法是有经验的测试人员，通过列出可能有的错误和易错情况表，写出测试用例的方法。
                      正交实验法
                      正交实验法是从大量的实验点挑出适量的、有代表性的点，应用正交表，合理地安排实验的一种实验设计方法。
                      利用正交实验法来设计测试用例时，首先要根据被测软件的需求规格说明找出影响功能实现的操作对象和外部因素，把它们当作因子，而把各个因子的取值当作状态，生成二无的因素分析表。然后，利用正交表进行各因子的状态的组合，构造有效的测试输入数据集，并由此建立因果图。这样得出的测试用例的数目将大大减少。
               白盒测试
               白盒测试方法一般包括控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、修订的条件／判定覆盖MC/DC、条件组合覆盖测试、路径覆盖测试）、数据流测试、程序变异、程序插桩、域测试和符号求值等。
                      控制流测试
                      控制流测试依据控制流程图产生测试用例，通过对不同控制结构成分的测试验证程序的控制结构。所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行，也称这一过程为覆盖。以下介绍几种覆盖：
                      （1）语句覆盖。语句覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被遍历，语句覆盖在测试中主要发现错误语句。
                      （2）分支覆盖。分支覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分支至少执行一次，分支覆盖也称判定覆盖。
                      （3）条件覆盖。条件覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中的每个条件的可能取值至少满足一次。
                      （4）修订的条件／判定覆盖（MC/DC——Modified Condition/Decision Coverage）。修订的条件／判定覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判定中的每个条件都曾独立的影响判定的结果至少一次（独立影响意思是在其他的条件不变的情况下，只改变一个条件，就可影响整个判定的值）。
                      对安全性要求比较高的软件，一般采用此覆盖要求。此覆盖要求在测试用例的效率和数量之间较为平衡。
                      （5）条件组合覆盖。条件组合覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中条件的各种组合至少出现一次，这种方法包含了“分支覆盖”和“条件覆盖”的各种要求。
                      （6）路径覆盖。路径覆盖要求设计适当数量的测试用例，运行被测程序，使得程序沿所有可能的路径执行，较大程序的路径可能很多，所以在设计测试用例时，要简化循环次数。
                      以上各种覆盖的控制流测试步骤如下：
                      （1）将程序流程图转换成控制流图。
                      （2）经过语法分析求得路径表达式。
                      （3）生成路径树。
                      （4）进行路径编码。
                      （5）经过译码得到执行的路径。
                      （6）通过路径枚举产生特定路径的测试用例。
                      控制流图是描述程序控制流的一种图示方式，它由结点和定向边构成。控制流图的结点代表一个基本块，定向边代表控制流的方向。其中要特别注意的是，如果判断中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符连接的逻辑表达式，则需要改变复合条件的判断为一系列单个条件的嵌套的判断。控制流图的基本结构如下图所示。
                      
                      控制流图基本结构
                      数据流测试
                      数据流测试是用控制流程图对变量的定义和引用进行分析，查找出未定义的变量或定义了而未使用的变量，这些变量可能是拼错的变量、变量混淆或丢失了语句。数据流测试一般使用工具进行。
                      数据流测试通过一定的覆盖准则，检查程序中每个数据对象的每次定义、使用和消除的情况。
                      数据流测试步骤：
                      （1）将程序流程图转换成控制流图。
                      （2）在每个链路上标注对有关变量的数据操作的操作符号或符号序列。
                      （3）选定数据流测试策略。
                      （4）根据测试策略得到测试路径。
                      （5）根据路径可以获得测试输入数据和测试用例。
                      动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析检查的局限，但动态方式检查是沿与测试输入有关的一部分路径进行的，检查的全面性和程序结构覆盖有关。
                      程序变异
                      程序变异是一种错误驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小错误。本方法应用于测试工具。
                      程序插装
                      程序插装是向被测程序中插入操作以实现测试目的方法。程序插装不应该影响被测程序的运行过程和功能。
                      有很多的工具有程序插装功能。由于数据记录量大，手工进行将是一件很烦琐的事。
                      域测试
                      域测试是要判别程序对输入空间的划分是否正确。该方法限制太多，使用不方便，供有特殊要求的测试使用。
                      符号求值
                      符号求值是允许数值变量取“符号值”以及数值。符号求值可以检查公式的执行结果是否达到程序预期的目的；也可以通过程序的符号执行，产生出程序的路径，用于产生测试数据。符号求值最好使用工具，在公式分支较少时手工推导也是可行的。
 
       可靠性
        （1）完备性。完备性评价指标及测量，如下表所示。
        
        完备性评价指标及测量
        （2）连续性。连续性评价指标及测量，如下表所示。
        
        连续性评价指标及测量
        
        （3）稳定性。稳定性评价指标及测量，如下表所示。
        
        稳定性评价指标及测量
        （4）有效性。有效性评价指标及测量，如下表所示。
        
        有效性评价指标及测量
        （5）可追溯性。可追溯性评价指标及测量，如下表所示。
        
        可追溯性评价指标及测量
        
 
       可靠性测试
        软件可靠性是软件质量的一个重要标志。美国电气和电子工程师协会（IEEE）将软件可靠性定义为：系统在特定的环境下，在给定的时间内无故障地运行的概率。软件可靠性涉及软件的性能、功能、可用性、可服务性、可安装性，以及可维护性等多方面特性，是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。
        可靠性测试一般伴随着强壮性测试，是评估软件在运行时的可靠性，通过测试确认平均无故障时间（Mean Time to Failure，MTTF）、故障发生前平均工作时间（Mean-Time-To-First-Failure，MTTFF）或因故障而停机的时间（Mean Time To Repairs，MTTR）在一年中应不超过多少时间。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。
 
       可靠性设计
        嵌入式系统硬件相关的可靠性设计往往是为“在有限的资源下尽可能提高可靠性”。因此可靠性设计通常需要考虑如下因素，以平衡不同因素对可靠性的影响：
        .有效的散热，降低高温对系统的危害；
        .尽量减少高敏感元器件的使用；
        .更多的使用可靠度高、质量好的元器件；
        .指定采用屏蔽性好或者内嵌的测试方法；
        .使用最少的元器件设计出来简单的电路；
        .在电子元器件级别进行冗余。
        温度是影响所有电子元器件的重要因素之一，而所有元器件都会产生热量。过高的温度会对元器件造成不可逆转的损伤，并阻碍电流流动。而且高温也是元器件损害的最主要的原因。同时过低温也会损坏电子设备。一般来说设备需要工作在所设计的环境中，不同级别的设备会对不同环境的耐受级别不同，因此根据不同用途要选择合适的设备，同时使用适当的散热或者保温措施。
        重要的是，元器件工作在标称额定值（环境）以内对电子设备的可靠性会有较大的提升。对于电容、电阻等元器件和各类芯片，都会对电压、电阻、功率、频率等有着严格的规定。保证电子元器件、电路工作在合理的环境中可以有效的保护元器件、降低故障发生的可能，提高可用性。此外选用高可靠的元器件也可以有效地提高可靠性。在选用可靠的元器件并对环境做出保证后，还应当进行筛选和老化实验保证元器件的一部分不合格元器件筛除。
        根据概率论的相关知识，若假设所有元器件出错的概率为p，而n个元器件中任意元器件出错都会导致系统崩溃，则整个系统出错的概率为1-（1-p）n。当n增加时，出错的概率会以指数形式增长。因此，降低元器件个数、简化设计可以有效地降低故障发生的概率从而提高可靠性。当一个部件的故障率为p而同时有n个冗余部件时，其整体故障的概率为pn。可以看出，当冗余元器件增多的时候，整体的故障概率会成指数形式降低。因此，有效的冗余设计可以保证系统的可靠性提高。
 
       模块化
        模块是程序中数据说明、可执行语句等程序对象的集合，或者是单独命名和编址的元素。在系统体系结构中，模块是可组合、可分解和可更换的单元。
        模块化是指解决一个复杂问题时自顶向下逐层把系统划分成若干模块的过程。每个模块完成一个特定的子功能，所有的模块按某种方法组装起来，成为一个整体，完成整个系统所要求的功能。
        开发一个大而复杂的系统，将它进行适当的分解，不但可降低其复杂性，还可减少开发工作量，从而降低开发成本，提高软件生产率。这是模块划分的依据。
        （1）划分模块时，尽量做到高内聚、低耦合，保持模块的相对独立性，并以此原则优化初始的系统体系结构。
        （2）一个模块的作用范围应在其控制范围之内，且判定所在的模块应与受其影响的模块在层次上尽量靠近。
        一个模块的作用范围是指受该模块内一个判定影响的所有模块的集合。一个模块的控制范围指模块本身及其所有下属模块（直接或者间接从属于它的模块）的集合。
        （3）系统结构的深度、宽度、扇入和扇出应适当。
        （4）模块的大小要适中。
 
       软件工程
        1）软件工程的概念
        为了消除软件危机，通过认真研究解决软件危机的方法，人们认识到软件工程是使计算机软件走向科学的途径，逐渐形成了软件工程的概念，并开辟工程学的新兴领域，即软件工程学。
        2）软件工程的要素
        软件工程具有以下3个要素。
        （1）方法。完成软件工程项目的技术手段。
        （2）工具。支持软件的开发、管理、文档生成。
        （3）过程。将方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。
        3）软件生命周期
        软件生命周期是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程，包括计划阶段、分析阶段、设计阶段、实现阶段、测试阶段和运行维护阶段。
        4）软件开发模型
        比较经典的软件开发模型有瀑布模型、快速原型模型、演化模型、增量模型、螺旋模型、喷泉模型等。
        5）软件开发方法
        软件开发方法有以下几种。
        （1）结构化软件开发（SASD）方法：采用结构化技术来完成软件开发的各项任务。它把软件生命周期划分成若干个阶段，依次完成每个阶段的任务。它与瀑布模型有很好的结合度，是与其最相适应的软件开发方法。
        （2）面向数据结构的软件开发方法：从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其他细节，从而可得到完整的程序结构图。有Jackson方法和Warnier方法。
        （3）面向对象的软件开发方法：随着OOP（面向对象编程）向OOD（面向对象设计）和OOA（面向对象分析）的发展，最终形成面向对象的软件开发方法OMT（Object Modelling Technique）。这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、输出数据结构，实际上也包含了所有对象的数据结构。
        （4）基于构件化的开发方法：用预先建立的构件和模板，像"搭积木"一样进行建造。
 
       软件可靠性设计
        在测试阶段我们利用测试手段收集测试数据，并利用软件可靠性模型，可以评估或预测软件的可靠性，这些软件可靠性测试活动虽然能通过查错-排错活动有限地改善软件可靠性，但不能从根本上提高软件的可靠性，也难以保证软件可靠性，并且修改由于设计导致的软件缺陷，有可能付出比较昂贵的代价。实践证明，保障软件可靠性最有效、最经济、最重要的手段是在软件设计阶段采取措施进行可靠性控制。为了从根本上提高软件的可靠性，降低软件后期修改的成本和难度，人们提出了可靠性设计的概念。
        可靠性设计其实就是在常规的软件设计中，应用各种方法和技术，使程序设计在兼顾用户的功能和性能需求的同时，全面满足软件的可靠性要求，即采用一些技术手段，把可靠性“设计”到软件中去。软件可靠性设计技术就是以提高和保障软件的可靠性为目的，在软件设计阶段运用的一种特殊的设计技术。
        在软件工程中已有很多比较成熟的设计技术，如结构化设计、模块化设计、自顶向下设计、自底向上设计等，这些技术是为了保障软件的整体质量而采用的，在此基础上，为了进一步提高软件的可靠性，通常会采用一些特殊设计技术。虽然软件可靠性设计技术与普通的软件设计技术没有明显的界限，但软件可靠性设计仍要遵循一些自己的原则：
        ①软件可靠性设计是软件设计的一部分，必须在软件的总体设计框架中使用，并且不能与其他设计原则相冲突。
        ②软件可靠性设计在满足提高软件质量要求的前提下，以提高和保障软件可靠性为最终目标。
        ③软件可靠性设计应确定软件的可靠性目标，不能无限扩大化，并且排在功能度、用户需求、开发费用之后考虑。
        可靠性设计概念被广为引用，但并没有多少人能提出非常实用并且广泛运用的可靠性设计技术。一般来说，被认可的且具有应用前景的软件可靠性设计技术主要有容错设计、检错设计、降低复杂度设计等技术。
               容错设计技术
               对于软件失效后果特别严重的场合，如飞机的飞行控制系统、空中交通管制系统、核反应堆安全控制系统等，可采用容错设计方法。常用的软件容错技术主要有三种方法：恢复块设计、N版本程序设计和冗余设计。
               . 恢复块设计。
               程序的执行过程可以看成是由一系列操作构成的，这些操作又可由更小的操作构成。恢复块设计就是选择一组操作作为容错设计单元，从而把普通的程序块变成恢复块。被选择用来构造恢复块的程序块可以是模块、过程、子程序、程序段等。
               一个恢复块包含有若干个功能相同、设计差异的程序块文本，每一时刻有一个文本处于运行状态。一旦该文本出现故障，则用备份文本加以替换，从而构成“动态冗余”。软件容错的恢复块方法就是使软件包含有一系列恢复块。
               . N版本程序设计。
               N版本程序的核心是通过设计出多个模块或不同版本，对于相同初始条件和相同输入的操作结果，实行多数表决，防止其中某一软件模块/版本的故障提供错误的服务，以实现软件容错。为使此种容错技术具有良好的结果，必须注意以下两个方面：
               ①使软件的需求说明具有完全性和精确性。这是保证软件设计错误不相关的前提。因为软件的需求说明是不同设计组织和人员的惟一共同出发点。
               ②设计全过程的不相关性。它要求各个不同的软件设计人员彼此不交流，程序设计使用不同的算法、不同的编程语言、不同的编译程序、不同的设计工具、不同的实现方法和不同的测试方法。为了彻底保证软件设计的不相关性，甚至提出设计人员应具有不同的受教育背景，来自不同地域、不同的国家。
               . 冗余设计。
               改善软件可靠性的一个重要技术是冗余设计。在硬件系统中，在主运行的系统之外备用额外的元件或系统，如果出现一个元件故障或系统故障，则立即更换冗余的元件或切换到冗余的系统，则该硬件系统仍可以维持运行。在软件系统中，冗余技术的运用有所区别。如果我们采用相同两套软件系统作为互为备份，其意义不大，因为在相同的运行环境中，一套软件出故障的地方，另外一套也一定会出现故障。软件的冗余设计技术实现的原理是在一套完整的软件系统之外，设计一种不同路径、不同算法或不同实现方法的模块或系统作为备份，在出现故障时可以使用冗余的部分进行替换，从而维持软件系统的正常运行。
               从表面上看，设计开发完成同样功能但实现方法完全不同的两套软件系统，需要的费用可能接近于单个版本软件开发费用的两倍，但采用冗余技术设计软件所增加的额外费用肯定远低于重新设计一个版本软件的费用。这是因为大多数设计花费，例如文档、测试以及人力都是有可能复用的。冗余设计还有可能导致软件运行时所花费的存储空间、内存消耗以及运行时间有所增加，这就需要在可靠性要求和额外付出代价之间作出折衷。
               检错技术
               在软件系统中，无需在线容错的地方，或不能采用冗余设计技术的部分，如果对可靠性要求较高，故障有可能导致严重的后果，一般采用检错技术，在软件出现故障后能及时发现并报警，提醒维护人员进行处理。检错技术实现的代价一般低于容错技术和冗余技术，但它有一个明显的缺点，就是不能自动解决故障，出现故障后如果不进行人工干预，将最终导致软件系统不能正常运行。
               采用检错设计技术要着重考虑几个要素：检测对象、检测延时、实现方式、处理方式。
               . 检测对象：检测对象包含两个层次的含义，检测点和检测内容。在设计时应考虑把检测点放在容易出错的地方，和出错对软件系统影响较大的地方；检测内容选取那些有代表性的、易于判断的指标。
               . 检测延时：从软件发生故障到被自检出来是有一定延时的，这段延时的长短对故障的处理是非常重要的，因此，在软件检错设计时要充分考虑到检测延时。如果延时长到影响故障的及时报警，则需要更换检测对象或检测方式。
               . 实现方式：最直接的一种实现方式是判断返回结果，如果返回结果超出正常范围，则进行异常处理。计算运行时间也是一种常用的技术，如果某个模块或函数运行超过预期的时间，可以判断出现故障。另外，还有置状态标志位等多种方法，自检的实现方式要根据实际情况来选用。
               . 处理方式：大多数检错采用“查出故障-停止软件系统运行-报警”的处理方式，但也有采用不停止或部分停止软件系统运行的情况，这一般由故障是否需要实时处理来决定。
               降低复杂度设计
               前面我们讲到，软件和硬件最大的区别之一就是软件的内部结构比硬件复杂得多，我们用软件复杂度来定量描述软件的复杂程度。软件复杂性常分为模块复杂性和结构复杂性。模块复杂性主要包含模块内部数据流向和程序长度两个方面，结构复杂性用不同模块之间的关联程度来表示。软件复杂度可用涉及到模块复杂性和结构复杂性的一些统计指标来进行定量描述，在这里就不进行详细叙述了。
               软件的复杂性与软件可靠性有着密切的关系，软件复杂性是产生软件缺陷的重要根源，有研究表明，当软件的复杂度超过一定界限时，软件缺陷数会急剧上升，软件的可靠性急剧下降。因此，在设计的时候就应考虑降低软件的复杂性，使之处于一个合理的阈值之内，这是提高软件可靠性的有效方法。
               降低复杂度设计的思想就是在保证实现软件功能的基础上，简化软件结构，缩短程序代码长度，优化软件数据流向，降低软件复杂度，从而提高软件可靠性。
               除了容错设计、检错设计和降低复杂度设计技术外，人们尝试着把硬件可靠性设计中比较成熟的技术，如故障树分析（FTA）、失效模式与效应分析（FMEA）等运用到软件可靠性设计领域，这些技术大多是运用一些分析、预测技术，在软件设计时就充分考虑影响软件可靠性的因素，并采取一些措施地进行优化。由于软件与硬件内部性质的巨大差异，这些技术在软件可靠性设计领域的应用效果和范围极其有限。
 
       软件设计
               软件设计的任务
               在给定系统的需求规格说明书后，需要对软件的结构进行设计，并对设计的过程进行管理。在嵌入式系统的软件设计过程中，需要完成以下一些任务。
                      准备工作计划
                      在软件设计之前，首先要制订详细的工作计划，其内容包括：
                      .过程管理方案：包括软件开发的进度管理、软件规模和所需人年的估算、开发人员的技能培训等；
                      .开发环境的准备方案：包括开发工具的准备、开发设备的准备、测试装备的准备、分布式开发环境下的开发准则等；
                      .软硬件联机调试的方案：联调的起始时间、地点、人员和具体的准备工作；
                      .质量保证方案：包括质量目标计划、质量控制计划等；
                      .配置控制方案：包括配置控制文档的编写、配置控制规则的制订等。
                      确定软件的结构
                      设计软件的各个组成部分，包括：
                      .任务结构的设计：使用操作系统提供的函数，设计出一个最佳的任务结构；
                      .线程的设计；
                      .公共数据结构的设计：在确保系统一致性的基础上，设计出所需的公共数据；
                      .操作系统资源的定义；
                      .类的设计；
                      .模块结构设计：在设计时要充分考虑模块的划分、标准化、可重用和灵活性等；
                      .内存的分配与布局。
                      设计评审
                      对于软件设计的结果，进行一次设计评审，并在必要时对设计进行修正。具体内容包括：
                      .确认每件工作的执行方法是否恰当，其内容是否完善；
                      .确认该设计完成了系统需求规格说明书所要求的功能和服务；
                      .评估任务结构设计、评估类的设计、评估模块结构设计；
                      .对软件设计的结果进行总结，编写出相应的文档。
                      维护工作计划
                      执行软件设计工作控制，在每日、每周和每月的时间粒度上对进度进行控制，确保软件设计能够如期完成。
                      与硬件部门密切合作、相互协调
                      根据工作计划中的安排，定期与硬件部门召开会议，协调各自的进展。如果软件规格说明书发生了变化，立即进行调整，重新进行软件设计。
                      控制工作的结果，把工作记录存档
                      掌握当前的工作进展情况，尽早地发现和分析问题，并采取相应的措施。对各种事件进行跟踪记录，包括：
                      .执行过程控制，跟踪进展情况并定期记录、存档。
                      .执行质量控制，保留质量记录。
                      .记录产品的配置、版本变化、bug的发现和处理等信息。
               软件架构设计
               软件架构也称为软件体系结构，需要考虑如何对系统进行分解，对分解后的组件及其之间的关系进行设计，满足系统的功能和非功能需求。软件架构形成过程如下图所示。
               
               架构的形成过程概要
               软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变，随后的架构设计需要通过一系列的迭代开发完善，使得软件架构日趋成熟、稳定。
               软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构，包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐，确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求，也具有可扩展、可移植性，从而为一个软件带来长久的生命力。
               在大量开发实践中，有很多广泛使用并被普遍接受的软件架构设计原则，这些原则独立于具体的软件开发方法，主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。
               （1）抽象：这是软件架构的核心原则，也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性，从具体的事务中通过封装来忽略细节，并且运用这些特征和属性，描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象，从而有多个不同层次架构。
               （2）信息隐藏：包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中，减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。
               （3）强内聚和松耦合：强内聚是指软件组件内的特性，即组件内所有处理都高度相关，所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性，软件组件之间应尽量做到没有或极少的直接关系，使其保持相对独立，这样使得未来的修改、复用简单，修改之后带来的影响最小。
               （4）关注点分离：所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件，需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分，使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单，那么就更容易理解和实现。但“展示某些关注点得到满足时，可能会影响到其他方面的关注点，但架构师必须能够说明所有关注点都已得到满足”。
               以上的原则中，删除需求细节或对细节进行抽象是最重要的工作，为用户的需求创建抽象模型，通过抽象将特殊问题映射为更普遍的问题类别，并识别各种模式。
               软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层，横向分解就是将每一个层面分成相对独立的部分。经过分解之后，可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装，功能独立、功能高度内聚、之间低耦合的一个组件。
               类似于建筑架构，软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性，好的软件架构也给人完整、明确、清晰等赏心悦目的感觉，具有较长的生命力。
               架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则，在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素，而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒，架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础，在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计，开发人员需要关注各子问题或要素的进一步分解和实现，是根据架构设计所定义的每个要素的功能、接口，进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下，考虑实现组件内部的细节及其实现方法。对于其中的公共子问题，形成公共类和工具类，从而可以达到重用的目的。
               一般的软件构架是根据需求自上而下方式来设计，即首先掌握和研究利益相关方的关键需求，基本思路是首先进行系统级的软件架构设计，需要将软件组件与其外部环境属性绑定在一起，关注软件系统与外部环境的交联设计；其次将一个大的系统划分成各组成部分，这些部分可以按照架构设计的不同方法，分为层次或成为模块；之后再开始研究所涉及到的要素，再实现这些要素以及定义这些要素之间的关系。
               在实际工作中，软件构架也可采用自底向上的方法，前提是已经建立了一个成熟稳定的软件架构，也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路，是为了解决共有问题解的方案模板，但并不是一个问题的设计或设计算法。
               模式常常整合在一起使用，提供解决更大、更复杂问题的解决方案，而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具，而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架，这时其他重要元素可以在这个架构基础上针对新的需求进行扩展，有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计，采用成熟的先进的设计框架和工具提高开发的效率，保证设计正确性。
               下图所示是针对架构设计中非功能需求的多维度分析，从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分，但超越了系统内部的算法和数据结构的详细设计。
               
               架构的多维度分析
               在架构设计阶段，需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。
               软件设计方法
               在将系统分解为各个组件的过程中，需要采取不同的策略，而每个策略则关注不同的设计概念。根据分解过程中所采用的不同策略，设计方法有基于功能分解的设计方法、基于信息隐藏的设计方法和基于模型驱动开发的设计方法等分类。
               （1）基于功能分解的设计方法。实时结构化分析与设计采用了功能分解，系统被分解为多个函数，并且以数据流或控制流的形式定义函数之间的接口；基于并发任务结构化的设计（Design Approach for Real-Time Systems，DARTS）提供了任务结构化标准，辅助人员确定系统中的并发任务，并指导定义任务接口。
               （2）基于信息隐藏的设计方法。面向对象（Object Oriented，OO）设计方法将数据和数据上操作封装在对象实体中，对象外界不能够直接对对象内部进行访问和操作，只能通过消息间接访问对象，符合人类思维方式，提高软件的扩展性、维护性和重用性。
               （3）基于模型驱动开发的设计方法。通过借助有效的（Model Driven Development，MDD）工具，构建和维护复杂系统的设计模型，直接产生高质量的代码，将开发的重心从编码转移到设计。当前使用较为广泛的MDD工具有IBM公司的Rhapsody。
 
       软件设计阶段
        从工程管理角度来看，软件设计可分为概要设计和详细设计两个阶段。
               概要设计
               概要设计也称为高层设计，即将软件需求转化为数据结构和软件的系统结构。例如，如果采用结构化设计，则从宏观的角度将软件划分成各个组成模块，并确定模块的功能及模块之间的调用关系。
               概要设计主要包括设计软件的结构、确定系统由哪些模块组成，以及每个模块之间的关系。它采用的是结构图（包括模块、调用和数据）来描述程序的结构，还可以使用层次图和HIPO（层次图加输入／处理／输出图）。整个过程主要包括复查基本系统模型、复查并精化数据流图、确定数据流图的信息流类型（包括交换流和事务流）、根据流类型分别实施变换分析或事务分析，以及根据软件设计原则对得到的软件结构图进一步进行优化。
               详细设计
               详细设计也称为低层设计，即对结构图进行细化，得到详细的数据结构与算法。同样，如果采用结构化设计，则详细设计的任务就是为每个模块进行设计。
               详细设计确定应该如何具体地实现所要求的系统，得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。经常使用的工具包括程序流程图、盒图、PAD图（问题分析图）及PDL（伪码）。
               总的来说，在整个软件设计过程中，需完成以下工作任务。
               （1）制定规范，作为设计的共同标准。
               （2）完成软件系统结构的总体设计，将复杂系统按功能划分为模块的层次结构，然后确定模块的功能，以及模块间的调用关系和组成关系。
               （3）设计处理方式，包括算法、性能、周转时间、响应时间、吞吐量和精度等。
               （4）设计数据结构。
               （5）可靠性设计。
               （6）编写设计文档，包括概要设计说明书、详细设计说明书、数据库设计说明书、用户手册和初步的测试计划等。
               （7）设计评审，主要是对设计文档进行评审。
               在设计阶段，必须根据要解决的问题做出设计的选择。例如，半结构化决策问题就适合由交互式计算机软件来解决。
 
       设计阶段
        设计阶段监理进行质量控制的要点如下。
        （1）了解建设单位的建设需求和对信息系统安全性的要求，协助建设单位制定项目质量目标规划和安全目标规划。
        （2）对各种设计文件提出设计质量标准。
        （3）进行设计过程跟踪，及时发现质量问题，并及时与承建单位协调解决。审查阶段性成果，并提出监理意见。审查承建单位提交的总体设计方案，审查承建单位对关键部位的测试方案。
        （4）协助承建单位建立质量保障体系。
        （5）协助承建单位完善现场质量管理制度。
        （6）组织设计文件及设计方案交底会，制定质量要求标准。
 
       预测
        随着项目进展，项目团队可根据项目绩效，对完工估算（EAC）进行预测，预测的结果可能与完工预算（BAC）存在差异。如果BAC已明显不再可行，则项目经理应考虑对EAC进行预测。预测EAC是根据当前掌握的绩效信息和其他知识，预计项目未来的情况和事件。预测要根据项目执行过程中所提供的工作绩效数据来产生、更新和重新发布。工作绩效信息包含项目过去的绩效，以及可能在未来对项目产生影响的任何信息。
        有关预测的相关计算会在15.4节中详细说明。
   题号导航      2009年下半年 系统架构设计师 下午试卷 论文   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第4题    在手机中做本题