《嵌入式系统原理与开发》课件-第9章

第9章系统设计技术9.1引言

9.2嵌入式系统的开发过程和设计流程

9.3系统设计的形式化方法

9.4需求分析与规格说明

9.5系统分析与体系结构设计9.6质量保证

思考与练习题

9.1引言

多数真正的嵌入式系统的设计实际上是很复杂的，其功能要求非常详细，且必须遵循许多其他要求，如成本、性能、功耗、质量、开发周期等。大多数嵌入式系统的复杂程度使得无法由个人设计和完成，而必须在一个开发团队中相互协作来完成。这样就使得开发人员必须遵循一定的设计过程，明确分工，相互交流并能达成一致。

设计过程还会受到内在和外在因素的影响。外在影响包括如消费者的变化、需求的变化、产品的变化以及元器件的变化等。内在影响包括如工作的改进、人员的变动等。这些都要求嵌入式系统开发人员必须掌握一定的系统设计方面的技术。因此，本章我们将研究设计方法学方面的一些知识。9.2节介绍嵌入式系统的设计流程，内容包括嵌入式系统开发的一般过程和通常采用的一些设计流程。9.3节介绍系统设计的形式化方法，首先简要介绍UML的一些基础知识， 然后介绍如何利用UML进行系统的结构描述和行为描述。9.4节介绍系统定义过程中进行需求分析和规格说明的方法。9.5节介绍在规格说明的基础上如何进行系统的体系结构设计。9.6节讨论关于质量保证方面的一些问题。

9.2嵌入式系统的开发过程和设计流程

9.2.1开发过程

嵌入式系统是专用的计算机系统，运行在特定的目标环境中，需要同时满足功能和性能等方面的要求。在嵌入式系统的开发过程中，要考虑到实时性、可靠性、稳定性、可维护性、可升级、可配置、易于操作、接口规范、抗干扰、物理尺寸、重量、功耗、成本、开发周期等多种因素。良好的设计方法在嵌入式系统的开发过程中是必不可少的。首先，好的方法有助于规划一个清晰的工作进度，避免遗漏重要的工作，例如性能的优化和可靠性测试对于一个合格的嵌入式产品而言是不可或缺的。其次，采用有效的方法可以将整个复杂的开发过程分解成若干可以控制的步骤，通过一些先进计算机辅助设计工具的辅助，我们可以按部就班、有条不紊地完成整个项目。最后，通过定义全面的设计过程，可以使整个开发团队的各个成员更好地理解自身的工作，方便成员之间相互交流与协作。在嵌入式系统的开发过程中，团队的概念至关重要。

图9-1是嵌入式系统开发的一般过程。图9-1嵌入式系统开发的一般过程

1．系统定义阶段

系统定义阶段需要确定系统开发最终实现的目标、实现目标的可行性、实现目标应采用的策略、估计完成系统开发所需的资源和成本、制定工程进度安排计划。这一阶段的工作主要包括了系统定义、可行性分析、需求分析和规格说明这四方面的内容。其中，需求分析是指从用户那里搜集系统的非形式描述。以此为基础经过进一步提炼得到系统的规格说明，并以此来设计系统的体系结构和系统构件。通常，用户仅了解和关心实际使用问题和需要具备的功能，但是往往不能完整、准确地表达这种需求，更不清楚怎样利用计算机去实现所需的功能。为了对系统进行准确无误地定义，就要求开发人员和用户之间充分交流，开发人员需要详细考察，最终得出经用户确认的、明确的系统实现逻辑模型。

需求可分为功能部分和非功能部分。非功能性需求包括了性能、价格、物理尺寸和重量、功耗等方面的因素。

确认需求最好的方法是建立模型。模型可以使用原始数据来模拟功能，并可以在计算机上运行。模型还应让用户了解系统是如何工作的，以及用户如何与系统交互。通常，系统的非功能模型可以让用户了解系统的特性。对一个大型的系统进行系统定义和需求分析是一件繁琐的工作，可以从先获取相对少量的、简单的信息入手。表9-1演示了一个简单的需求表格的样本。表9-1需求表格样本

2．总体设计阶段

总体设计是设计的第一步，其目的是描述系统如何实现由系统定义规定的那些功能。它需要解决嵌入式系统的总体构架，从功能实现上对软硬件进行划分；在此基础上，选定处理器和基本接口器件；根据系统的复杂程度确定是否使用操作系统，以及选择哪种操作系统；此外，还需要选择系统的开发环境。本阶段应提供系统总体设计报告，推荐一个基本的软硬件配置方案，包括系统中各模块间的接口关系。确立总体方案时，要使用系统流程图或其他工具，描述每一种可能的系统组成，估计每一种方案的成本和效益，最终使总体方案建立在充分权衡各种方案利弊的基础上。总体设计中对系统体系结构的描述必须同时满足功能上和非功能上的需求。一般地，功能约束在构建系统总体框图时集中考虑，而非功能约束在构建硬件和软件体系结构时考虑。在构建体系结构时对非功能约束的估算部分来源于经验，而建造一个简化的模型往往有助于做出更精确的估算。

3．构件设计阶段

构件通常包括硬件和软件两部分。构件设计使得构件、体系结构和规格说明相一致。

一些构件是标准的，可以直接使用，如CPU和存储器。如果采用标准数据库，我们就可以用标准例程对该数据库进行访问。这些数据库中的数据不仅使用预定义的格式，而且被高度压缩以节省存储空间。在这些访问函数中使用标准软件不仅节约设计时间，而且有可能较快地实现像数据解压缩这样的专用函数。

4．系统集成与性能测试阶段

系统集成与性能测试阶段的工作包括将测试完成的软件系统装入制作好的硬件系统中，进行系统综合测试，验证系统功能是否能够准确无误地实现，各方面指标是否符合设计要求，最后将正确无误的软件固化在目标硬件中。在系统集成阶段通常会发现错误。按阶段构建系统并正确运行选好的测试，可以更容易地找出这些错误。如果每次只对一部分模块排错，则可以更容易地发现和识别较简单的错误。也只有在早期修正这些简单的错误，才能发现那些只有在系统高负荷时才能确定的、较复杂、较含混的错误。因此，我们必须

确保在体系结构和构件设计阶段尽可能容易地按阶段组装系统和相对独立地测试系统功能。9.2.2设计流程

设计流程是指在系统设计期间应遵遁的一系列步骤，其中的一些步骤可以由工具软件，如编译程序或者CAD系统完成；其他的步骤只可用手工完成。本节将讲述设计流程的基本特性。

1．瀑布模型

图9-2演示了瀑布模型，这是一个为软件开发过程提出的模型。图9-2软件开发的瀑布模型

2．螺旋模型

图9-3演示了螺旋模型。图9-3软件设计的螺旋模型

3．逐步求精

图9-4演示了逐步求精的设计方法。图9-4逐步求精开发模型

4．分层设计流程

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

5．并行工程

当众多的设计者一起设计一个大系统时，非常容易偏离完整的设计流程，导致每个设计者对自己在设计流程中的角色产生狭隘的看法。并行工程试图采用一种更宽的方法，使整个流程优化。对于并行工程而言，缩减设计时间是一个重要的目标，它为设计流程的很多方面提供了捷径，例如可靠性、性能、功耗等。特别需要指出的是，要从并行工程中获得最多收益，通常需要消除设计和制造之间的隔阂。为了获得最优结果，需要注意以下几点：

(1)交叉功能组应包括来自不同学科的成员，包括制造业、硬件/软件设计和市场营销等。

(2)并行产品实现过程的活动是并行工程的中心。同时做几件事，例如同时设计几个不同的子系统，减少设计时间是关键性的。

(3)递增的信息共享和使用将有助于减少并行产品的实现导致意外的可能性。一旦新的信息可用，它就被共享并且集成到设计中。交叉功能组对于及时和高效的信息共享是很重要的。

(4)综合的工程管理保证有人对整个工程负责，而且这种职责决不能在工程的某一方面一旦完成就放弃。

(5)提供商尽早地和不间断地参与有助于充分利用提供商的能力。

(6)客户尽早地和不间断地关注有助于确保产品能最好地满足其需要。

6．其他

软件工程的方法直接影响到设计流程。目前，软件开发过程结合了面向对象的方法和第四代工具。该方法针对嵌入式系统还在不断完善。

在基于面向对象的开发过程中，开发组成员可以遵循并行过程的方法，并发地设计组件。

第四代软件工具能够根据较高级的设计规范生成代码，例如自动报表生成、自动高级图形生成、创建数据库查询以及在创建网站时自动生成HTML代码等。

总之，不断改进的模型，其过程生命周期是迭代的，直到进行验证、确认和交付或安装到系统的ROM中为止。 9.3系统设计的形式化方法

9.3.1UML简介

在上一节我们将嵌入式系统的开发过程划分为四个阶段，在不同的设计阶段将按照不同层次的抽象完成许多不同的设计任务。在实际工作中，随着设计过程的延伸，很可能会出现这样的情况，即每到一个新的抽象层次可能会对系统重新考虑设计。这种情况的发生主要是由于我们没有在设计工作的起始就为系统建立一个合适的模型而引起的。我们希望的设计过程是一种逐步求精的过程，即随着设计过程的延伸逐渐在设计中加入新的细节而不是彻底推翻原先的设计。因此，系统设计中就需要用到一种建模语言，以帮助我们不会偏离设计的主线。统一建模语言UML是一种面向对象的可视化语言，它可以用图表的方式概念化这些不同的设计任务，显然这对于设计过程中的多层抽象非常有用。

面向对象的规格说明可以看成互补的两个方面：

(1)面向对象的规格说明允许用精确地模拟真实世界的对象和它们之间的交互方式来描述系统。

(2)面向对象的规格说明提供一个基本的原语集，可以用特殊属性来描述系统，而不管系统构件和真实世界对象的关系如何。

1．UML基本元素

UML最基本的元素是对象和类，对象是类的实例。另外，对象和类之间可能存在着各种不同的关系。类具有属性和行为。活跃类是能实现独立控制线程的类。对象可能有被赋予特定的值的属性。匿名对象属于某一个类但没有标识名。程序包是系统的组织单元，可能包括类定义、对象等。状态在状态图中描述行为。物理处理器是硬件部件。构件是实现一组接口的系统的物理组成部分。

我们常常发现，在一个对象或类中会多次用到一些元素的特定组合。我们可以对这些组合命名，这样的一个定义在UML中称为模板(stereotype)。

表9-2列出了UML的基本元素。图9-6给出了这些基本元素的表示。表9-2UML基本元素图9-6UML基本元素

2．UML图

UML的基本元素可以通过多种方式组合到一起。使用图形组可以完成以下建模任务：软件可视化、数据设计、算法设计、软件设计、软件说明书、软件开发过程、工业过程等。表9-3列出了几种基本的UML图。图9-7给出了这些图的示例。表9-3UML图图9-7UML图示例9.3.2结构描述

结构描述用于定义系统的基本构件。面向对象设计的首要构件自然是对象。一个对象包括定义其内部状态的属性集。当使用程序设计语言实现时，这些属性通常是一种数据结构中的变量或常量。有时，我们会在属性名后加上类型声明，但不总是对属性指定类型。图9-8说明了一个用UML符号表示的描述显示器(如CRT屏幕)的对象。折角页状图标中的文字是注释，它不对应于系统中的对象。在这里，属性是保存显示器内容的像素数组。对象有两个特征：它有唯一的标识名以及它是一个类的成员。图9-8UML表示法中的对象

1．类

类是类型定义的一种形式——从同一个类导出的所有对象尽管其属性可能有不同的值，但它们都有相同的性质。类定义了对象可能有的属性，也定义了对象与外界交互的操作。 使用编程语言，操作将变成用来控制对象的一小段代码。图9-9所示是Display类的UML描述。Display类定义了对象中的pixels属性。当对象将一个类实例化时，对象就有了自己的存储空间，以便同一个类的不同对象有自己的属性值。其他的类能检查和修改类的属性。图9-9UML表示法中的类

2．选择合适的界面

显然，选择界面是面向对象设计中非常重要的决策。正确的界面必须提供访问对象状态的方法(因为属性不能直接访问)和更新状态的方法。对象的界面必须通用，以充分利用它的性能。然而，过分通用会使对象庞大而缓慢。大而复杂的界面同样会使定义类的工作对于设计者来说难以理解和使用。

对象和类之间存在若干种类型的关系：

关联——发生在彼此通信但没有从属关系的对象间。

聚集——描述由较小的对象组成的复杂对象。

组合——是一种聚集类型，其中所有者不允许访问构件对象。

泛化——允许我们通过其他类定义类。

3．类和对象的软件实现

因为UML用于设计的很多阶段，所以它不是一种程序设计语言。因此，它的概念有时看起来很抽象。它有助于在程序设计语言中使用类和对象前理解其抽象概念。首先，我

们用直接支持面向对象技术的C++语言实现Display类和d1对象。下面是Display类的定义：

4．派生类

像大多数面向对象语言一样，UML允许根据其他的类来定义一个类。如图9-10所示的例子中，派生了两种特殊的显示器类型：一个是BW_display，描述黑白显示器，不需要增加新的属性和操作，但可以规定其以每像素一位的方式工作；另一个是Color_map_display，使用称为颜色映射表的图形设备，允许用户即使在每像素只有很少几位时，也可以从大量现有颜色中选择。这个类定义了color_map属性，该属性决定如何把像素值映射到显示颜色。一个派生类从它的基类继承所有的属性和操作。图9-10UML中派生类作为泛化的一种形式

5．泛化和继承

UML认为继承是泛化的一种形式。泛化关系在UML图中用空心箭头显示。BW_display和Color_map_display都是Display的特定版本，因此Display泛化了它的两个版本。UML允许多重继承，即一个类继承不止一个基类(大部分面向对象编程语言都支持多重继承)。图9-11所示是一个多重继承的例子，为了简便起见，我们忽略类的属性和操作的细节。在此，将Display类和处理声音的Speaker类合并建立了Multimedia_display类，该类继承两个基类Display和Speaker的所有属性和操作。多重继承会导致属性集的大小迅速增加和操作的迅速增多，因此须小心使用。图9-11UML中的多重继承一个链接描述对象间的关系。关联与链接的关系就像类与对象的关系，需要链接是因为对象通常不是孤立的，关联使我们获得这些链接的类型信息。图9-12显示了链接和一个关联的例子。图9-12链接和关联9.3.3行为描述

行为描述用来规定系统的行为和结构。规定操作的行为采用的一种方法是状态机。图9-13表示UML状态，两种状态间的转换用箭头表示。图9-13UML中的状态和转换这些状态机不依赖硬件时钟的操作，一个状态向另一个状态的转换由事件触发。事件是某一种动作，可能来自系统外部，如用户按了一个按钮；也可能来自系统内部，如一个例程完成计算并将结果传送到另一个例程。下面将集中讨论图9-14中显示的用UML定义的三种类型的事件。图9-14UML中的信号、调用和定时器事件考虑一个简单的状态机规则来理解UML状态机的语义。图9-15展示了显示操作的状态机。开始和结束状态是特殊的状态，它有助于组织状态机的流程。状态机中的状态代表了不同的概念性的操作。某些情况下，根据输入或状态中的计算结果，我们采用状态条件转移，其他情况下都无条件转移到下一个状态。条件转移和无条件转移都使用调用事件。将复杂操作分解成几个状态有助于证明需求的步骤，类似于使用子例程来构建代码。图9-15UML中的状态机规格说明有时给出随时间的操作顺序是很有用的，特别是在涉及许多对象时。在这种情况下，可以建立一个顺序图，就像图9-16显示的鼠标单击事件一样。顺序图有时与硬件时序图很相似(虽然时间流在顺序图中是垂直的而在时序图中是水平的)。设计顺序图来显示特定情景或事件的选择，这不便于显示互斥可能性的多寡。图9-16UML中的顺序图 9.4需求分析与规格说明

9.4.1需求分析

创建一个需求文档的目的是使用户和设计者可以有效地交流。设计者应该知道用户期望他们设计什么，而用户应该明白他们将得到什么。

需求有两种类型：功能性需求和非功能性需求。一个功能性需求说明了这个系统必须做什么，例如FFT运算。一个非功能性需求可以是其他属性中的一些性质，包括物理尺寸、价格、功耗、开发周期、可靠性等。一套好的需求分析应该满足以下测试要求：

(1)正确性——需求不能错误地描述用户的要求。正确性还包括应该避免超出需要的需求，需求不应该加上那些不必要的条件。

(2)无二义性——需求文档应该清晰，并且只用一种明确的语言解释。

(3)完整性——所有的需求都应该被包括。

(4)可检验性——应该有一个有效的方法来确保最后的产品满足每一种需求。例如，在不符合“吸引力”定义的情况下，一个想使系统组装吸引人的需求是很难验证的。

(5)一致性——一个需求不能和另一个需求相矛盾。

(6)可修改性——需求文档应结构化，以便在不影响一致性、可检验性等情况下可以被修改以适应变化的需求。

(7)可追踪性——每个需求应满足以下可追踪性：

——可以追踪需求知道每个需求存在的价值。

——可以追踪需求之前创建的文档来理解它们如何与最终的需求相关联。

——可以向前追踪来理解每个需求在实现中如何被满足。

——可以向后追踪以便知道哪一个需求是用户满意的。9.4.2规格说明

1．SDL

使用状态机可以确定UML中的控制。SDL(SystemDescriptiveLanguage，系统描述语言)是一种广泛使用状态机的规格说明语言，这种语言是通信产业为通信协议、电话系统等开发的。如图9-17所示，SDL规格说明包括状态、操作以及状态间有条件的和非条件的转换。SDL是一个面向事件的状态机模型，状态间的转换由内部或外部事件引发。图9-17SDL规格说明语言

2．状态图表

状态图表是一种常用的基于状态的规格说明的方法，它基于一种事件驱动模型建立。状态图表允许状态被组合在一起表示普通的功能。两种基本的组合是OR(或)和AND(与)。图9-18通过用OR状态描述的状态图表与传统的状态转换图的比较演示了一个OR状态的例子。图9-18状态图表中的OR状态图9-19通过与传统状态机模型的比较演示了用状态图表符号表示的AND状态。传统的模型中，状态间有大量的转换，并且一组状态中只有一个入口点和一个出口点。图9-19状态图表中的AND状态

3．AND/OR表

图9-20演示了一个AND/OR表的例子及其所描述的布尔表达式。AND/OR表中的每一行用表达式中的基本变量标记。每一列相当于表达式中的一个AND项。例如，AND项(条件2与非条件3)在第二列中用使条件2为真、条件3为假、条件1忽略来表示，这就相当于AND条件要为真时，必须有条件2为真且条件3为假。我们用这种表来估计一个给定的条件在系统中是否有效。变量的当前状态与表中的元素相比较，如果所有当前变量的值与该列中给定的要求的值相等，则该列的值就为真。当我们期望一个AND/OR表达时，若列中任一值为真，则这个表为真。这个符号表和状态图表最大的不同在于“否”的情况在表中明确地表示了出来。实践证明，这样的表示对在一个规格说明表中寻找问题有很大帮助。图9-20AND/OR表

9.5系统分析与体系结构设计

把一个规格说明变成一种体系结构设计，这对于理解一个复杂系统的整体结构是一种非常有用的方法。

CRC卡方法是帮助分析一个系统结构的一种普遍、实用的方法。由于它支持封装数据和功能，因此特别适用于面向对象的设计。

缩写CRC代表此方法所要确认的以下三个主要项目：

类(Class)——定义了数据和功能的逻辑分组。

责任(Responsibility)——描述类所要做的工作。

协作者(Collaborator)——与给定类相关的其他类。

CRC卡的命名源自人们习惯于将此方法写在标签上，在其空白处填写类的名字、责任、协作者以及其他的相关信息。CRC卡方法的实质是要人们填写这些卡片，讨论并更新卡片内容，直到获得自己满意的结果。图9-21所示为CRC卡的示意图。图9-21CRC卡示意图用CRC卡分析系统时，应该按下列步骤进行：

(1)设计类的初始清单。

(2)书写责任和协作者初始清单。

(3)创建一些使用脚本。

(4)预演脚本。

(5)求精类、责任、协作者。

(6)添加类之间的关系。 9.6质量保证

产品或服务的质量可以用满足其功能的程度来判断。造成产品质量低下的原因有很多，如粗制滥造、元件设计错误、体系结构构思不合理、没有正确理解产品的需求，等等。质量必须作为设计的一部分。质量保证(QA)过程对提交一个令人满意的系统来说是至关重要的，而对质量的追求贯穿于整个设计流程中。本节我们将集中讨论旨在改进最终系统的质量的方法学部分的内容。国际标准化组织(ISO)制定了ISO9000系列质量标准。ISO9000在工业领域中的应用范围十分广泛，包括但不限于嵌入式系统的硬件和软件。针对某一特定产品的质量标准可以制定适应该产品的特殊的、具体的规范，但是涉及范围广泛的标准不可能对工业中的每一领域都面面俱到。所以，ISO9000重在规范产品制造和服务的过程。满足ISO9000的生产过程将对整个组织以及设计和制造过程中的每一步产生影响。可用来验证系统设计并确保质量的技术有许多种，包括手工的和基于工具的。基于工具的验证有助于妥善地管理在复杂设计中产生的大量信息。验证系统设计的技术必须适合整个软件开发过程，这一过程的具体内容将取决于多个因素，包括正在设计产品的类型、要生产的单元的数量和设计允许的时间、公司中业已存在的规则惯例以及其他一些因素。

检测组织软件开发过程质量的一个众所周知的方法是卡内基梅隆大学软件工程研究所提出的能力成熟度评价模型(CMM)。CMM提供了一个判断组织成熟度的模型，该模型将组织的成熟度定义为5个等级。

(1)初始级(Initial)：开发过程的组织工作杂乱无章，缺乏定义良好的软件开发过程。项目的成功完全依赖于个人的努力，与组织自身无关。

(2)可重复级(Repeatable)：提供了跟踪机制，使管理人员可以了解软件开发的费用、调度、正在开发系统与目标相符的程度等。

(3)定义级(Defined)：管理和开发过程均已实现文档化和标准化。所有项目均使用文档化的并且核准了的标准方法。

(4)管理级(Managed)：可对开发过程和产品质量进行详细的测量。

(5)优化级(Optimizing)：CMM的最高级别，利用详细的测量反馈资料来不断地完善、提高组织的软件开发过程。

1．需求验证

验证需求可以采取许多措施来保证客户和起草需求的人相互交流。原型是一个与最终用户沟通的非常有用的工具。与只是用广泛的技术术语向用户描述系统不同的是，原型至少可使客户听到、看到、感受到系统的一些重要方面。当然，原型不可能完成系统的所有功能，因为设计工作还没有做。但是，特殊的用户界面可用于建立原型和用户测试。可以用预先设定的或随机的数据来仿真系统的内部操作。原型有助于最终用户判断许多功能上的和非功能上的需求，如数据显示、操作速度、大小、重量，等等。

2．规格说明验证

用于验证需求的工具和方法如建立原型、规格说明语言和参照已存系统，对验证规格说明的正确性同样有用。审计工具可用于检验一致性、完整性等。使用脚本可帮助设计者完成规格说明的细节工作，并确保其完整性和正确性。在某种情况下，形式化技术(即使用数学证明的设计技术，证明可手工完成或自动完成)可能也很有效。某些复杂系统说明起来可能很简单，但整个时间序