
[信息与通信]第9章系统设计技术.ppt
88页9第9章 系统设计技术 第9章系统设计技术 9.1 引言引言9.2 设计流程设计流程9.3 系统设计的形式化方法系统设计的形式化方法9.4 需求分析与规格说明需求分析与规格说明9.5 系统分析与体系结构设计系统分析与体系结构设计9.6 质量保证质量保证思考与练习题思考与练习题 9第9章 系统设计技术 9.1 引引 言言 多数真正的嵌入式系统的设计实际上是很复杂的,其功能要求非常详细,且必须遵循许多其他要求,如成本、性能、功耗、质量、开发周期等大多数嵌入式系统的复杂程度使得无法由个人设计和完成,而必须在一个开发团队中相互协作来完成这样就使得开发人员必须遵循一定的设计过程,明确分工,相互交流并能达成一致 设计过程还会受到内在和外在因素的影响而变化外在影响包括如消费者的变化、需求的变化、产品的变化以及元器件的变化等内在影响包括如工作的改进、人员的变动等 9第9章 系统设计技术 9.2 设设 计计 流流 程程 9.2.1 9.2.1 嵌入式系统的开发过程嵌入式系统的开发过程 嵌入式系统是专用的计算机系统,运行在特定的目标环境中,需要同时满足功能和性能等方面的要求。
在嵌入式系统的开发过程中,要考虑到实时性、可靠性、稳定性、可维护性、可升级、可配置、易于操作、接口规范、抗干扰、物理尺寸、重量、功耗、成本、开发周期等多种因素良好的设计方法在嵌入式系统的开发过程中是必不可少的首先,好的方法有助于规划一个清晰的工作进度,避免遗漏重要的工作,例如性能的优化和可靠性测试对于一个合格的嵌入式产品而言是不可或缺的其次,采用有效的方法可以将整个复杂的开发过程分解成若干可以控制的步骤,通过现代一些先进计算机辅助设计工具的辅助,我们可以按部就班、有条不紊地完成整个项目 9第9章 系统设计技术 图9-1 嵌入式系统开发的一般过程 9第9章 系统设计技术 1 1.系统定义阶段.系统定义阶段 系统定义阶段需要确定系统开发最终实现的目标、实现目标的可行性、实现目标应采用的策略、估计完成系统开发所需的资源和成本、制定工程进度安排计划这一阶段的工作主要包括了系统定义、可行性分析、需求分析和规格说明四方面的内容其中,需求分析是指从用户那里搜集系统的非形式描述以此为基础经过进一步提炼得到系统的规格说明,并以此来设计系统的体系结构和系统构件 9第9章 系统设计技术 通常,用户仅了解和关心实际使用问题和需要具备的功能,但是往往不能完整、准确地表达这种需求,更不清楚怎样利用计算机去实现所需的功能。
为了对系统进行准确无误地定义,就要求开发人员和用户之间充分交流,开发人员需要详细考察,最终得出经用户确认的、明确的系统实现逻辑模型 需求可分为功能部分和非功能部分非功能性需求包括了性能、价格、物理尺寸和重量、功耗等方面的因素 9第9章 系统设计技术 确认需求最好的方法是建立模型模型可以使用原始数据来模拟功能,并可以在计算机上运行模型还应让用户了解系统是如何工作的,以及用户如何与系统交互通常,系统的非功能模型可以让用户了解系统的特性 对一个大型的系统进行系统定义和需求分析是一件繁琐的工作,可以从先获取相对少量的、简单的信息入手表9-1演示了一个简单的需求表格的样本 9第9章 系统设计技术 表表9-1 需求表格样本需求表格样本 9第9章 系统设计技术 * 名称——给项目取一个好的名称,可以使设计目的更加明确,也便于交流、讨论时使用 * 目的——用最精炼的语言来描述清楚系统需要满足的需求 * 输入和输出——系统的输入和输出包含了大量的细节,如数据类型,包括模拟信号、数字信号、机械输入等;数据特性,包括周期性或非周期性数据、用户的输入、数据位数等;I/O设备类型,包括按键、ADC、显示器等。
* 功能——功能的描述可以从对输入到输出的分析中得出,如当系统接收到输入时,执行哪些动作?用户通过界面输入的数据如何对该功能产生影响?不同功能之间如何相互作用? 9第9章 系统设计技术 * 性能——系统控制物理设备或者处理外界输入的数据都需要花费一定的时间在大部分情况下,嵌入式系统在计算时间上都有要求,因此从系统定义和需求分析开始,这种性能的要求就必须明确,并在执行过程中加以认真考虑,以便随时检查系统能否满足其性能要求系统的处理速度通常又是系统实用性和成本的主要决定因素在大多数情况下,软件的性能在很大程度上决定了系统的性能 9第9章 系统设计技术 * 生产成本——产品的成本会影响其价格成本包含两个主要部分:生成成本,包括购买构件以及组装费用等;不可再生的工程成本,包括人力成本以及设计费用等生产成本主要包括的是硬件成本通过对硬件成本的估计,可以大略估计产品形成后的价格;或者,基于产品最终的粗略价格来计算构建系统可以使用的硬件构件,因为价格最终会影响系统的体系结构 * 功耗——由电池供电的系统必须对功耗问题认真考虑而系统的功耗需要在设计开始时就要至少有一个粗略的了解通常,基于这种了解可以使开发者决定系统是采用电池供电还是采用市电。
9第9章 系统设计技术 * 物理尺寸和重量——产品的物理尺寸和重量因使用领域的不同而不同例如,对飞机上的电子设备,其重量应严格限制又如,手持设备对系统的物理尺寸和重量都有严格限制对系统的物理尺寸和重量有一定的了解有助于系统体系结构的设计 需求分析需要对其内部一致性进行检查规格说明可以使设计者花费最少的时间和精力创建一个工作系统规格说明应该足够明晰,以便别人可以验证它是否符合系统需求并且完全满足客户的期望;亦不能有歧义,设计者应知道什么是他们需要构造的设计者可能碰到各种不同类型的由于不明确的规格说明而导致的问题如果在某个特定的状况下的某些特性在规格说明中不明确,那么设计者就可能设计出错误的功能9第9章 系统设计技术 2 2.总体设计阶段.总体设计阶段 总体设计是设计的第一步,其目的是描述系统如何实现由系统定义规定的那些功能它需要解决嵌入式系统的总体构架,从功能实现上对软硬件进行划分;在此基础上,选定处理器和基本接口器件;根据系统的复杂程度确定是否使用操作系统,以及选择哪种操作系统;此外,还需要选择系统的开发环境 9第9章 系统设计技术 本阶段应提供系统总体设计报告,推荐一个基本的软硬件配置方案,包括系统中各模块间的接口关系。
确立总体方案时,要使用系统流程图或其他工具,描述每一种可能的系统组成,估计每一种方案的成本和效益,最终使总体方案建立在充分权衡各种方案利弊的基础上总体设计中对系统体系结构的描述必须同时满足功能上和非功能上的需求一般地,功能约束在构建系统总体框图时集中考虑,而非功能约束在构建硬件和软件体系结构时考虑在构建体系结构时对非功能约束的估算部分来源于经验,而建造一个简化的模型往往有助于做出更精确的估算 9第9章 系统设计技术 3 3.构件设计阶段.构件设计阶段 构件通常包括硬件和软件两部分构件设计使得构件、体系结构和规格说明相一致 一些构件是标准的,可以直接使用,如CPU和存储器如果采用标准数据库,我们就可以用标准例程对该数据库进行访问这些数据库中的数据不仅使用预定义的格式,而且被高度压缩以节省存储空间在这些访问函数中使用标准软件不仅节约设计时间,而且有可能较快地实现像数据解压缩这样的专用函数 9第9章 系统设计技术 在大部分情况下,我们必须自己设计一些构件,如使用集成电路设计PCB、做大量定制的编程等在设计期间,我们经常会利用一些计算机辅助设计工具和开发平台,并且对每个构件都需要进行功能和性能等方面的测试。
嵌入式系统的设计还要求有较高的设计技能,在设计软件时要非常小心地读/写存储器以减小功耗由于存储器访问是主要的功耗来源,因此存储器事务必须精心安排以避免多次读取同样的数据 9第9章 系统设计技术 4 4.系统集成阶段.系统集成阶段 系统集成阶段的工作包括将测试完成的软件系统装入制作好的硬件系统中,进行系统综合测试,验证系统功能是否能够准确无误地实现,各方面指标是否符合设计要求,最后将正确无误的软件固化在目标硬件中在系统集成阶段通常会发现错误按阶段构建系统并正确运行选好的测试,可以更容易地找出这些错误如果每次只对一部分模块排错,则可以更容易地发现和识别较简单的错误也只有在早期修正这些简单的错误,才能发现那些只有在系统高负荷时才能确定的、较复杂、较含混的错误因此,我们必须确保在体系结构和构件设计阶段尽可能容易地按阶段组装系统和相对独立地测试系统功能 9第9章 系统设计技术 9.2.2 9.2.2 设计流程设计流程 设计流程是指在系统设计期间应遵遁的一系列步骤,其中的一些步骤可以由工具软件完成,如编译程序或者CAD系统;其他的步骤只可用手工完成本节将讲述设计流程的基本特性 1 1.瀑布模型.瀑布模型 图9-2演示了瀑布模型,这是一个为软件开发过程提出的模型。
9第9章 系统设计技术 图9-2 软件开发的瀑布模型 9第9章 系统设计技术 瀑布开发模型由五个主要阶段构成:需求分析,确定目标系统的基本特点;体系结构设计,将系统的功能分解为主要的构件;编码,编写程序段并将其集成;测试,检测错误;维护,修改软件以适应环境变化,并改正错误,进行系统升级各阶段的工作和信息总是由高级的抽象到较详细的设计步骤单向流动(只有少量的到高一级的反馈) 自顶向下的设计可以使得在早期设计阶段就对要完成的系统有很好的预见,但大多数的设计者并没有完全遵循这种自顶向下的设计顺序很多的设计项目要进行试验和更改,就需要有从下到上的回溯瀑布模型对于理解其他设计流程对它的改进是很重要的 9第9章 系统设计技术 图9-3 软件设计的螺旋模型 2 2.螺旋模型.螺旋模型图9-3演示了螺旋模型 9第9章 系统设计技术 3.逐步求精.逐步求精 图9-4 逐步求精开发模型 9第9章 系统设计技术 4 4.分层设计流程.分层设计流程 许多复杂的嵌入式系统自身是由更多的小设计组成的完整的系统可能需要有效的软件构件、专用的集成电路(ASIC)等,而且这些部件反过来可能由尚需设计的更小的部件组成。
从最抽象的完整系统设计到为个别部件的设计,设计流程随着系统中的抽象层次而变化流程的实现阶段从规格说明到测试,本身是一个完整的流程在一个大项目中,每一个流程可能会由单独的人或小组来完成,每个组必须依靠其他组的结果各个分组从上级小组获得要求,同时上级小组依靠各个分组的设计质量和测试性能充分交流在这样的大项目中非常重要其设计流程如图9-5所示 9第9章 系统设计技术 图9-5 嵌入式系统分层设计工作流程 9第9章 系统设计技术 5 5.并行工程.并行工程 当众多的设计者一起设计一个大系统时,非常容易偏离完整的设计流程,导致每个设计者对自己在设计流程中的角色产生狭隘的看法并行工程试图采用一种更宽的方法,使整个流程优化对于并行工程而言,缩减设计时间是一个重要的目标,它为设计流程的很多方面提供了捷径,例如,可靠性、性能、功耗等特别需要指出的是,要从并行工程中获得最多收益通常需要删除设计和制造之间的隔阂为了获得最优结果,需要注意以下几点: (1) 交叉功能组应包括来自不同学科的成员,包括制造业、硬件/软件设计和市场营销等 9第9章 系统设计技术 (2) 并行产品实现过程的活动是并行工程的中心。
同时做几件事,例如同时设计几个不同的子系统,减少设计时间是关键性的 (3) 递增的信息共享和使用将有助于减少并行产品的实现导致意外的可能性 一旦新的信息可用,它就被共享并且集成到设计中交叉功能组对于及时和高效的信息共享是很重要的 (4) 综合的工程管理保证有人对整个工程负责,而且这种职责决不能在工程的某一方面一旦完成就放弃 (5) 提供商尽早地和不间断地参与有助于充分利用提供商的能力 (6) 客户尽早地和不间断地关注有助于确保产品能最好地满足其需要 9第9章 系统设计技术 6 6.其他.其他 软件工程的方法直接影响到设计流程目前,软件开发过程结合了面向对象的方法和第四代工具该方法针对嵌入式系统还在不断完善 在基于面向对象的开发过程中,开发组成员可以遵循并行过程的方法,并发地设计组件例如,一个小组设计设备驱动程序,另一个小组设计错误处理程序,还有一个小组设计应用程序 第四代软件工具能够根据较高级的设计规范生成代码,例如,自动报表生成、自动高级图形生成、创建数据库查询以及在创建网站时自动生成HTML代码等9第9章 系统设计技术 9.3 系统设计的形式化方法系统设计的形式化方法 9.3.1 UML简介简介 面向对象的规格说明可以看成互补的两个方面: (1) 面向对象的规格说明允许用精确地模拟真实世界的对象和它们之间的交互方式来描述系统。
(2) 面向对象的规格说明提供一个基本的原语集,可以用特殊属性来描述系统,而不管系统构件和真实世界对象的关系如何 9第9章 系统设计技术 1 1..UMLUML基本元素基本元素 UML最基本的元素是对象和类,对象是类的实例另外,对象和类之间可能存在着各种不同的关系类具有属性和行为活跃类是能实现独立控制线程的类对象可能有被赋予特定的值的属性匿名对象属于某一个类但没有标识名程序包是系统的组织单元,可能包括类定义、对象等状态在状态图中描述行为物理处理器是硬件部件构件是实现一组接口的系统的物理组成部分 我们常常发现,在一个对象或类中会多次用到一些元素的特定组合我们可以对这些组合命名,这样的一个定义在UML中称为模板(stereotype) 9第9章 系统设计技术 表表9-2 UML基本元素基本元素 9第9章 系统设计技术 图9- 6 UML基本元素 9第9章 系统设计技术 2 2..UMLUML图图 UML的基本元素可以通过多种方式组合到一起,使用图形组可以完成以下建模任务:软件可视化、数据设计、算法设计、软件设计、软件说明书、软件开发过程、工业过程等表9-3列出了几种基本的UML图。
图9-7给出了这些图的示例 9第9章 系统设计技术 表表9-3 UML 图图 9第9章 系统设计技术 图9-7 UML图示例 9第9章 系统设计技术 图9-7 UML图示例 9第9章 系统设计技术 9.3.2 9.3.2 结构描述结构描述 结构描述用于定义系统的基本构件面向对象设计的首要构件自然是对象一个对象包括定义其内部状态的属性集当使用程序设计语言实现时,这些属性通常是一种数据结构中的变量或常量有时,我们会在属性名后加上类型声明,但不总是对属性指定类型图9-8说明了一个用UML符号表示的描述显示器(如CRT屏幕)的对象折角页状图标中的文字是注释,它不对应于系统中的对象在这里,属性是保存显示器内容的像素数组对象有两个特征:它有唯一的标识名以及它是一个类的成员 9第9章 系统设计技术 图9-8 UML表示法中的对象 9第9章 系统设计技术 1 1.类.类 类是类型定义的一种形式——从同一个类导出的所有对象尽管其属性可能有不同的值,但它们都有相同的性质类定义了对象可能有的属性,也定义了对象与外界交互的操作 使用编程语言,操作将变成用来控制对象的一小段代码。
图9-9所示是Display类的UML描述Display类定义了对象中的pixels属性,当对象将一个类实例化时,对象就有了自己的存储空间,以便同一个类的不同对象有自己的属性值其他的类能检查和修改类的属性 9第9章 系统设计技术 图9-9 UML表示法中的类 9第9章 系统设计技术 2 2.选择合适的界面.选择合适的界面 显然,选择界面是面向对象设计中非常重要的决策正确的界面必须提供访问对象状态的方法(因为属性不能直接访问)和更新状态的方法对象的界面必须通用,以充分利用它的性能然而,过分通用会使对象庞大而缓慢大而复杂的界面同样会使定义类的工作对于设计者来说难以理解和使用 对象和类之间存在若干种类型的关系:关联——发生在彼此通信但没有从属关系的对象间聚集——描述由较小的对象组成的复杂对象组合——是一种聚集类型,其中所有者不允许访问构件对象泛化——允许我们通过其他类定义类 9第9章 系统设计技术 3 3.类和对象的软件实现.类和对象的软件实现 因为UML用于设计的很多阶段,所以它不是一种程序设计语言因此,它的概念有时看起来很抽象它有助于在程序设计语言中使用类和对象前理解其抽象概念。
首先,我们用直接支持面向对象技术的C++语言实现Display类和d1对象下面是Display类的定义: 9第9章 系统设计技术 class Display { pixels: pixeltype[IMAX, JMAX]; public: Display( ) { } /*一个创建类的结构体的实例*/ pixeltype pixel(int i, int j) { return pixels[i,j]; /*为清楚起见无限制地检查*/ } void set_pixel(pixeltype val, int i, int j) { pixels[i,j] = val; }}; 9第9章 系统设计技术 在C++中,操作被称为方法它包括参数列表、返回类型和方法的代码C++代码比UML规格说明包含更多的细节,这是因为我们使用C++实现类,而UML描述仅仅抓住系统的本质特征Display类的例化为对象d1: Display d1; d1的例化在内存中建立了为d1保存像素值的数据结构例如,类中定义的方法能调用d1,以控制它的像素值: apixel = d1.pixel(0,0); /* 获取pixel [0,0]的值 */ object.method()的表示法说明正在运行特定对象的方法。
确保特定方法可以在给定对象上使用是一种类型检查操作 9第9章 系统设计技术 在非面向对象语言(如C语言)中实现类和对象具有一定的挑战性,但是仍能做得相当好下面是一种描述Display类的属性和操作的方法: /* 这些操作都在一个二维pixels数组上执行 */ pixel pixelval(pixel *px, int i, int j) { return px[i,j]; } void set_pixel(pixel *px, pixeltype val, int i, int j) { px[i,j] = val; } 9第9章 系统设计技术 这里我们选择不定义像素数组的显式类型,因为它是一个基本二维数组;在其他情况下,可用结构体定义对象的属性我们定义了两个函数来实现操作,注意,与C++代码相比这些函数有额外的参数,第一个参数是我们要操作的数组在面向对象语言中,像object.method()这种形式的符号用来运行特定对象的操作当用C语言实现这个类时,我们必须自己写代码将方法的操作运用于代表对象的数据集这意味着,在C语言的实现中,通常将对象的所有数据保存在一个简单的结构中,可以是数组也可以是单个结构。
要求程序员为对象的每一个函数调用按正确的顺序,提供正确的数据元素是很浪费时间且容易出错的 9第9章 系统设计技术 下面是d1对象的示例: pixel d1_pixels[IMAX, JMAX]; 这行代码只例化了d1的数据结构,我们已经给出了操作的代码为了实现标准C函数的调用,我们应用d1的属性编写如下代码: apixel = pixelval(d1_pixel, 0, 0); /* 从d1数组获得pixel [0, 0] */ 9第9章 系统设计技术 4 4.派生类.派生类 像大多数面向对象语言一样,UML允许根据其他的类来定义一个类如图9-10所示的例子中,派生了两种特殊的显示器类型,一个是BW_display,描述黑白显示器,不需要增加新的属性和操作,但可以规定其以每像素一位的方式工作;另一个是Color_map_display,使用称为颜色映射表的图形设备,允许用户即使在每像素只有很少几位时,也可以从大量现有颜色中选择这个类定义了color_map属性,该属性决定如何把像素值映射到显示颜色一个派生类从它的基类继承所有的属性和操作这里,Display类是其他两个类的基类。
派生类定义为包括其基类的所有属性 9第9章 系统设计技术 这是传递关系——如果Display类是从其他类派生来的,那么BW_display类和Color_map_display类同样会继承Display类的基类的所有属性和操作继承有两个目的:首先,它允许我们简洁地描述一个与其他类共享某些特征的类;更重要的是,它取得类之间的这些关系并文档化当我们要改变其中的任何类时,类结构的知识有助于确定这种改变的涉及面例如,这种改变究竟是只影响Color_map_display对象还是影响所有Display对象? 9第9章 系统设计技术 图9-10 UML中派生类作为泛化的一种形式 9第9章 系统设计技术 5 5.泛化和继承.泛化和继承 UML认为继承是泛化的一种形式泛化关系在UML图中用空心箭头显示BW_display和Color_map_display都是Display的特定版本,因此Display泛化了它的两个版本UML允许多重继承,即一个类继承不止一个基类(大部分面向对象编程语言支持多重继承)图9-11所示是一个多重继承的例子,为了简便起见,我们忽略类的属性和操作的细节在此,将Display类处理声音的Speaker类合并建立了Multimedia_display类,该类继承两个基类Display和Speaker的所有属性和操作。
多重继承会导致属性集和操作的大小迅速增加,因此须小心使用 9第9章 系统设计技术 图9-11 UML中的多重继承 9第9章 系统设计技术 一个链接描述对象间的关系,关联与链接的关系就像类与对象的关系,需要链接是因为对象通常不是孤立的,关联使我们获得这些链接的类型信息图9-12显示了链接和一个关联的例子当考虑系统中的实际对象时,有一个跟踪当前活动消息数目(例子中有两个)和指向活动消息的消息集这时,链接定义了contains关系当泛化到类时,我们在消息集类和消息类之间定义一个关联,关联被画成标有关联名称contains的一条线消息类一端的零和其他数字表示消息集类可能包括零个或多个消息对象有时,可能要将数据附加到链接本身,我们可以通过附加保存关联数据的像类那样的方框到关联的边上来在关联中指明这一点 9第9章 系统设计技术 图9-12 链接和关联 9第9章 系统设计技术 9.3.3 9.3.3 行为描述行为描述 行为描述用来规定系统的行为和结构规定操作的行为采用的一种方法是状态机图9-13表示UML状态,两种状态间的转换用箭头表示 图9-13 UML中的状态和转换 9第9章 系统设计技术 这些状态机不依赖硬件时钟的操作,一个状态向另一个状态改变由事件触发。
事件是某一种动作,可能来自系统外部,如用户按了一个按钮;也可能来自系统内部,如一个例程完成计算并将结果传送到另一个例程下面将集中讨论图9-14中显示的用UML定义的三种类型的事件 9第9章 系统设计技术 图9-14 UML中的信号、调用和定时器事件 9第9章 系统设计技术 信号是异步发生的,在UML中用标记为<
条件转移和无条件转移都使用调用事件将复杂操作分解成几个状态有助于证明需求的步骤,类似于使用子例程来构建代码 9第9章 系统设计技术 图9-15 UML中的状态机规格说明 9第9章 系统设计技术 有时给出随时间的操作顺序是很有用的,特别是在涉及到许多对象时在这种情况下,可以建立一个顺序图,就像图9-16显示的鼠标单击事件一样顺序图有时与硬件时序图相似(虽然时间流在顺序图中是垂直的而在时序图中是水平的)设计顺序图来显示特定情景或事件的选择——这不便于显示互斥可能性的多寡在这个案例中,操作序列表明了鼠标单击菜单区域时发生的事情要处理图9-16顶部的三个对象在每个对象的下面扩展出生命线,虚线表示对象的生存期这里,所有对象在整个流程中保持存活状态,但在其他情况下,对象有可能随处理过程创建或撤消生命线边上的方框表示序列中的控制焦点,即对象什么时候是活动处理的这里,鼠标对象仅在创建mouse_click事件时是活动的;显示器对象一直是活动的,它用调用事件实现调用菜单对象两次:一次决定所选菜单项,一次执行实际的菜单调用find_region( )调用在显示器对象内部,因此它在图中不以一个事件出现。
9第9章 系统设计技术 图9-16 UML中的顺序图 9第9章 系统设计技术 9.4 需求分析与规格说明需求分析与规格说明9.4.1 9.4.1 需求分析需求分析 创建一个需求文档的目的是使用户和设计者可以有效地交流设计者应该知道用户期望他们设计什么,而用户应该明白他们将得到什么 需求有两种类型:功能性需求和非功能性需求一个功能性需求说明了这个系统必须做什么,例如FFT运算一个非功能性需求可以是其他属性中的一些,包括物理尺寸、价格、功耗、开发周期、可靠性等 9第9章 系统设计技术 一套好的需求分析应该满足以下的测试要求: (1) 正确性——需求不能错误地描述用户的要求正确性还包括应该避免超出需要的需求,需求不应该加上那些不必要的条件 (2) 无二义性——需求文档应该清晰,并且只用一种明确的语言解释 (3) 完整性——所有的需求都应该被包括 (4) 可检验性——应该有一个有效的方法来确保最后的产品满足每一种需求例如,在不符合“吸引力”定义的情况下,一个想使系统组装吸引人的需求是很难验证的 9第9章 系统设计技术 (5) 一致性——一个需求不能和另一个需求相矛盾。
(6) 可修改性——需求文档应结构化,以便在不影响一致性、可检验性等情况下可以被修改以适应变化的需求 (7) 可追踪性——每个需求应满足以下可追踪性: ——可以追踪需求知道每个需求存在的价值 ——可以追踪需求之前创建的文档来理解它们如何和最终的需求相关联 ——可以向前追踪来理解每个需求在实现中如何被满足 ——可以向后追踪以便知道哪一个需求是用户满意的 9第9章 系统设计技术 9.4.2 9.4.2 规格说明规格说明 1 1..SDLSDL 使用状态机可以确定UML中的控制SDL(System Descriptive Language,系统描述语言)是一种广泛使用状态机的规格说明语言,这种语言是通信产业为通信协议、系统等开发的如图9-17所示,SDL规格说明包括状态、操作以及状态间有条件的和非条件的转换SDL是一个面向事件的状态机模型,状态间的转换由内部或外部事件引发 9第9章 系统设计技术 图9-17 SDL规格说明语言 9第9章 系统设计技术 2 2.状态图表.状态图表 状态图表是一种常用的基于状态的规格说明的方法,基于一种事件驱动模型建立状态图表允许状态被组合在一起表示普通的功能,两种基本的组合是OR(或)和AND(与)。
图9-18通过用OR状态描述的状态图表与传统的状态转换图的比较演示了一个OR状态的例子该状态机描述了当s1、s2、s3收到输入i2时,机器将从s1、s2、s3的任一状态转换到状态s4状态图表也可以通过在s1、s2、s3周围标出OR状态来表示这种特性s123是OR状态的名字,在状态上方的小方块中给出从OR状态s123出来的惟一转换表明了状态机处于s123包括的任意一个状态时接收到i2输入都会进入状态s4OR状态不但允许成员状态间的相互转换,还允许内部状态间的相互转换(例如从s1到s3、从s2到s3)OR状态仅仅是表明与这些状态相关的转换的一种工具 9第9章 系统设计技术 图9-18 状态图表中的OR状态 9第9章 系统设计技术 图9-19通过与传统状态机模型的比较演示了用状态图表符号表示的AND状态传统的模型中,状态间有大量的转换,并且一组状态中只有一个入口点和一个出口点 9第9章 系统设计技术 图9-19 状态图表中的AND状态 9第9章 系统设计技术 传统状态机中状态的名字显示了它们与AND状态部件的联系这样,s1-3状态相当于状态图表的状态机sa部件处于s1状态且sb部件处于s3状态,依此类推。
在传统方法中,我们能跳出这一组状态,进入s5状态,且仅当我们处于状态s2-4时接收r,在AND状态图中相当于sa处于s2状态、sb处于s4状态且状态机在这种组合状态下接收到r输入尽管传统图模型与状态图表模型描述了同样的行为,然而在当每个部件有两种状态并且状态间存在关系时,状态图表看起来要简单一些 9第9章 系统设计技术 3 3..AND/ORAND/OR表表 图9-20演示了一个AND/OR表的例子及其所描述的布尔表达式AND/OR表中的行用表达式中的基本变量标记每一列相当于表达式中的一个AND项例如,AND项(条件2与非条件3)在第二列中用使条件2为真、条件3为假、条件1忽略来表示这就相当于AND条件要为真时,必须有条件2为真且条件3为假我们用这种表来估计一个给定的条件在系统中是否有效变量的当前状态与表中的元素相比较,如果所有当前变量的值与该列中给定的要求的值相等,则该列的值就为真当我们期望一个AND/OR表达时,若列中任一值为真,则这个表为真这个符号表和状态图表最大的不同在于“否”的情况在表中明确地表示了出来,实践证明,这样的表示对在一个规格说明表中寻找问题有很大帮助 9第9章 系统设计技术 图9-20 AND/OR表9第9章 系统设计技术 9.5 系统分析与体系结构设计系统分析与体系结构设计 把一个规格说明变成一种体系结构设计,这对于理解一个复杂系统的整体结构是一种非常有用的方法。
CRC卡方法是帮助分析一个系统结构的一种普遍、实用的方法由于它支持封装数据和功能,因此特别适用于面向对象的设计 9第9章 系统设计技术 缩写CRC代表此方法所要确认的以下三个主要项目: * 类(Class)——定义了数据和功能的逻辑分组 * 责任(Responsibility)——描述类所要做的工作 * 协作者(Collaborator)——与给定类相关的其他类 CRC卡的命名源自人们习惯于将此方法写在标签上,在其空白处填写类的名字、责任、协作者以及其他的相关信息CRC卡方法的实质是要人们填写这些卡片,讨论并更新卡片内容,直到获得自己满意的结果图9-21所示为CRC卡的示意图 9第9章 系统设计技术 图9-21 CRC卡示意图 9第9章 系统设计技术 对于计算机系统设计而言,CRC卡方法似乎是一种比较原始的方法然而,它有一些重要的优点首先,它很容易让非计算机专业人员来创建CRC卡在系统设计中,获得领域专家的忠告是非常重要的,这些专家可能是擅长汽车电子设备方面的汽车设计人员,也可能是从事PDA设计的人类遗传因子研究方面的权威人士CRC卡方法很简便,所以它对非计算机领域的专家使用此方法并不产生影响,而且还允许你收集他们的输入信息。
其次,通过鼓励领域专家分组工作和分析情况,可以很好地帮助计算机专家进行工作在CRC卡方法中运用的预排过程对于明确设计范围和决定系统的哪一部分未被充分地理解是非常有用的在基于工具的设计和编码中这种简便方法很有价值而软件工程工具对自动创建CRC卡非常有效 9第9章 系统设计技术 用CRC卡分析系统时,应该按下列步骤进行:(1) 设计类的初始清单2) 书写责任和协作者初始清单3) 创建一些使用脚本 (4) 预演脚本 (5) 求精类、责任、协作者 (6) 添加类之间的关系 9第9章 系统设计技术 9.6 质质 量量 保保 证证 国际标准化组织(ISO)制定了ISO 9000系列质量标准ISO 9000在工业领域中的应用范围十分广泛,包括但不限于嵌入式系统的硬件和软件针对某一特定产品的质量标准可以制定适应该产品的特殊的、具体的规范,但是涉及范围广泛的标准不可能对工业中的每一领域都面面俱到所以,ISO 9000重在产品制造和服务的过程满足ISO 9000的生产过程将对整个组织以及设计和制造过程中的每一步产生影响9第9章 系统设计技术 检测组织软件开发过程质量的一个众所周知的方法是卡内基梅隆大学软件工程研究所提出的能力成熟度评价模型(CMM)。
CMM提供了一个判断组织成熟度的模型,CMM将组织的成熟度定义为5个等级 (1) 初始级(Initial):开发过程的组织工作杂乱无章,缺乏定义良好的软件开发过程项目的成功完全依赖于个人的努力,与组织自身无关 (2) 可重复级(Repeatable):这一级别提供了跟踪机制,使管理人员可以了解软件开发的费用、调度、正在开发系统与目标相符的程度等 9第9章 系统设计技术 (3) 定义级(Defined):管理和开发过程均已实现文档化和标准化所有项目均使用文档化的并且核准了的标准方法 (4) 管理级(Managed):这一级别可对开发过程和产品质量进行详细的测量 (5) 优化级(Optimizing):CMM的最高级别,利用详细的测量反馈资料来不断地完善提高组织的软件开发过程 9第9章 系统设计技术 1 1.需求验证.需求验证 验证需求可以采取许多措施来保证客户和起草需求的人相互交流原型是一个与最终用户沟通的非常有用的工具,与只是用广泛的技术术语向用户描述系统不同的是,原型至少可使客户听到、看到、感受到系统的一些重要方面当然,原型不可能完成系统的所有功能,因为设计工作还没有做。
但是,特殊的用户界面可用于建立原型和用户测试可以用预先设定的或随机的数据来仿真系统的内部操作原型有助于最终用户判断许多功能上的和非功能上的需求,如数据显示、操作速度、大小、重量,等等 9第9章 系统设计技术 2 2.规格说明验证.规格说明验证 用于验证需求的工具和方法如建立原型、规格说明语言和参照已存系统,对验证规格说明的正确性同样有用审计工具可用于检验一致性、完整性等使用脚本可帮助设计者完成规格说明的细节工作,并确保其完整性和正确性在某种情况下,形式化技术(即使用数学证明的设计技术,证明可手工完成或自动完成)可能也很有效某些复杂系统说明起来可能很简单,但整个时间序列的行为却错综复杂,自动证明过程对此特别有用 9第9章 系统设计技术 设计评审是所有质量保证开发过程中的至关重要的组成部分,是在设计阶段早期发现错误的简单、低成本的方法通过设计评审会议,开发小组成员对设计工作进行讨论,并评审系统某个组成部分如何工作也可以运用设计评审提高软件实现的质量,并使以后的改动更加容易实现 在设计评审会议前,设计小组准备好描述将被评审的系统组成部分的一系列文档,包括代码清单、流程图、规格说明等,并将文档事先分发给评审小组的其他人员;设计评审负责人协调开会时间、分发资料等。
9第9章 系统设计技术 设计评审会议期间,设计评审负责人确保会议顺利进行,记录员进行会议情况记录该系统组成部分的设计者提交设计成果从上向下的提交顺序较好,先提交需求和界面描述,然后提交组成部分的整体结构及其细节,最后是测试策略参与者查看所有细化程度的所有类型的问题,通常所涉及的问题包括:设计小组提交的规格说明与整个系统的规格说明是否一致,设计小组是否有解释上的错误,该系统组成部分的内部体系结构工作是否正确及测试策略是否充分,等等 9第9章 系统设计技术 设计评审记录员所做的记录用于评审会议的后续处理设计小组应该改正错误并处理与会者所关注的问题同时,设计小组还要记下他们所做的工作设计评审负责人与设计小组进行沟通,以确保设计评审中提出的问题得到了修改,并将修改结果交给设计评审参与者9第9章 系统设计技术 最终通过测量正在开发系统的错误率并利用统计结果,不仅可以帮助我们确定针对某一个系统正确的测试工作量,而且还可以利用在一个项目中得到的知识预测新项目的哪些地方可能出现错误设计过程的测量也提供了准确的信息,帮助我们更好地理解一项软件项目的研究发现,在设定的软件例子中46%的错误源于对问题的错误理解、交流不畅以及解决问题的技术知识的不充分等,而只有38%的错误与更先进的工具和其他技术方法有关。
另一项研究结果表明,许多错误是由开发过程中存在的高层问题引入的,如功能设计不完善以及糟糕的文档等另外,由于对发现问题的不恰当修改也会为排错过程引入少量新的错误 9第9章 系统设计技术 思考与练习题思考与练习题 1.简要描述需求和规格说明之间的差异 2.简要描述规格说明和体系结构之间的差异 3.在设计方法学的哪一个阶段确定使用CPU的类型? 4.在设计方法学的哪一个阶段选择编程语言? 5.在设计方法学的哪一个阶段针对功能正确性来测试设计? 6.开发一个状态图,定义一次呼叫中的基本活动,包括摘机、拨号、接通、通话、挂机和结束呼叫在可能的时候使用AND和OR状态 7.开发一个UML图,描述一个图形用户接口,使该设计模型既可用于PDA,又可用于机顶盒 。












