第3章 软件设计基础

1、13.1 软件设计的基本概念软件设计的基本概念软件设计主要针对软件设计主要针对需求分析需求分析过程得到的软过程得到的软件需求规格说明，综合考虑各种制约因素件需求规格说明，综合考虑各种制约因素，探求切实可行的软件解决方案并最终给，探求切实可行的软件解决方案并最终给出方案的逻辑表示，包括文档、模型等。出方案的逻辑表示，包括文档、模型等。软件设计受到资源和技术两方面的制约。软件设计受到资源和技术两方面的制约。软件设计基本概念是过去数十年里陆续提软件设计基本概念是过去数十年里陆续提出的，软件设计者根据这组概念进行设计出的，软件设计者根据这组概念进行设计决策。决策。软件设计的最终目标是获得满足软件需求软

2、件设计的最终目标是获得满足软件需求的、明确的、可行的、高质量的软件解决的、明确的、可行的、高质量的软件解决方案。方案。 3.1 软件设计的基本概念软件设计的基本概念 抽象与逐步求精抽象与逐步求精模块数量与成本模块数量与成本内聚与耦合及量化指标内聚与耦合及量化指标模块化与信息隐藏模块化与信息隐藏（1）抽象与逐步求精）抽象与逐步求精“抽象抽象”是一个心理学概念，它要求人们将是一个心理学概念，它要求人们将注意力集中在某一层次上考虑问题，而忽注意力集中在某一层次上考虑问题，而忽略那些低层次的细节。是管理、控制复杂略那些低层次的细节。是管理、控制复杂性的基本策略。性的基本策略。软件设计过程是在不同抽象级

3、别考虑、处软件设计过程是在不同抽象级别考虑、处理问题的过程。最初应该在最高抽象级别理问题的过程。最初应该在最高抽象级别上，用面向问题域的语言概述问题，包括上，用面向问题域的语言概述问题，包括问题解的形式，然后不断具体化，不断用问题解的形式，然后不断具体化，不断用接近计算机域的语言描述问题，最后，在接近计算机域的语言描述问题，最后，在最低的抽象级别上给出可直接实现的问题最低的抽象级别上给出可直接实现的问题解，即程序。解，即程序。把原本未知解的问题描述成如何解的过程，最终得到解。把原本未知解的问题描述成如何解的过程，最终得到解。（1）抽象与逐步求精）抽象与逐步求精软件设计过程的每一步都是对较高的、

4、抽软件设计过程的每一步都是对较高的、抽象的解作一次更具体化的描述。象的解作一次更具体化的描述。过程抽象过程抽象：把完成特定功能的动作序列抽象：把完成特定功能的动作序列抽象为一个过程名和参数表，以后通过指定过程为一个过程名和参数表，以后通过指定过程名和实际参数调用此过程。名和实际参数调用此过程。（方法、函数）（方法、函数）数据抽象：数据抽象：把一个数据对象的定义（或描述把一个数据对象的定义（或描述）抽象为一个数据类型名，用此类型名可定）抽象为一个数据类型名，用此类型名可定义多个具有相同性质的数据对象。义多个具有相同性质的数据对象。（系统以（系统以及自定义的数据类型、数据结构、类）及自定义的数据类

5、型、数据结构、类）（1）抽象与逐步求精）抽象与逐步求精“逐步求精逐步求精” 可视为一种早期的自顶向下设可视为一种早期的自顶向下设计策略，其主要思想是，针对某个功能的计策略，其主要思想是，针对某个功能的宏观描述用逐步求精的方法不断地分解，宏观描述用逐步求精的方法不断地分解，逐步确立过程细节，直至该功能用程序语逐步确立过程细节，直至该功能用程序语言描述的算法实现为止。言描述的算法实现为止。 在软件设计过程中，抽象与逐步求精是一在软件设计过程中，抽象与逐步求精是一般都是结合起来进行应用。般都是结合起来进行应用。系统的层次结构的上一层是下一层的抽象系统的层次结构的上一层是下一层的抽象，下一层是上一层的

6、求精。，下一层是上一层的求精。 抽象与逐步求精抽象与逐步求精（2）模块化与信息隐藏）模块化与信息隐藏软件体系结构体现了模块化思想，即把软件划软件体系结构体现了模块化思想，即把软件划分为可独立命名和访问的部件，每个部件称为分为可独立命名和访问的部件，每个部件称为一个模块，当把所有模块组装到一起时则获得一个模块，当把所有模块组装到一起时则获得满足问题需要的解。满足问题需要的解。模块化使得开发活动更加简单的一个重要因素模块化使得开发活动更加简单的一个重要因素是模块的信息隐藏，即一个模块的开发者不必是模块的信息隐藏，即一个模块的开发者不必看到其它模块的内部，只需知道其接口即可，看到其它模块的内部，只需

7、知道其接口即可，这使得每个模块的开发人员所要处理的复杂性这使得每个模块的开发人员所要处理的复杂性显著降低。显著降低。 信息隐藏指导的模块化设计不仅支持模块的并信息隐藏指导的模块化设计不仅支持模块的并行开发，而且还可以减少测试和维护的工作量行开发，而且还可以减少测试和维护的工作量。（2）模块化与信息隐藏）模块化与信息隐藏问题求解的研究表明，把两个问题组合起问题求解的研究表明，把两个问题组合起来进行求解的复杂性，一般要比分别对两来进行求解的复杂性，一般要比分别对两个问题进行求解的复杂度之和更大，这个个问题进行求解的复杂度之和更大，这个结论导致结论导致“分治法分治法”的出现，即把一个复杂的出现，即把

8、一个复杂问题分割成若干个可管理的、更易于求解问题分割成若干个可管理的、更易于求解的小问题。的小问题。但这种分割并不意味着但这种分割并不意味着“无限无限”分割，当模分割，当模块数量增加时，模块接口所需要的代价也块数量增加时，模块接口所需要的代价也随之增加。随之增加。模块数量与成本模块数量与成本（2）模块化与信息隐藏）模块化与信息隐藏恰当的定义模块范围和大小非常重要，这恰当的定义模块范围和大小非常重要，这与采用的设计方法密切相关，评价所采用与采用的设计方法密切相关，评价所采用设计方法的标准：设计方法的标准：模块可分解性模块可分解性模块的组装性模块的组装性模块的可理解性模块的可理解性模块连续性模块连

9、续性模块保护模块保护内聚与耦合内聚与耦合每个模块应相对独立，其功能相对单一，每个模块应相对独立，其功能相对单一，而模块之间的接口应尽可能简单。而模块之间的接口应尽可能简单。内聚内聚是前述信息隐藏和局部化概念的自然扩是前述信息隐藏和局部化概念的自然扩展，它标志一个模块展，它标志一个模块内部内部各成分彼此结合的各成分彼此结合的紧密程度紧密程度。 耦合耦合是对软件结构中模块间关联程度的一种是对软件结构中模块间关联程度的一种度量。耦合的强弱取决于度量。耦合的强弱取决于模块间模块间接口的复杂接口的复杂性、进入或调用模块的位置以及通过接口传性、进入或调用模块的位置以及通过接口传送数据的多少等。送数据的多少

10、等。 追求追求高内聚、低耦合高内聚、低耦合。（1）抽象与逐步求精）抽象与逐步求精内聚内聚内聚按其高低程度可划分为不同等级，内内聚按其高低程度可划分为不同等级，内聚度越高越好，从而获得较高的模块独立聚度越高越好，从而获得较高的模块独立性。性。低等级内聚：低等级内聚： 偶然性内聚偶然性内聚 逻辑性内聚逻辑性内聚 时序内聚时序内聚中等级内聚：中等级内聚： 过程性内聚过程性内聚 通信性内聚通信性内聚高级内聚：高级内聚： 顺序性内聚顺序性内聚 功能性内聚：最高程度的内聚功能性内聚：最高程度的内聚耦合耦合耦合的强弱取决于模块间接口的复杂性、耦合的强弱取决于模块间接口的复杂性、进入或调用模块的位置、通过接口

11、传输数进入或调用模块的位置、通过接口传输数据量等。据量等。模块间的耦合程度直接影响着系统的可理模块间的耦合程度直接影响着系统的可理解性、可测试性、可靠性和可维护性，软解性、可测试性、可靠性和可维护性，软件设计应追求尽可能松散的耦合，模块间件设计应追求尽可能松散的耦合，模块间的联系越少，错误在模块间传递的可能性的联系越少，错误在模块间传递的可能性就越小。就越小。耦合耦合耦合等级的划分耦合等级的划分低等级耦合：低等级耦合： 非直接耦合非直接耦合中等级耦合中等级耦合 数据耦合数据耦合 特征耦合特征耦合 控制耦合控制耦合 外部耦合外部耦合 公共耦合公共耦合高等级耦合：高等级耦合： 内容耦合内容耦合尽量

12、使用数据耦合，减少控制耦合，限制尽量使用数据耦合，减少控制耦合，限制外部耦合和公共耦合，杜绝内容耦合。外部耦合和公共耦合，杜绝内容耦合。传递的信息含有控制信息内聚和耦合的量化指标内聚和耦合的量化指标类耦合度类耦合度类的耦合度为与它耦合的其它类的数目，包括调类的耦合度为与它耦合的其它类的数目，包括调用其他类的方法、使用其它类的实例变量。一个用其他类的方法、使用其它类的实例变量。一个类越独立，它在应用中就越容易被重用，类之间类越独立，它在应用中就越容易被重用，类之间的耦合度应尽可能的小。的耦合度应尽可能的小。方法内聚缺乏程度方法内聚缺乏程度“不访问相同成员变量的方法对数目不访问相同成员变量的方法对

13、数目”减去减去“访问访问相同成员变量的方法对数目相同成员变量的方法对数目”如果一个类中没有任何两个方法对同一变量进行如果一个类中没有任何两个方法对同一变量进行访问，则它们没有相似性，该类的内聚程度将会访问，则它们没有相似性，该类的内聚程度将会很低，缺乏内聚度意味着该类可以分为两个或更很低，缺乏内聚度意味着该类可以分为两个或更多的类。多的类。（1）软件设计的一般过程）软件设计的一般过程软件设计可能是一个多次反复的过程，所软件设计可能是一个多次反复的过程，所以，软件设计一般都可以被看作是迭代的以，软件设计一般都可以被看作是迭代的过程。过程。 迭代有两层含义（如下页图）迭代有两层含义（如下页图）软件

14、设计的迭代软件设计的迭代迭代的两层含义：迭代的两层含义：第一层含义是，针对给定的需求模型，通过多次第一层含义是，针对给定的需求模型，通过多次从抽象到具体的设计过程，得出足够精细的设计模从抽象到具体的设计过程，得出足够精细的设计模型以供软件实现之用。型以供软件实现之用。第二层含义是，在需求模型发生变化并更新完成第二层含义是，在需求模型发生变化并更新完成后，第一层含义的设计过程再随之展开，直至获得后，第一层含义的设计过程再随之展开，直至获得最终的目标软件产品最终的目标软件产品 。软件设计的一般过程软件设计的一般过程软件设计过程包括在不同抽象层次上开发系软件设计过程包括在不同抽象层次上开发系统的多个

15、模型。统的多个模型。软件设计可以看作是将软件设计可以看作是将需求规格说明需求规格说明转换为转换为可直接提供软件代码实现使用的可直接提供软件代码实现使用的设计规格说设计规格说明。明。工程管理的角度：工程管理的角度：概要设计：根据需求确定软件和数据总体框架。概要设计：根据需求确定软件和数据总体框架。详细设计：进一步精化成软件的算法表示和数据详细设计：进一步精化成软件的算法表示和数据结构。结构。技术上，概要设计和详细设计由若干活动组成，技术上，概要设计和详细设计由若干活动组成，包括软件体系结构设计、界面设计、模块包括软件体系结构设计、界面设计、模块/子系统子系统设计、数据模型设计、过程设计、数据模型

16、设计、过程/算法设计。算法设计。软件设计的一般过程软件设计的一般过程1）软件设计计划）软件设计计划在设计过程中，对设计活动进行计划应该最在设计过程中，对设计活动进行计划应该最早进行，然后按照计划实施体系结构设计、早进行，然后按照计划实施体系结构设计、界面设计、模块界面设计、模块/子系统设计、数据模型设计子系统设计、数据模型设计、过程、过程/算法设计等活动。算法设计等活动。 软件设计计划的任务是：明确设计过程的输软件设计计划的任务是：明确设计过程的输入制品并使其处于就绪状态，定义设计过程入制品并使其处于就绪状态，定义设计过程的目标、输出制品及其验收准则，确定覆盖的目标、输出制品及其验收准则，确定

17、覆盖设计过程中各个阶段的全局性设计策略，分设计过程中各个阶段的全局性设计策略，分配设计过程相关人员的职责，针对设计过程配设计过程相关人员的职责，针对设计过程中的活动制订工作计划。中的活动制订工作计划。 1）软件设计计划）软件设计计划软件设计计划的步骤：软件设计计划的步骤：确定设计的目标和验收标准确定设计的目标和验收标准明确目标软件系统应遵循的技术标准或规范明确目标软件系统应遵循的技术标准或规范重新审视项目风险管理计划重新审视项目风险管理计划制定本次设计过程的工作计划制定本次设计过程的工作计划对设计过程的工作计划进行评审对设计过程的工作计划进行评审2）体系结构设计）体系结构设计软件体系结构设计的

18、目标是建立软件系统软件体系结构设计的目标是建立软件系统的体系结构，有时也称的体系结构，有时也称“顶层架构顶层架构”。这种架构既要明确定义软件各子系统、关这种架构既要明确定义软件各子系统、关键构件、关键类的职责划分及协作关系，键构件、关键类的职责划分及协作关系，同时也要描绘它们在物理运行环境下的部同时也要描绘它们在物理运行环境下的部署模型。署模型。顶层架构还必须针对软件系统全局性、基顶层架构还必须针对软件系统全局性、基础性的技术问题给出技术解决方案，这种础性的技术问题给出技术解决方案，这种方案往往构成目标软件系统的体系结构的方案往往构成目标软件系统的体系结构的技术基础设施。技术基础设施。 2）体

19、系结构设计）体系结构设计评价软件体系结构评价软件体系结构宽度和深度：软件控制的层数和跨度宽度和深度：软件控制的层数和跨度扇出率和扇入率：扇出率和扇入率： 扇出率：一个模块的扇出率指该模块直接扇出率：一个模块的扇出率指该模块直接控制控制的的 其他其他模块数。模块数。 扇入率：一个模块的扇入率指直接扇入率：一个模块的扇入率指直接控制该模块控制该模块的的 模块数模块数。可见性和联通性可见性和联通性 模块的可见性：该模块可直接或间接引用的一组模块。模块的可见性：该模块可直接或间接引用的一组模块。 模块的联通性：模块可直接引用的一组模块。模块的联通性：模块可直接引用的一组模块。软件体系结构设计有关概念软

20、件体系结构设计有关概念3）界面设计）界面设计用户界面设计的目标是，为用户使用目标软件用户界面设计的目标是，为用户使用目标软件系统以实现其所有业务需求而提供友好的人机系统以实现其所有业务需求而提供友好的人机交互界面。交互界面。 软件界面设计需要考虑以下因素软件界面设计需要考虑以下因素 ：适用于软件功能适用于软件功能 易理解性易理解性 一致性一致性 灵敏性灵敏性 容错性容错性 人性化人性化 国际化国际化 个性化个性化 合理的布局合理的布局 和谐的色彩和谐的色彩 界面的易用性界面的美观性4）模块）模块/子系统设计子系统设计子系统和模块的区别：子系统和模块的区别：一个子系统独立构成系统，不依赖其它子系

21、统提一个子系统独立构成系统，不依赖其它子系统提供的服务。供的服务。 一个模块通常是一个能提供一个或多个服务的系一个模块通常是一个能提供一个或多个服务的系统部件。它能利用其它模块提供的服务，一般不统部件。它能利用其它模块提供的服务，一般不被看成一个独立的系统。被看成一个独立的系统。 由于模块和子系统都是软件组成部分，它们由于模块和子系统都是软件组成部分，它们一般都有层次结构，相互之间存在接口，其一般都有层次结构，相互之间存在接口，其设计方法有很多类似的方面，因此我们统一设计方法有很多类似的方面，因此我们统一称为模块设计。称为模块设计。 模块设计的目标模块设计的目标模块设计的目标是，确定模块设计的

22、目标是，确定模块的具体接口模块的具体接口定义定义，并设计模块的内部结构，即，设置，并设计模块的内部结构，即，设置包含于其中的（更小粒度的）模块、构件包含于其中的（更小粒度的）模块、构件和设计类，和设计类，明确它们之间的明确它们之间的协作关系协作关系，确保它们能够，确保它们能够协同实现高层模块接口规定的所有功能和协同实现高层模块接口规定的所有功能和行为。行为。在进行模块设计时，要尽量保持模块的功在进行模块设计时，要尽量保持模块的功能独立性，遵循能独立性，遵循“高内聚、低耦合高内聚、低耦合”的设计的设计思想。思想。此外，还要力求将模块的影响限制在模块此外，还要力求将模块的影响限制在模块的控制范围内

23、，使得以后软件的修改和维的控制范围内，使得以后软件的修改和维护工作更加简单。护工作更加简单。 5）过程）过程/算法设计算法设计过程过程/算法设计的任务就是对模块内部的工算法设计的任务就是对模块内部的工作和执行过程进行描述，给出有关处理的作和执行过程进行描述，给出有关处理的精确说明，例如事件的顺序、确切的决策精确说明，例如事件的顺序、确切的决策位置、循环操作以及数据的组成等。位置、循环操作以及数据的组成等。 软件结构与软件过程相互关联，软件结构软件结构与软件过程相互关联，软件结构中任何模块的所有从属模块必将被引用出中任何模块的所有从属模块必将被引用出现在该模块的过程说明中。因此，软件过现在该模块

24、的过程说明中。因此，软件过程对应的结构设计亦构成一个层次结构。程对应的结构设计亦构成一个层次结构。 可以使用可以使用UML对模块进行设计对模块进行设计使用使用UML的模块过程设计的模块过程设计6）数据模型设计）数据模型设计我们把数据结构设计、数据库设计、甚至我们把数据结构设计、数据库设计、甚至数据文件设计等统一称为数据模型设计。数据文件设计等统一称为数据模型设计。 在数据模型设计中有一个重要概念：持久在数据模型设计中有一个重要概念：持久数据操作，它包括写入、查询、更新和删数据操作，它包括写入、查询、更新和删除四类基本操作以及由它们复合而成的业除四类基本操作以及由它们复合而成的业务数据操作。务数

25、据操作。 在很多软件系统中，数据是其核心，因此在很多软件系统中，数据是其核心，因此，对数据元素的格式、结构、访存、表示，对数据元素的格式、结构、访存、表示等机制进行良好建模和优化，是提高软件等机制进行良好建模和优化，是提高软件设计质量和系统性能的基础，对软件系统设计质量和系统性能的基础，对软件系统的应用具有重要意义。的应用具有重要意义。 软件设计的一般过程软件设计的一般过程软件设计质量的重要性软件设计质量的重要性软件设计是软件开发过程中的核心活动，软软件设计是软件开发过程中的核心活动，软件设计的质量不但对最终软件产品的质量起件设计的质量不但对最终软件产品的质量起着决定性作用，还对软件开发过程以

26、及软件着决定性作用，还对软件开发过程以及软件以后在使用过程中维护的难易程度有着重要以后在使用过程中维护的难易程度有着重要的影响。的影响。高质量的软件设计，能够有效缩短软件开发高质量的软件设计，能够有效缩短软件开发时间，减少开发成本，提高最终软件产品质时间，减少开发成本，提高最终软件产品质量。量。 软件设计的质量要素软件设计的质量要素评价软件设计的质量评价软件设计的质量结构良好结构良好充分性充分性可行性可行性简单性简单性实用性实用性灵活性灵活性健壮性健壮性可移植性可移植性可复用性可复用性标准化标准化软件设计的质量软件设计的质量软件设计对最终软件产品质量产生的影响软件设计对最终软件产品质量产生的影

27、响包括：包括：正确性正确性可靠性可靠性运行效率运行效率可移植性可移植性可维护性可维护性可复用性可复用性软件设计的质量软件设计的质量软件设计对软件开发过程可能产生的影响软件设计对软件开发过程可能产生的影响包括：包括：开发效率开发效率交付时间交付时间风险管理风险管理资源使用资源使用成本成本人员培训人员培训合法性合法性（1）软件体系结构设计方法概述）软件体系结构设计方法概述软件体系结构的设计方法是指通过一系列软件体系结构的设计方法是指通过一系列的设计活动，获得满足系统功能性需求、的设计活动，获得满足系统功能性需求、并且符合一定非功能性需求约束的软件体并且符合一定非功能性需求约束的软件体系结构模型。系

28、结构模型。目前存在多种体系结构设计方法，它们的目前存在多种体系结构设计方法，它们的侧重点有所不同侧重点有所不同(功能、非功能、复用功能、非功能、复用)。 在实际应用过程中，这些体系结构设计方在实际应用过程中，这些体系结构设计方法并不是绝对互斥的，根据需要，有可能法并不是绝对互斥的，根据需要，有可能综合运用不同体系结构设计方法的思想，综合运用不同体系结构设计方法的思想，得到最终所需的设计结果。得到最终所需的设计结果。 软件体系结构设计方法软件体系结构设计方法4+1多视图建模多视图建模基于评估与转换的设计方法基于评估与转换的设计方法模式驱动的设计方法模式驱动的设计方法领域特定的软件体系结构设计领域

29、特定的软件体系结构设计 复用复用软件产品线方法软件产品线方法其它软件体系结构设计方法其它软件体系结构设计方法1） 多视图建模多视图建模1） 多视图建模多视图建模逻辑视图：功能需求、与应用领域密切相关、领域术语、逻辑视图：功能需求、与应用领域密切相关、领域术语、系统功能映射到概念构件和连接件、与硬件和软件细节无系统功能映射到概念构件和连接件、与硬件和软件细节无关。关。进程视图：非功能需求、设计中关于并发和同步的内容。进程视图：非功能需求、设计中关于并发和同步的内容。开发视图：软件在开发环境中的静态结构、构件和连接子开发视图：软件在开发环境中的静态结构、构件和连接子映射到子系统或模块、关注软件模块

30、的组织。映射到子系统或模块、关注软件模块的组织。物理视图：描述软件到硬件的映射关系、关注物理环境的物理视图：描述软件到硬件的映射关系、关注物理环境的拓扑结构以及节点间的通信。拓扑结构以及节点间的通信。场景：把上述四种视图联系起来，场景（用例的实例）通场景：把上述四种视图联系起来，场景（用例的实例）通常是最重要的需求。常是最重要的需求。 以上视图均可用以上视图均可用UML进行建模。进行建模。2）基于评估与转换的设计）基于评估与转换的设计方法方法针对功能特性设计体系结构，对设计结果针对功能特性设计体系结构，对设计结果进行评审，如果不满足要求则进行改进，进行评审，如果不满足要求则进行改进，一直迭代到

31、满足要求为止。一直迭代到满足要求为止。对设计出的体系结构的质量进行评估、不对设计出的体系结构的质量进行评估、不满足要求时的体现结构转换特别重要。满足要求时的体现结构转换特别重要。2）基于评估与转换的设计）基于评估与转换的设计方法方法体系结构的评估体系结构的评估基于场景的评估基于场景的评估仿真仿真数学建模数学建模基于经验的推理基于经验的推理体系结构设计转换方式体系结构设计转换方式质量评价结果不满足需求规格说明，需要质量评价结果不满足需求规格说明，需要改变评估环境（修改评估）或修改体系结改变评估环境（修改评估）或修改体系结构设计，有以下三种体系结构转化方式：构设计，有以下三种体系结构转化方式：使用

32、合适的体系结构风格和模式，或者设计模使用合适的体系结构风格和模式，或者设计模式来改进体系结构设计。式来改进体系结构设计。把非功能需求转化为功能性解决方案，该功能把非功能需求转化为功能性解决方案，该功能性方案可以与问题域无关，但可以满足质量属性方案可以与问题域无关，但可以满足质量属性的要求。性的要求。采用采用“分而治之分而治之”的方式，可以把系统级的质的方式，可以把系统级的质量需求分配到子系统或模块中，或者把质量需量需求分配到子系统或模块中，或者把质量需求分解为多个与功能相关的质量需求，分解后求分解为多个与功能相关的质量需求，分解后的质量需求能够比较容易得到满足。的质量需求能够比较容易得到满足。

33、软件设计经验的总结和复用软件设计经验的总结和复用模式驱动的设计方法模式驱动的设计方法领域特定的软件体系结构设计领域特定的软件体系结构设计软件产品线方法软件产品线方法体系结构风格体系结构风格/模式模式体系结构风格是描述某一特定应用方式中体系结构风格是描述某一特定应用方式中系统组织方式的惯用模式，为设计人员提系统组织方式的惯用模式，为设计人员提供公共的模型、符号和术语表示，促进设供公共的模型、符号和术语表示，促进设计复用甚至代码复用计复用甚至代码复用体系结构模式是对设计模式的扩展，描述体系结构模式是对设计模式的扩展，描述了软件系统基本的结构化组织方案，是具了软件系统基本的结构化组织方案，是具体体系

34、结构的模板。体体系结构的模板。体系结构风格描述了软件总体框架的结构体系结构风格描述了软件总体框架的结构，综合考虑整个系统各方面的需求。，综合考虑整个系统各方面的需求。设计模式是针对单一的问题提供解决方案设计模式是针对单一的问题提供解决方案，层次比软件体系结构风格低。，层次比软件体系结构风格低。3）模式驱动的设计方法）模式驱动的设计方法体系结构风格的分类体系结构风格的分类体系结构风格分类体系结构风格分类独立构件体系结构独立构件体系结构数据流体系结构数据流体系结构数据为中心的体系结构数据为中心的体系结构虚拟机体系结构虚拟机体系结构调用与返回体系结构调用与返回体系结构4）领域特定的软件体系结构设计）

35、领域特定的软件体系结构设计领域特定的软件体系结构（领域特定的软件体系结构（Domain Specific Software Architecture，DSSA）是领域工程的核心部分，领域工程分析）是领域工程的核心部分，领域工程分析应用领域的共同特征和可变特征，对刻画应用领域的共同特征和可变特征，对刻画这些特征的对象和操作进行选择和抽象，这些特征的对象和操作进行选择和抽象，形成领域模型，并进一步生成形成领域模型，并进一步生成DSSA。领域特定的软件体系结构借鉴领域中已经领域特定的软件体系结构借鉴领域中已经成熟的软件体系结构，实现解决方案在某成熟的软件体系结构，实现解决方案在某个领域内的复用。虽然

36、这些系统实例的细个领域内的复用。虽然这些系统实例的细节会有不同，但共同的体系结构在开发新节会有不同，但共同的体系结构在开发新系统时是能够复用的。系统时是能够复用的。 DSSA与体系结构风格的区与体系结构风格的区别别DSSA与软件体系结构风格是从不同角度出与软件体系结构风格是从不同角度出发研究问题的两种结果，前者从问题域出发发研究问题的两种结果，前者从问题域出发，而后者从解决域出发。，而后者从解决域出发。DSSA只在某个特定领域中进行经验知识的只在某个特定领域中进行经验知识的提取、总结与组织，但可以同时使用多种软提取、总结与组织，但可以同时使用多种软件体系结构风格；而一种软件体系结构风格件体系结

37、构风格；而一种软件体系结构风格所呈现的公共结构和设计方法可以扩展到多所呈现的公共结构和设计方法可以扩展到多个应用领域。个应用领域。DSSA的体系结构表示和工具一般只适用于的体系结构表示和工具一般只适用于一个较小的范围，在其它领域中是不适用并一个较小的范围，在其它领域中是不适用并难以复用的。难以复用的。领域特定的软件体系结构类领域特定的软件体系结构类型型类模型：类模型是从许多实际系统中抽象类模型：类模型是从许多实际系统中抽象出来的一般模型，它们封装这些系统的主出来的一般模型，它们封装这些系统的主要特征。如：编译器模型，大量的编译器要特征。如：编译器模型，大量的编译器几乎都基于同一种体系结构。几乎

38、都基于同一种体系结构。参考模型：参考模型是更抽象且是描述一参考模型：参考模型是更抽象且是描述一大类系统的模型，它对设计者是有关某类大类系统的模型，它对设计者是有关某类系统的一般结构的指导，通常源自于对某系统的一般结构的指导，通常源自于对某应用领域的研究。它代表了一个理想化的应用领域的研究。它代表了一个理想化的体系结构，包含了系统所有应该具有的特体系结构，包含了系统所有应该具有的特征。如：征。如：OSI七层参考模型。七层参考模型。5）软件产品线方法）软件产品线方法软件复用的更高阶段，已经超出软件体系结构设计方法软件复用的更高阶段，已经超出软件体系结构设计方法的范畴。的范畴。软件产品线指一组具有公

39、共的、可管理特征（系统需求软件产品线指一组具有公共的、可管理特征（系统需求）的软件系统，这些系统满足特定的市场需求或者任务）的软件系统，这些系统满足特定的市场需求或者任务领域需求，并且按照预定义的方式基于公共的核心资产领域需求，并且按照预定义的方式基于公共的核心资产（Core Assets）集合开发得到。）集合开发得到。 软件产品线主要由两部分组成：软件产品线主要由两部分组成：核心资产库：产品线的基础，是领域工程所有成果的核心资产库：产品线的基础，是领域工程所有成果的集合，管理支持产品开发的可复用资源。产品线体系集合，管理支持产品开发的可复用资源。产品线体系结构和构件是核心资产库中用于产品构建

40、的最重要部结构和构件是核心资产库中用于产品构建的最重要部分。分。产品集合产品集合软件产品线过程模型软件产品线过程模型三个基本活动三个基本活动产品线方法的基本活动产品线方法的基本活动核心资产开发：如何获得核心资产，可以核心资产开发：如何获得核心资产，可以自己构建、直接购买、委托加工等方式。自己构建、直接购买、委托加工等方式。产品开发：是产品线的目标，核心资产开产品开发：是产品线的目标，核心资产开发只是达到该目标的一种手段。发只是达到该目标的一种手段。管理：为各个活动合理分配资源、协调监管理：为各个活动合理分配资源、协调监督、设置恰当的组织机构等。督、设置恰当的组织机构等。循环重复是产品线开发过程

41、、核心资产开发循环重复是产品线开发过程、核心资产开发、产品、产品开发以及对其进行管理的特征。核心资产开开发以及对其进行管理的特征。核心资产开发和产发和产品开发没有先后顺序，管理活动协调整个产品开发没有先后顺序，管理活动协调整个产品线开品线开发过程的各个活动。发过程的各个活动。产品线方法产品线方法_新产品形成步新产品形成步骤骤从公共资产库中选取合适的构件；从公共资产库中选取合适的构件；使用预定义的变化机制进行裁剪，如参数使用预定义的变化机制进行裁剪，如参数化、继承等；化、继承等；必要时增加新的构件；必要时增加新的构件；在整个产品线范围内共同的体系结构指导在整个产品线范围内共同的体系结构指导下，进

42、行构件组装，形成系统。下，进行构件组装，形成系统。新产品的开发从新产品的开发从“创造创造”变成变成“组装组装”，占支配，占支配地位的活动是地位的活动是“集成集成”而非而非“编程编程”。软件产品。软件产品线是对特定领域的软件开发更加全面的复用，包线是对特定领域的软件开发更加全面的复用，包括领域特定的软件体系结构设计方法。（到商店括领域特定的软件体系结构设计方法。（到商店里买，去仓库里拿，而不是自己慢慢烹饪）里买，去仓库里拿，而不是自己慢慢烹饪）6）其它软件体系结构设计）其它软件体系结构设计方法方法基于目标图推理的体系结构设计方法基于目标图推理的体系结构设计方法 基于属性的体系结构设计方法基于属性

43、的体系结构设计方法 一些常用的软件开发方法学中也包含了软一些常用的软件开发方法学中也包含了软件体系结构的设计，例如：件体系结构的设计，例如：面向数据流的软件开发方法面向数据流的软件开发方法面向对象的软件开发方法面向对象的软件开发方法面向方面的软件开发方法面向方面的软件开发方法 软件体系结构设计步骤软件体系结构设计步骤始于体系结构设计，自顶向下、逐步精化始于体系结构设计，自顶向下、逐步精化。体系结构设计是在需求规格说明、软件设体系结构设计是在需求规格说明、软件设计计划已经完成后开始的。计计划已经完成后开始的。软件体系机构设计步骤图软件体系机构设计步骤图（2）软件体系结构设计步）软件体系结构设计步

44、骤骤开发软件顶层架构开发软件顶层架构 搜索并选取可用设计资产搜索并选取可用设计资产 设计技术支撑方案设计技术支撑方案 确定设计元素确定设计元素 开发软件部署模型开发软件部署模型 设计并发机制设计并发机制 构建软件体系结构模型构建软件体系结构模型 评审软件体系结构模型评审软件体系结构模型 （1）可信软件的特点）可信软件的特点计算机系统的缺陷很大一部分是由于软件计算机系统的缺陷很大一部分是由于软件的问题引发的。纵观软件应用的发展历史的问题引发的。纵观软件应用的发展历史，国际上由于软件可信性问题所导致的重，国际上由于软件可信性问题所导致的重大灾难、事故和严重损失屡见不鲜，软件大灾难、事故和严重损失屡

45、见不鲜，软件的可信性问题已经成为一个相当普遍的问的可信性问题已经成为一个相当普遍的问题。题。 所谓所谓“可信软件可信软件”，是指软件系统的运行行，是指软件系统的运行行为及其结果总是符合人们的预期，且在受为及其结果总是符合人们的预期，且在受到干扰（包括操作错误、环境影响、外部到干扰（包括操作错误、环境影响、外部攻击等）时仍能提供连续的服务。攻击等）时仍能提供连续的服务。 可信属性可信属性可靠性（可靠性（Reliability）：在规定的环境下和规定的时间内）：在规定的环境下和规定的时间内，软件无失效运行的概率；，软件无失效运行的概率；可靠安全性（可靠安全性（Safety）：软件运行不引起危险、灾

46、难的能）：软件运行不引起危险、灾难的能力；力；保密安全性（保密安全性（Security）：软件系统对数据和信息提供保）：软件系统对数据和信息提供保密性、完整性、可用性、真实性保障的能力；密性、完整性、可用性、真实性保障的能力；可生存性（可生存性（Survivability）：软件在受到攻击或失效出现）：软件在受到攻击或失效出现时连续提供服务并在规定时间内恢复所有服务的能力；时连续提供服务并在规定时间内恢复所有服务的能力；实时性（实时性（Real Time）：软件在指定的时间内完成反应或）：软件在指定的时间内完成反应或提交输出的能力。提交输出的能力。成本可信曲线成本可信曲线由于需要附加的设计、实

47、现和验证开销，提高可信行性将极大的增加开发成本指数曲线指数曲线（2）容错设计）容错设计为了保证高可信系统即使在极端条件下也为了保证高可信系统即使在极端条件下也能按其规格说明执行，对硬件和软件同时能按其规格说明执行，对硬件和软件同时采用容错计算非常重要。采用容错计算非常重要。硬件容错对所有关键硬件部件进行备份。硬件容错对所有关键硬件部件进行备份。 为了保护软件免受软件故障的影响，软件为了保护软件免受软件故障的影响，软件逻辑和数据也必须被备份。逻辑和数据也必须被备份。 软件容错设计是使得软件能发现失效危险软件容错设计是使得软件能发现失效危险并从临失效状态恢复的软件设计技术，有并从临失效状态恢复的软

48、件设计技术，有两种主要的软件容错设计方法：两种主要的软件容错设计方法：恢复块（恢复块（Recovery Blocks）N-版本（版本（N-version）编程）编程 1）恢复块技术）恢复块技术检测到错误后将执行软件模块的另一个不同版本。在执行模块的一个版本前，首先要创建检查点，这有助于在该版本执行失败后恢复状态，并为检测到错误后执行下一个版本提供有效的起始点。2）N- 版本编程版本编程N版本编程是一种多版本技术，关键模块的不同版本被设计成满足同样的基本需求，每个版本完成同样的任务，但却使用不同的方式。这些版本同时执行，它们的输出结果提交给一个表决系统以决定正确的结果，对输出正确性的判断基于对所

49、有输出的比较，出现不一致的情况时利用多数表决决定最优先的结果。设计多样性设计多样性恢复块技术和恢复块技术和N-版本编程都是基于设计多样版本编程都是基于设计多样性性当不同的开发者采用不同方法实现相同的需当不同的开发者采用不同方法实现相同的需求时，一个合理的假设是不同版本的软件不求时，一个合理的假设是不同版本的软件不大可能包含相同的缺陷，因此，也就不会产大可能包含相同的缺陷，因此，也就不会产生相同的失效。生相同的失效。设计多样性可以通过以下多种方式达到：设计多样性可以通过以下多种方式达到：使用不同的设计方法来实现需求。使用不同的设计方法来实现需求。使用不同的程序设计语言来完成实现。使用不同的程序设

50、计语言来完成实现。使用不同的开发工具，且在不同的开发环境中完成。使用不同的开发工具，且在不同的开发环境中完成。明确要求在实现某些关键过程时使用不同的算法。明确要求在实现某些关键过程时使用不同的算法。（3）软件失效模式和影响）软件失效模式和影响分析分析软件失效模式和影响分析（软件失效模式和影响分析（Failure Model and Effects Analysis，FMEA）主要是在）主要是在软件开发阶段的早期（需求阶段和设计阶软件开发阶段的早期（需求阶段和设计阶段），通过识别软件失效模式，研究分析段），通过识别软件失效模式，研究分析各种失效模式产生的原因及其造成的后果各种失效模式产生的原因及

51、其造成的后果，寻找消除和减少其有害后果的方法，以，寻找消除和减少其有害后果的方法，以尽早发现潜在的问题，并采取相应的措施尽早发现潜在的问题，并采取相应的措施，从而提高软件的可靠性和安全性。，从而提高软件的可靠性和安全性。FMEA目的在于分析各种失效模式对系统的目的在于分析各种失效模式对系统的影响，从而在软件实现之前为改进设计质影响，从而在软件实现之前为改进设计质量提供依据。量提供依据。相关概念相关概念软件失效（软件失效（software failure）。软件失效）。软件失效就是泛指程序在运行中丧失了全部或部分就是泛指程序在运行中丧失了全部或部分功能、出现偏离预期的正常状态的事件。功能、出现偏

52、离预期的正常状态的事件。软件失效模式（软件失效模式（software failure mode）。软件失效模式是指软件失效的不同类型。软件失效模式是指软件失效的不同类型，通常用于描述软件失效发生的方式以及，通常用于描述软件失效发生的方式以及对设备运行可能产生的影响。对设备运行可能产生的影响。软件失效的影响（软件失效的影响（software failure effect）。软件失效的影响是指软件失效模式对）。软件失效的影响是指软件失效模式对软件系统的运行、功能或状态等造成的后软件系统的运行、功能或状态等造成的后果。果。FMEA分析方法分析方法软件系统级软件系统级FMEA：在软件设计阶段的早期：在

53、软件设计阶段的早期，对软件体系结构进行安全性评估，在此，对软件体系结构进行安全性评估，在此阶段进行体系结构的修改代价较低，分析阶段进行体系结构的修改代价较低，分析对象是设计阶段早期的高层次子系统、部对象是设计阶段早期的高层次子系统、部件、模块以及它们之间的关系。件、模块以及它们之间的关系。软件详细级软件详细级FMEA：在详细设计完成后进行：在详细设计完成后进行，验证详细设计是否满足安全性设计要求，验证详细设计是否满足安全性设计要求，分析对象是至少已完成过程设计、由伪，分析对象是至少已完成过程设计、由伪代码或其他方式描述的模块。代码或其他方式描述的模块。软件失效模式和影响分析软件失效模式和影响分

54、析 FMEA ( Failure Model and Effects Analysis)软件系统级软件系统级FMEA过程过程如何描述和刻画系统级FMEA的分析对象，即如何描述目标软件系统的层次结构以及层次结构中各个模块之间的依赖关系是系统级FMEA分析需要关注和解决的关键问题。只有正确、充分地描述了目标软件系统的逻辑单元、层次结构和各个模块之间的依赖关系，才可能找出每个单元可能存在的、危害整个系统安全运行的失效模式，并根据模块间的依赖关系高效的分析失效的原因、影响和后果，然后在设计时有针对性的采取相应的改进措施，以保证最终系统安全的运行。（4）软件故障树分析）软件故障树分析软件故障树分析（软件

55、故障树分析（Fault Tree Analysis，FTA）就是在软件系统设计过程中，通过对）就是在软件系统设计过程中，通过对可能造成系统故障的各种因素（包括硬件可能造成系统故障的各种因素（包括硬件、软件、环境、人为因素等）进行分析，、软件、环境、人为因素等）进行分析，画出逻辑框图（即故障树），从而确定系画出逻辑框图（即故障树），从而确定系统故障原因的各种可能组合，采取相应的统故障原因的各种可能组合，采取相应的纠正措施，是提高系统可靠性的一种设计纠正措施，是提高系统可靠性的一种设计分析方法。分析方法。将不希望发生的事件（故障）作为顶级事将不希望发生的事件（故障）作为顶级事件，然后从该事件向下分

56、解。最主要的用件，然后从该事件向下分解。最主要的用途是把顶级关键事件转换为在子系统或模途是把顶级关键事件转换为在子系统或模块级别必须防止的事件，然后利用经验确块级别必须防止的事件，然后利用经验确定有害事件的潜在原因。定有害事件的潜在原因。 故障树的构造过程故障树的构造过程故障分析是构造故障树最关键的一步。由故障分析是构造故障树最关键的一步。由设计人员、质量保证人员共同合作。设计人员、质量保证人员共同合作。以顶端事件为以顶端事件为“根根”向下倒长的故障树构造向下倒长的故障树构造步骤：步骤： 广泛收集并分析有关技术资料广泛收集并分析有关技术资料 选择顶事件选择顶事件 生成故障树生成故障树 简化故障

57、树简化故障树故障树图形符号故障树图形符号事件符号与逻辑符号：事件符号与逻辑符号：使用逻辑使用逻辑符号对事符号对事件逐步向件逐步向下分解，下分解，将顶级事将顶级事件细化到件细化到最基本的最基本的潜在事件潜在事件高可信软件的设计方法高可信软件的设计方法黑盒行为黑盒行为状态盒行为状态盒行为明盒行为明盒行为形式化方法形式化方法净室方法净室方法（5）形式化方法）形式化方法形式化方法是关于在计算系统的开发中进行严格推理的理形式化方法是关于在计算系统的开发中进行严格推理的理论、技术和工具，它主要包括论、技术和工具，它主要包括形式规约技术形式规约技术（Formal Specification）和）和形式验证技

58、术形式验证技术（Formal Verification）。是提高软件质量的重要途径。是提高软件质量的重要途径。形式规约技术形式规约技术使用具有严格数学定义语法和语义的语言刻使用具有严格数学定义语法和语义的语言刻画软件系统及其性质，可以尽早发现需求和设计中的错误画软件系统及其性质，可以尽早发现需求和设计中的错误、歧义、不一致和不完全。、歧义、不一致和不完全。 数学上的抽象和组合概念是数学上的抽象和组合概念是形式化规约技术的重要基础。形式化规约技术的重要基础。形式化验证形式化验证是在形式化规约的基础上建立软件系统及其性是在形式化规约的基础上建立软件系统及其性质的关系，即分析系统是否具有所期望性质的

59、过程，主要质的关系，即分析系统是否具有所期望性质的过程，主要分为两类：模型检验（分为两类：模型检验（Model Checking）和定理证明（）和定理证明（Theorem Proving）。）。 形式化方法形式化方法模型检验技术是通过搜索待验证软件系统模模型检验技术是通过搜索待验证软件系统模型的有穷状态空间来检验系统的行为是否具型的有穷状态空间来检验系统的行为是否具备预期性质的一种有穷状态系统自动验证技备预期性质的一种有穷状态系统自动验证技术。术。定理证明技术是将软件系统和性质都用逻辑定理证明技术是将软件系统和性质都用逻辑方法来规约，基于公理和推理规则组成的形方法来规约，基于公理和推理规则组成

60、的形式系统，以如同数学中定理证明的方法来证式系统，以如同数学中定理证明的方法来证明软件系统是否具备所期望的关键性质。明软件系统是否具备所期望的关键性质。 模型检验技术和定理证明技术优势互补。各模型检验技术和定理证明技术优势互补。各有优点和缺点。有优点和缺点。形式化方法能以严格的方式保证软件可信性形式化方法能以严格的方式保证软件可信性，但理论基础复杂，对技术人员的理论素养，但理论基础复杂，对技术人员的理论素养和要求很高。和要求很高。（6）净室方法）净室方法净室软件工程（净室软件工程（Clean-room Software Engineering）将形式化方法的规范、设计）将形式化方法的规范、设计