[信息与通信]第9章系统设计技术.ppt

《[信息与通信]第9章系统设计技术.ppt》由会员分享，可在线阅读，更多相关《[信息与通信]第9章系统设计技术.ppt（88页珍藏版）》请在三一办公上搜索。

1、第9章系统设计技术,9.1 引言9.2 设计流程9.3 系统设计的形式化方法9.4 需求分析与规格说明9.5 系统分析与体系结构设计9.6 质量保证思考与练习题,9.1 引 言,多数真正的嵌入式系统的设计实际上是很复杂的，其功能要求非常详细，且必须遵循许多其他要求，如成本、性能、功耗、质量、开发周期等。大多数嵌入式系统的复杂程度使得无法由个人设计和完成，而必须在一个开发团队中相互协作来完成。这样就使得开发人员必须遵循一定的设计过程，明确分工，相互交流并能达成一致。设计过程还会受到内在和外在因素的影响而变化。外在影响包括如消费者的变化、需求的变化、产品的变化以及元器件的变化等。内在影响包括如工作

2、的改进、人员的变动等。,9.2 设 计 流 程,9.2.1 嵌入式系统的开发过程嵌入式系统是专用的计算机系统，运行在特定的目标环境中，需要同时满足功能和性能等方面的要求。在嵌入式系统的开发过程中，要考虑到实时性、可靠性、稳定性、可维护性、可升级、可配置、易于操作、接口规范、抗干扰、物理尺寸、重量、功耗、成本、开发周期等多种因素。良好的设计方法在嵌入式系统的开发过程中是必不可少的。首先，好的方法有助于规划一个清晰的工作进度，避免遗漏重要的工作，例如性能的优化和可靠性测试对于一个合格的嵌入式产品而言是不可或缺的。其次，采用有效的方法可以将整个复杂的开发过程分解成若干可以控制的步骤，通过现代一些先进

3、计算机辅助设计工具的辅助，我们可以按部就班、有条不紊地完成整个项目。,图9-1 嵌入式系统开发的一般过程,1系统定义阶段系统定义阶段需要确定系统开发最终实现的目标、实现目标的可行性、实现目标应采用的策略、估计完成系统开发所需的资源和成本、制定工程进度安排计划。这一阶段的工作主要包括了系统定义、可行性分析、需求分析和规格说明四方面的内容。其中，需求分析是指从用户那里搜集系统的非形式描述。以此为基础经过进一步提炼得到系统的规格说明，并以此来设计系统的体系结构和系统构件。,通常，用户仅了解和关心实际使用问题和需要具备的功能，但是往往不能完整、准确地表达这种需求，更不清楚怎样利用计算机去实现所需的功能

4、。为了对系统进行准确无误地定义，就要求开发人员和用户之间充分交流，开发人员需要详细考察，最终得出经用户确认的、明确的系统实现逻辑模型。需求可分为功能部分和非功能部分。非功能性需求包括了性能、价格、物理尺寸和重量、功耗等方面的因素。,确认需求最好的方法是建立模型。模型可以使用原始数据来模拟功能，并可以在计算机上运行。模型还应让用户了解系统是如何工作的，以及用户如何与系统交互。通常，系统的非功能模型可以让用户了解系统的特性。对一个大型的系统进行系统定义和需求分析是一件繁琐的工作，可以从先获取相对少量的、简单的信息入手。表9-1演示了一个简单的需求表格的样本。,表9-1 需求表格样本,*名称给项目取

5、一个好的名称，可以使设计目的更加明确，也便于交流、讨论时使用。*目的用最精炼的语言来描述清楚系统需要满足的需求。*输入和输出系统的输入和输出包含了大量的细节，如数据类型，包括模拟信号、数字信号、机械输入等；数据特性，包括周期性或非周期性数据、用户的输入、数据位数等；I/O设备类型，包括按键、ADC、显示器等。*功能功能的描述可以从对输入到输出的分析中得出，如当系统接收到输入时，执行哪些动作？用户通过界面输入的数据如何对该功能产生影响？不同功能之间如何相互作用？,*性能系统控制物理设备或者处理外界输入的数据都需要花费一定的时间。在大部分情况下，嵌入式系统在计算时间上都有要求，因此从系统定义和需求

6、分析开始，这种性能的要求就必须明确，并在执行过程中加以认真考虑，以便随时检查系统能否满足其性能要求。系统的处理速度通常又是系统实用性和成本的主要决定因素。在大多数情况下，软件的性能在很大程度上决定了系统的性能。,*生产成本产品的成本会影响其价格。成本包含两个主要部分：生成成本，包括购买构件以及组装费用等；不可再生的工程成本，包括人力成本以及设计费用等。生产成本主要包括的是硬件成本。通过对硬件成本的估计，可以大略估计产品形成后的价格；或者，基于产品最终的粗略价格来计算构建系统可以使用的硬件构件，因为价格最终会影响系统的体系结构。*功耗由电池供电的系统必须对功耗问题认真考虑。而系统的功耗需要在设计

7、开始时就要至少有一个粗略的了解。通常，基于这种了解可以使开发者决定系统是采用电池供电还是采用市电。,*物理尺寸和重量产品的物理尺寸和重量因使用领域的不同而不同。例如，对飞机上的电子设备，其重量应严格限制。又如，手持设备对系统的物理尺寸和重量都有严格限制。对系统的物理尺寸和重量有一定的了解有助于系统体系结构的设计。需求分析需要对其内部一致性进行检查。规格说明可以使设计者花费最少的时间和精力创建一个工作系统。规格说明应该足够明晰，以便别人可以验证它是否符合系统需求并且完全满足客户的期望；亦不能有歧义，设计者应知道什么是他们需要构造的。设计者可能碰到各种不同类型的由于不明确的规格说明而导致的问题。如

8、果在某个特定的状况下的某些特性在规格说明中不明确，那么设计者就可能设计出错误的功能。,2总体设计阶段总体设计是设计的第一步，其目的是描述系统如何实现由系统定义规定的那些功能。它需要解决嵌入式系统的总体构架，从功能实现上对软硬件进行划分；在此基础上，选定处理器和基本接口器件；根据系统的复杂程度确定是否使用操作系统，以及选择哪种操作系统；此外，还需要选择系统的开发环境。,本阶段应提供系统总体设计报告，推荐一个基本的软硬件配置方案，包括系统中各模块间的接口关系。确立总体方案时，要使用系统流程图或其他工具，描述每一种可能的系统组成，估计每一种方案的成本和效益，最终使总体方案建立在充分权衡各种方案利弊的

9、基础上。总体设计中对系统体系结构的描述必须同时满足功能上和非功能上的需求。一般地，功能约束在构建系统总体框图时集中考虑，而非功能约束在构建硬件和软件体系结构时考虑。在构建体系结构时对非功能约束的估算部分来源于经验，而建造一个简化的模型往往有助于做出更精确的估算。,3构件设计阶段构件通常包括硬件和软件两部分。构件设计使得构件、体系结构和规格说明相一致。一些构件是标准的，可以直接使用，如CPU和存储器。如果采用标准数据库，我们就可以用标准例程对该数据库进行访问。这些数据库中的数据不仅使用预定义的格式，而且被高度压缩以节省存储空间。在这些访问函数中使用标准软件不仅节约设计时间，而且有可能较快地实现像

10、数据解压缩这样的专用函数。,在大部分情况下，我们必须自己设计一些构件，如使用集成电路设计PCB、做大量定制的编程等。在设计期间，我们经常会利用一些计算机辅助设计工具和开发平台，并且对每个构件都需要进行功能和性能等方面的测试。嵌入式系统的设计还要求有较高的设计技能，在设计软件时要非常小心地读/写存储器以减小功耗。由于存储器访问是主要的功耗来源，因此存储器事务必须精心安排以避免多次读取同样的数据。,4系统集成阶段系统集成阶段的工作包括将测试完成的软件系统装入制作好的硬件系统中，进行系统综合测试，验证系统功能是否能够准确无误地实现，各方面指标是否符合设计要求，最后将正确无误的软件固化在目标硬件中。在

11、系统集成阶段通常会发现错误。按阶段构建系统并正确运行选好的测试，可以更容易地找出这些错误。如果每次只对一部分模块排错，则可以更容易地发现和识别较简单的错误。也只有在早期修正这些简单的错误，才能发现那些只有在系统高负荷时才能确定的、较复杂、较含混的错误。因此，我们必须确保在体系结构和构件设计阶段尽可能容易地按阶段组装系统和相对独立地测试系统功能。,9.2.2 设计流程设计流程是指在系统设计期间应遵遁的一系列步骤，其中的一些步骤可以由工具软件完成，如编译程序或者CAD系统；其他的步骤只可用手工完成。本节将讲述设计流程的基本特性。1瀑布模型图9-2演示了瀑布模型，这是一个为软件开发过程提出的模型。,

12、图9-2 软件开发的瀑布模型,瀑布开发模型由五个主要阶段构成：需求分析，确定目标系统的基本特点；体系结构设计，将系统的功能分解为主要的构件；编码，编写程序段并将其集成；测试，检测错误；维护，修改软件以适应环境变化，并改正错误，进行系统升级。各阶段的工作和信息总是由高级的抽象到较详细的设计步骤单向流动(只有少量的到高一级的反馈)。自顶向下的设计可以使得在早期设计阶段就对要完成的系统有很好的预见，但大多数的设计者并没有完全遵循这种自顶向下的设计顺序。很多的设计项目要进行试验和更改，就需要有从下到上的回溯。瀑布模型对于理解其他设计流程对它的改进是很重要的。,图9-3 软件设计的螺旋模型,2螺旋模型图

13、9-3演示了螺旋模型。,3逐步求精,图9-4 逐步求精开发模型,4分层设计流程许多复杂的嵌入式系统自身是由更多的小设计组成的。完整的系统可能需要有效的软件构件、专用的集成电路(ASIC)等，而且这些部件反过来可能由尚需设计的更小的部件组成。从最抽象的完整系统设计到为个别部件的设计，设计流程随着系统中的抽象层次而变化。流程的实现阶段从规格说明到测试，本身是一个完整的流程。在一个大项目中，每一个流程可能会由单独的人或小组来完成，每个组必须依靠其他组的结果。各个分组从上级小组获得要求，同时上级小组依靠各个分组的设计质量和测试性能。充分交流在这样的大项目中非常重要。其设计流程如图9-5所示。,图9-5

14、 嵌入式系统分层设计工作流程,5并行工程当众多的设计者一起设计一个大系统时，非常容易偏离完整的设计流程，导致每个设计者对自己在设计流程中的角色产生狭隘的看法。并行工程试图采用一种更宽的方法，使整个流程优化。对于并行工程而言，缩减设计时间是一个重要的目标，它为设计流程的很多方面提供了捷径，例如，可靠性、性能、功耗等。特别需要指出的是，要从并行工程中获得最多收益通常需要删除设计和制造之间的隔阂。为了获得最优结果，需要注意以下几点：(1)交叉功能组应包括来自不同学科的成员，包括制造业、硬件/软件设计和市场营销等。,(2)并行产品实现过程的活动是并行工程的中心。同时做几件事，例如同时设计几个不同的子系

15、统，减少设计时间是关键性的。(3)递增的信息共享和使用将有助于减少并行产品的实现导致意外的可能性。一旦新的信息可用，它就被共享并且集成到设计中。交叉功能组对于及时和高效的信息共享是很重要的。(4)综合的工程管理保证有人对整个工程负责，而且这种职责决不能在工程的某一方面一旦完成就放弃。(5)提供商尽早地和不间断地参与有助于充分利用提供商的能力。(6)客户尽早地和不间断地关注有助于确保产品能最好地满足其需要。,6其他软件工程的方法直接影响到设计流程。目前，软件开发过程结合了面向对象的方法和第四代工具。该方法针对嵌入式系统还在不断完善。在基于面向对象的开发过程中，开发组成员可以遵循并行过程的方法，并

16、发地设计组件。例如，一个小组设计设备驱动程序，另一个小组设计错误处理程序，还有一个小组设计应用程序。第四代软件工具能够根据较高级的设计规范生成代码，例如，自动报表生成、自动高级图形生成、创建数据库查询以及在创建网站时自动生成HTML代码等。,9.3 系统设计的形式化方法,9.3.1 UML简介,面向对象的规格说明可以看成互补的两个方面：(1)面向对象的规格说明允许用精确地模拟真实世界的对象和它们之间的交互方式来描述系统。(2)面向对象的规格说明提供一个基本的原语集，可以用特殊属性来描述系统，而不管系统构件和真实世界对象的关系如何。,1UML基本元素UML最基本的元素是对象和类，对象是类的实例。

17、另外，对象和类之间可能存在着各种不同的关系。类具有属性和行为。活跃类是能实现独立控制线程的类。对象可能有被赋予特定的值的属性。匿名对象属于某一个类但没有标识名。程序包是系统的组织单元，可能包括类定义、对象等。状态在状态图中描述行为。物理处理器是硬件部件。构件是实现一组接口的系统的物理组成部分。我们常常发现，在一个对象或类中会多次用到一些元素的特定组合。我们可以对这些组合命名，这样的一个定义在UML中称为模板(stereotype)。,表9-2 UML基本元素,图9-6 UML基本元素,2UML图UML的基本元素可以通过多种方式组合到一起，使用图形组可以完成以下建模任务：软件可视化、数据设计、算

18、法设计、软件设计、软件说明书、软件开发过程、工业过程等。表9-3列出了几种基本的UML图。图9-7给出了这些图的示例。,表9-3 UML 图,图9-7 UML图示例,图9-7 UML图示例,9.3.2 结构描述结构描述用于定义系统的基本构件。面向对象设计的首要构件自然是对象。一个对象包括定义其内部状态的属性集。当使用程序设计语言实现时，这些属性通常是一种数据结构中的变量或常量。有时，我们会在属性名后加上类型声明，但不总是对属性指定类型。图9-8说明了一个用UML符号表示的描述显示器(如CRT屏幕)的对象。折角页状图标中的文字是注释，它不对应于系统中的对象。在这里，属性是保存显示器内容的像素数组

19、。对象有两个特征：它有唯一的标识名以及它是一个类的成员。,图9-8 UML表示法中的对象,1类类是类型定义的一种形式从同一个类导出的所有对象尽管其属性可能有不同的值，但它们都有相同的性质。类定义了对象可能有的属性，也定义了对象与外界交互的操作。使用编程语言，操作将变成用来控制对象的一小段代码。图9-9所示是Display类的UML描述。Display类定义了对象中的pixels属性，当对象将一个类实例化时，对象就有了自己的存储空间，以便同一个类的不同对象有自己的属性值。其他的类能检查和修改类的属性。,图9-9 UML表示法中的类,2选择合适的界面显然，选择界面是面向对象设计中非常重要的决策。正

20、确的界面必须提供访问对象状态的方法(因为属性不能直接访问)和更新状态的方法。对象的界面必须通用，以充分利用它的性能。然而，过分通用会使对象庞大而缓慢。大而复杂的界面同样会使定义类的工作对于设计者来说难以理解和使用。,对象和类之间存在若干种类型的关系：关联发生在彼此通信但没有从属关系的对象间。聚集描述由较小的对象组成的复杂对象。组合是一种聚集类型，其中所有者不允许访问构件对象。泛化允许我们通过其他类定义类。,3类和对象的软件实现因为UML用于设计的很多阶段，所以它不是一种程序设计语言。因此，它的概念有时看起来很抽象。它有助于在程序设计语言中使用类和对象前理解其抽象概念。首先，我们用直接支持面向对

21、象技术的C+语言实现Display类和d1对象。下面是Display类的定义：,class Display pixels:pixeltypeIMAX,JMAX;public:Display()/*一个创建类的结构体的实例*/pixeltype pixel(int i,int j)return pixelsi,j;/*为清楚起见无限制地检查*/void set_pixel(pixeltype val,int i,int j)pixelsi,j=val;,在C+中，操作被称为方法。它包括参数列表、返回类型和方法的代码。C+代码比UML规格说明包含更多的细节，这是因为我们使用C+实现类，而UML描述

22、仅仅抓住系统的本质特征。Display类的例化为对象d1：Display d1;d1的例化在内存中建立了为d1保存像素值的数据结构。例如，类中定义的方法能调用d1，以控制它的像素值：apixel=d1.pixel(0,0);/*获取pixel 0,0的值*/object.method()的表示法说明正在运行特定对象的方法。确保特定方法可以在给定对象上使用是一种类型检查操作。,在非面向对象语言(如C语言)中实现类和对象具有一定的挑战性，但是仍能做得相当好。下面是一种描述Display类的属性和操作的方法：/*这些操作都在一个二维pixels数组上执行*/pixel pixelval(pixel*

23、px,int i,int j)return pxi,j;void set_pixel(pixel*px,pixeltype val,int i,int j)pxi,j=val;,这里我们选择不定义像素数组的显式类型，因为它是一个基本二维数组；在其他情况下，可用结构体定义对象的属性。我们定义了两个函数来实现操作，注意，与C+代码相比这些函数有额外的参数，第一个参数是我们要操作的数组。在面向对象语言中，像object.method()这种形式的符号用来运行特定对象的操作。当用C语言实现这个类时，我们必须自己写代码将方法的操作运用于代表对象的数据集。这意味着，在C语言的实现中，通常将对象的所有数据保

24、存在一个简单的结构中，可以是数组也可以是单个结构。要求程序员为对象的每一个函数调用按正确的顺序，提供正确的数据元素是很浪费时间且容易出错的。,下面是d1对象的示例：pixel d1_pixelsIMAX,JMAX;这行代码只例化了d1的数据结构，我们已经给出了操作的代码。为了实现标准C函数的调用，我们应用d1的属性编写如下代码：apixel=pixelval(d1_pixel,0,0);/*从d1数组获得pixel 0,0*/,4派生类像大多数面向对象语言一样，UML允许根据其他的类来定义一个类。如图9-10所示的例子中，派生了两种特殊的显示器类型，一个是BW_display，描述黑白显示器，

25、不需要增加新的属性和操作，但可以规定其以每像素一位的方式工作；另一个是Color_map_display，使用称为颜色映射表的图形设备，允许用户即使在每像素只有很少几位时，也可以从大量现有颜色中选择。这个类定义了color_map属性，该属性决定如何把像素值映射到显示颜色。一个派生类从它的基类继承所有的属性和操作。这里，Display类是其他两个类的基类。派生类定义为包括其基类的所有属性。,这是传递关系如果Display类是从其他类派生来的，那么BW_display类和Color_map_display类同样会继承Display类的基类的所有属性和操作。继承有两个目的：首先，它允许我们简洁地描

26、述一个与其他类共享某些特征的类；更重要的是，它取得类之间的这些关系并文档化。当我们要改变其中的任何类时，类结构的知识有助于确定这种改变的涉及面。例如，这种改变究竟是只影响Color_map_display对象还是影响所有Display对象？,图9-10 UML中派生类作为泛化的一种形式,5泛化和继承UML认为继承是泛化的一种形式。泛化关系在UML图中用空心箭头显示。BW_display和Color_map_display都是Display的特定版本，因此Display泛化了它的两个版本。UML允许多重继承，即一个类继承不止一个基类(大部分面向对象编程语言支持多重继承)。图9-11所示是一个多重

27、继承的例子，为了简便起见，我们忽略类的属性和操作的细节。在此，将Display类处理声音的Speaker类合并建立了Multimedia_display类，该类继承两个基类Display和Speaker的所有属性和操作。多重继承会导致属性集和操作的大小迅速增加，因此须小心使用。,图9-11 UML中的多重继承,一个链接描述对象间的关系，关联与链接的关系就像类与对象的关系，需要链接是因为对象通常不是孤立的，关联使我们获得这些链接的类型信息。图9-12显示了链接和一个关联的例子。当考虑系统中的实际对象时，有一个跟踪当前活动消息数目(例子中有两个)和指向活动消息的消息集。这时，链接定义了contai

28、ns关系。当泛化到类时，我们在消息集类和消息类之间定义一个关联，关联被画成标有关联名称contains的一条线。消息类一端的零和其他数字表示消息集类可能包括零个或多个消息对象。有时，可能要将数据附加到链接本身，我们可以通过附加保存关联数据的像类那样的方框到关联的边上来在关联中指明这一点。,图9-12 链接和关联,9.3.3 行为描述行为描述用来规定系统的行为和结构。规定操作的行为采用的一种方法是状态机。图9-13表示UML状态，两种状态间的转换用箭头表示。,图9-13 UML中的状态和转换,这些状态机不依赖硬件时钟的操作，一个状态向另一个状态改变由事件触发。事件是某一种动作，可能来自系统外部，

29、如用户按了一个按钮；也可能来自系统内部，如一个例程完成计算并将结果传送到另一个例程。下面将集中讨论图9-14中显示的用UML定义的三种类型的事件。,图9-14 UML中的信号、调用和定时器事件,信号是异步发生的，在UML中用标记为的对象定义。图中的这种对象作为事件存在的声明，因为它是对象，所以信号可能有传递给信号接收器的参数。在程序设计语言中，调用事件发生在程序调用模式后。定时事件导致机器在一定时间后离开某一状态。边上的标号tm(time_value)表示时间的数量，在这一时间后转换就发生。定时通常由外部定时器实现。这种符号简化了规格说明，允许我们服从定时机制的实现细节。,我们用同样的方式正如

30、转换上的标号，在UML图中表示所有类型信号的发生。考虑一个简单的状态机规则来理解UML状态机的语义。图9-15展示显示操作的状态机。开始和结束状态是特殊的状态，它有助于组织状态机的流程。状态机中的状态代表了不同的概念性的操作。某些情况下，根据输入或状态中的计算结果，我们采用状态条件转移，其他情况下都无条件转移到下一个状态。条件转移和无条件转移都使用调用事件。将复杂操作分解成几个状态有助于证明需求的步骤，类似于使用子例程来构建代码。,图9-15 UML中的状态机规格说明,有时给出随时间的操作顺序是很有用的，特别是在涉及到许多对象时。在这种情况下，可以建立一个顺序图，就像图9-16显示的鼠标单击事

31、件一样。顺序图有时与硬件时序图相似(虽然时间流在顺序图中是垂直的而在时序图中是水平的)。设计顺序图来显示特定情景或事件的选择这不便于显示互斥可能性的多寡。在这个案例中，操作序列表明了鼠标单击菜单区域时发生的事情。要处理图9-16顶部的三个对象。在每个对象的下面扩展出生命线，虚线表示对象的生存期。这里，所有对象在整个流程中保持存活状态，但在其他情况下，对象有可能随处理过程创建或撤消。生命线边上的方框表示序列中的控制焦点，即对象什么时候是活动处理的。这里，鼠标对象仅在创建mouse_click事件时是活动的；显示器对象一直是活动的，它用调用事件实现调用菜单对象两次：一次决定所选菜单项，一次执行实际

32、的菜单调用。find_region()调用在显示器对象内部，因此它在图中不以一个事件出现。,图9-16 UML中的顺序图,9.4 需求分析与规格说明,9.4.1 需求分析创建一个需求文档的目的是使用户和设计者可以有效地交流。设计者应该知道用户期望他们设计什么，而用户应该明白他们将得到什么。需求有两种类型：功能性需求和非功能性需求。一个功能性需求说明了这个系统必须做什么，例如FFT运算。一个非功能性需求可以是其他属性中的一些，包括物理尺寸、价格、功耗、开发周期、可靠性等。,一套好的需求分析应该满足以下的测试要求：(1)正确性需求不能错误地描述用户的要求。正确性还包括应该避免超出需要的需求，需求不

33、应该加上那些不必要的条件。(2)无二义性需求文档应该清晰，并且只用一种明确的语言解释。(3)完整性所有的需求都应该被包括。(4)可检验性应该有一个有效的方法来确保最后的产品满足每一种需求。例如，在不符合“吸引力”定义的情况下，一个想使系统组装吸引人的需求是很难验证的。,(5)一致性一个需求不能和另一个需求相矛盾。(6)可修改性需求文档应结构化，以便在不影响一致性、可检验性等情况下可以被修改以适应变化的需求。(7)可追踪性每个需求应满足以下可追踪性：可以追踪需求知道每个需求存在的价值。可以追踪需求之前创建的文档来理解它们如何和最终的需求相关联。可以向前追踪来理解每个需求在实现中如何被满足。可以向

34、后追踪以便知道哪一个需求是用户满意的。,9.4.2 规格说明1SDL使用状态机可以确定UML中的控制。SDL(System Descriptive Language，系统描述语言)是一种广泛使用状态机的规格说明语言，这种语言是通信产业为通信协议、电话系统等开发的。如图9-17所示，SDL规格说明包括状态、操作以及状态间有条件的和非条件的转换。SDL是一个面向事件的状态机模型，状态间的转换由内部或外部事件引发。,图9-17 SDL规格说明语言,2状态图表状态图表是一种常用的基于状态的规格说明的方法，基于一种事件驱动模型建立。状态图表允许状态被组合在一起表示普通的功能，两种基本的组合是OR(或)和

35、AND(与)。图9-18通过用OR状态描述的状态图表与传统的状态转换图的比较演示了一个OR状态的例子。该状态机描述了当s1、s2、s3收到输入i2时，机器将从s1、s2、s3的任一状态转换到状态s4。状态图表也可以通过在s1、s2、s3周围标出OR状态来表示这种特性。s123是OR状态的名字，在状态上方的小方块中给出。从OR状态s123出来的惟一转换表明了状态机处于s123包括的任意一个状态时接收到i2输入都会进入状态s4。OR状态不但允许成员状态间的相互转换，还允许内部状态间的相互转换(例如从s1到s3、从s2到s3)。OR状态仅仅是表明与这些状态相关的转换的一种工具。,图9-18 状态图表

36、中的OR状态,图9-19通过与传统状态机模型的比较演示了用状态图表符号表示的AND状态。传统的模型中，状态间有大量的转换，并且一组状态中只有一个入口点和一个出口点。,图9-19 状态图表中的AND状态,传统状态机中状态的名字显示了它们与AND状态部件的联系。这样，s1-3状态相当于状态图表的状态机sa部件处于s1状态且sb部件处于s3状态，依此类推。在传统方法中，我们能跳出这一组状态，进入s5状态，且仅当我们处于状态s2-4时接收r，在AND状态图中相当于sa处于s2状态、sb处于s4状态且状态机在这种组合状态下接收到r输入。尽管传统图模型与状态图表模型描述了同样的行为，然而在当每个部件有两种

37、状态并且状态间存在关系时，状态图表看起来要简单一些。,3AND/OR表图9-20演示了一个AND/OR表的例子及其所描述的布尔表达式。AND/OR表中的行用表达式中的基本变量标记。每一列相当于表达式中的一个AND项。例如，AND项(条件2与非条件3)在第二列中用使条件2为真、条件3为假、条件1忽略来表示。这就相当于AND条件要为真时，必须有条件2为真且条件3为假。我们用这种表来估计一个给定的条件在系统中是否有效。变量的当前状态与表中的元素相比较，如果所有当前变量的值与该列中给定的要求的值相等，则该列的值就为真。当我们期望一个AND/OR表达时，若列中任一值为真，则这个表为真。这个符号表和状态图

38、表最大的不同在于“否”的情况在表中明确地表示了出来，实践证明，这样的表示对在一个规格说明表中寻找问题有很大帮助。,图9-20 AND/OR表,9.5 系统分析与体系结构设计,把一个规格说明变成一种体系结构设计，这对于理解一个复杂系统的整体结构是一种非常有用的方法。CRC卡方法是帮助分析一个系统结构的一种普遍、实用的方法。由于它支持封装数据和功能，因此特别适用于面向对象的设计。,缩写CRC代表此方法所要确认的以下三个主要项目：*类(Class)定义了数据和功能的逻辑分组。*责任(Responsibility)描述类所要做的工作。*协作者(Collaborator)与给定类相关的其他类。CRC卡的

39、命名源自人们习惯于将此方法写在标签上，在其空白处填写类的名字、责任、协作者以及其他的相关信息。CRC卡方法的实质是要人们填写这些卡片，讨论并更新卡片内容，直到获得自己满意的结果。图9-21所示为CRC卡的示意图。,图9-21 CRC卡示意图,对于计算机系统设计而言，CRC卡方法似乎是一种比较原始的方法。然而，它有一些重要的优点。首先，它很容易让非计算机专业人员来创建CRC卡。在系统设计中，获得领域专家的忠告是非常重要的，这些专家可能是擅长汽车电子设备方面的汽车设计人员，也可能是从事PDA设计的人类遗传因子研究方面的权威人士。CRC卡方法很简便，所以它对非计算机领域的专家使用此方法并不产生影响，

40、而且还允许你收集他们的输入信息。其次，通过鼓励领域专家分组工作和分析情况，可以很好地帮助计算机专家进行工作。在CRC卡方法中运用的预排过程对于明确设计范围和决定系统的哪一部分未被充分地理解是非常有用的。在基于工具的设计和编码中这种简便方法很有价值。而软件工程工具对自动创建CRC卡非常有效。,用CRC卡分析系统时，应该按下列步骤进行：(1)设计类的初始清单。(2)书写责任和协作者初始清单。(3)创建一些使用脚本。(4)预演脚本。(5)求精类、责任、协作者。(6)添加类之间的关系。,9.6 质 量 保 证,国际标准化组织(ISO)制定了ISO 9000系列质量标准。ISO 9000在工业领域中的应

41、用范围十分广泛，包括但不限于嵌入式系统的硬件和软件。针对某一特定产品的质量标准可以制定适应该产品的特殊的、具体的规范，但是涉及范围广泛的标准不可能对工业中的每一领域都面面俱到。所以，ISO 9000重在产品制造和服务的过程。满足ISO 9000的生产过程将对整个组织以及设计和制造过程中的每一步产生影响。,检测组织软件开发过程质量的一个众所周知的方法是卡内基梅隆大学软件工程研究所提出的能力成熟度评价模型(CMM)。CMM提供了一个判断组织成熟度的模型，CMM将组织的成熟度定义为5个等级。(1)初始级(Initial)：开发过程的组织工作杂乱无章，缺乏定义良好的软件开发过程。项目的成功完全依赖于个

42、人的努力，与组织自身无关。(2)可重复级(Repeatable)：这一级别提供了跟踪机制，使管理人员可以了解软件开发的费用、调度、正在开发系统与目标相符的程度等。,(3)定义级(Defined)：管理和开发过程均已实现文档化和标准化。所有项目均使用文档化的并且核准了的标准方法。(4)管理级(Managed)：这一级别可对开发过程和产品质量进行详细的测量。(5)优化级(Optimizing)：CMM的最高级别，利用详细的测量反馈资料来不断地完善提高组织的软件开发过程。,1需求验证验证需求可以采取许多措施来保证客户和起草需求的人相互交流。原型是一个与最终用户沟通的非常有用的工具，与只是用广泛的技术

43、术语向用户描述系统不同的是，原型至少可使客户听到、看到、感受到系统的一些重要方面。当然，原型不可能完成系统的所有功能，因为设计工作还没有做。但是，特殊的用户界面可用于建立原型和用户测试。可以用预先设定的或随机的数据来仿真系统的内部操作。原型有助于最终用户判断许多功能上的和非功能上的需求，如数据显示、操作速度、大小、重量，等等。,2规格说明验证用于验证需求的工具和方法如建立原型、规格说明语言和参照已存系统，对验证规格说明的正确性同样有用。审计工具可用于检验一致性、完整性等。使用脚本可帮助设计者完成规格说明的细节工作，并确保其完整性和正确性。在某种情况下，形式化技术(即使用数学证明的设计技术，证明

44、可手工完成或自动完成)可能也很有效。某些复杂系统说明起来可能很简单，但整个时间序列的行为却错综复杂，自动证明过程对此特别有用。,设计评审是所有质量保证开发过程中的至关重要的组成部分，是在设计阶段早期发现错误的简单、低成本的方法。通过设计评审会议，开发小组成员对设计工作进行讨论，并评审系统某个组成部分如何工作。也可以运用设计评审提高软件实现的质量，并使以后的改动更加容易实现。在设计评审会议前，设计小组准备好描述将被评审的系统组成部分的一系列文档，包括代码清单、流程图、规格说明等，并将文档事先分发给评审小组的其他人员；设计评审负责人协调开会时间、分发资料等。,设计评审会议期间，设计评审负责人确保会

45、议顺利进行，记录员进行会议情况记录。该系统组成部分的设计者提交设计成果。从上向下的提交顺序较好，先提交需求和界面描述，然后提交组成部分的整体结构及其细节，最后是测试策略。参与者查看所有细化程度的所有类型的问题，通常所涉及的问题包括：设计小组提交的规格说明与整个系统的规格说明是否一致，设计小组是否有解释上的错误，该系统组成部分的内部体系结构工作是否正确及测试策略是否充分，等等。,设计评审记录员所做的记录用于评审会议的后续处理。设计小组应该改正错误并处理与会者所关注的问题。同时，设计小组还要记下他们所做的工作。设计评审负责人与设计小组进行沟通，以确保设计评审中提出的问题得到了修改，并将修改结果交给

46、设计评审参与者。,最终通过测量正在开发系统的错误率并利用统计结果，不仅可以帮助我们确定针对某一个系统正确的测试工作量，而且还可以利用在一个项目中得到的知识预测新项目的哪些地方可能出现错误。设计过程的测量也提供了准确的信息，帮助我们更好地理解。一项软件项目的研究发现，在设定的软件例子中46%的错误源于对问题的错误理解、交流不畅以及解决问题的技术知识的不充分等，而只有38%的错误与更先进的工具和其他技术方法有关。另一项研究结果表明，许多错误是由开发过程中存在的高层问题引入的，如功能设计不完善以及糟糕的文档等。另外，由于对发现问题的不恰当修改也会为排错过程引入少量新的错误。,思考与练习题,1简要描述需求和规格说明之间的差异。2简要描述规格说明和体系结构之间的差异。3在设计方法学的哪一个阶段确定使用CPU的类型？4在设计方法学的哪一个阶段选择编程语言？5在设计方法学的哪一个阶段针对功能正确性来测试设计？6开发一个状态图，定义一次电话呼叫中的基本活动，包括摘机、拨号、接通、通话、挂机和结束呼叫。在可能的时候使用AND和OR状态。7开发一个UML图，描述一个图形用户接口，使该设计模型既可用于PDA，又可用于机顶盒。,