基于模型的代码生成器的系统测式.docx

《基于模型的代码生成器的系统测式.docx》由会员分享，可在线阅读，更多相关《基于模型的代码生成器的系统测式.docx（17页珍藏版）》请在优知文库上搜索。

1、基于模型的系统的测试代码生成程序IngoSturmer,MirkoConrad,HeikoDorr,andPeterPepper,成员，IEEE摘要：不象常见吩咐式程序语言（如C或者ADA）编译器，维护了基于模型的代码生成器生成的构件没有既定的方法存在尽管在形式验证领域取得进展。几种测试方法在工程实践中处于支配地位。这篇文章为运用在基于模型开发的代码生成器描述一个通用和工具独立的测试体系。我们通过测试TargetLink代码生成程序执行的最优化评价我们的方法的有效性。TargetLink代码生成器在基于模型自动化开发中是一个被广泛地接受和困难开发工具。索引术语测试和调试。1绪论汽车的嵌入软件被

2、开发方式已经变更。可执行的模型现在被运用在开发的全部阶段，从起初设计到到实现（基于模型的发展）。用大众流行图形建模语言进行模型设计，象来自MathWorks1的SimUIink/Statcflow。新的方法允许通过所谓的代码生成器干脆从SimUlink和StatefIOW自动生成可控有效的代码，象dSPACE2的TargCtLink或者MathWOrkS3的实时工作室嵌入代码编码器。一个代码生成器本质上是一个编译器，它把一个用图形建模语言表示的源程序翻译成象C或者ADA一样的一个吩咐式语言。代码生成器相当地降低软件实现的努力。也，通过在模型级早期的质量保证获得质量级别可以导致高质量代码，供应代

3、码生成器工作正确。由于这些特征，代码生成器有一个强大工业需求。基于模型代码生成器与传统编译器不同有几个方面。1）目标语言和源语言两者都可执行的。因此，代码生成器的可执行行为能干脆与模型的仿真行为比较。2）模型语言的语义常常不是明确的定义。语义可依靠信息的布局（例，位置的状态）及内部模型设置（例，块参数,数据类型的处理）。所以,语义被嵌入在模拟器的说明算法中4。3）特殊,象被Sinnnink定义数据驱动语言生成器组成一类新的开发工具。代码生成器不能简洁执行逐步翻译从模型分层体系结构到一个抽象的目标语言语法树。相反，他们必需分析数据依靠源于一个适当的计算机序列，这是代码生成器的精髓。在目前，基于模

4、型的代码生成器不是同己制定的C或者ADA那样成熟。代码生成器的技术风险是高的，因为他们D是被一个相当小的开发团队运用和2）面对一个高效率的技术革新引起一个新版本的出现在一个短周期内。因此，一个正式化代码生成器正确性的证据在实际中是不行实行的。因此，通过基于建模工具代码生成器的运用取得生产效率的提高不能完全开采的。代码生成器与手工写代码一样必需用同样昂贵的精力检查，即使惊慌的质量度量已经花费在模型上。这篇论文为基于建模的代码生成器介绍了一种通用、切合实际的的测试方法。该方法大量运用代码生成器的输入和输出是可执行的事实。方法的目的有三点：1）测试案例的系统来历必需在测试包中执行的信念，因此它可以用

5、服务于验证代码生成器。2）测试案例必需能自动产生覆盖高可变的模型。3）测试包必需能执行和自动评价，处理代码生成器的快发布周期。通过确认TargetLink代码生成器执行的优化，我们评价我们测试方法的有效性。这篇论文的剩余部分的结构如下：其次节介绍基于模型的代码生成。第三节描述了代码生成器的优化。第四节支撑一个系统的代码器测试理论线索的概要。第五节通过一个例了描述了系统代码生成器测试方法。第六节介绍了从三个案例获得测试结果第七节探讨了结果和局限性，和通过总结他的贡献和示意将来探讨方面结束论文。codegenerationtoolchain图.1基于模型的代码生成原理.2 .基于模型的代码生成在基

6、于模型的开发中，一个限制算法的实现通过模型的逐步求精来开发，一个所谓的的物理模型起源于软件元件（图L左上）的功能需求说明书，物理模型捕获限制算法和依靠于（连续）输入信号和（内部或外部）事务的限制功能的描述行为。物理模型有代表性地运用浮点算法（FLP）和被用来验证关于在需求说明书规定需求的模型的功能行为。在机动机工程领域，嵌入式系统被定义作电子限制器（EeUs）。由于硬件资源的限制，ECU须要一个很小开销（例，有限或者没有抽象）和能有效的利用系统资源的（高级）编程语言。由于经济缘由，运用在一个ECU的微处理器是更相宜8,16,或者32-位固定点处理器。因此，物理模型不得不被实现专家手工精炼；例如

7、，功能部分被安排到不同的任务和用必需的实现细微环节增加。而且，用在物理模型的FLP算法是适合嵌入式目标处理机（看5具体）的固定（FXP）算法。为了保持FXP数误差精度尽可能低，固定点的数据类型被护展以相宜伸缩信息，2.提炼的结果是实现了的模型。它包括为代码生成须要的全部信息和允许被代码生成器产生的有效C代码的创建。依靠于开发阶段和目的，为开发计算器（主机）生成的代码，在多数状况下，是一个标准的PC（图.1.右），在那种状况下，一个传统的编译者/链结者组合被用作将产生的代码译成可一个可执行的.对于目标硬件一一个典型的评估委员会类似于电子限制单元（EeU）限制-一个所谓交叉编译器被须要。这儿，一个

8、连接器和装入器建业和装入二进制代码到嵌入设备。工具链确定建模工具（编辑器和模拟器），模型到代码的翻译工具（例如，代码生成器，（交叉）编译器，连接器，装入器），和，最终，目标硬件自身组成代码生成器工具链（图.1）。基于模型的代码生成器是一个基于模型开发的主要的优点。在软件实现阶段，一个代码生成器的运用导致一个重大的生产效率改进。个别探讨表明：通过代码生成7软件开发时间的降低达到百分之二十。假如手工确认过程在代码级也能降低，报告说节约达到百分之五十。这与其他用户供应国内信息是一样的。总的来说，与传统手工编码相比，生产效率提高达到50%o3 .代码生成器优化嵌入系统的代码生成常常有资源限制。624因

9、此，就生成有效的代码而言，无论什么时侯可能，优化技术必需被采纳。例如，内存消费和执行速度。传统上，代码优化是通过（叉）编译器翻译源代码成可执行的目标代码来完成。这样标准优化是，例如，死代码消出，不变的传播，环路的解开，从传统编译器说明了解到的（看，例，8）。当运用一个代码生成器，优化已经在最高级表现形式被执行，例如，在中间（图）表现形式3（IR,看图.1.中间），和能运用呈现在模型级的巨大数量信息。一个有代表性基于模型优化，为了创建有效代码模板，企图组合不同模型部分，是块间优化。图.2显示一个图形模形描绘一个ifThen-else控件结构，那里假如A不在间距C2,Cl中，输出E等于输入A。另外

10、，常量值C3被传播到输出E。控件逻辑被用所谓开关块D计算，它的操作如下：开关传播或者是第一个输入A或者是第三个输入E依靠于控件输入B的值（在这个案例中，输出或操作）。假如在控件输入符号是大于或等于一个内部临界值_t,开关传播第一个输入。否则，它传播第三个输入。当一个没有优化的代码生成器翻译图形模式块到块和为每个输出块引入变量，一个优化了代码生成器能翻译模型成一个单独if-thcn-else限制结构：if（ACl）II（AC2）E=A;）elseE=C3;）留意全部表示块输出中间变量已经被消出和逻辑被插入交换条件。作比照，一个块翻译将产生额外的程序代码和，所以，导致一个高RAM消费。由于不同的代

11、码生成器，代码生成器设置，或者优化技术的选择，一个特定的模型结构的实现可以多样化。因此，在一个模型和产生代码之间不同结构可能存在。在代码生成器优化中，四个主要优化/翻译策略的分类引起在模型和代码之间结构差异：1 .重复。代码为每个他的调用者重更实现可复用的模型结构。内联就是这样的一个优化技术。2 .复用。这个优化取一套等价但有区分的模型结构和为了降低程序尺寸用一个单独可复用的元件来实现他们。一个函数调用用不同的参数是一个典型的这样优化技术的例子。复用是与内联相对。3 .简化。模型结构的实现是合并或者丢弃为了得到效率（例，块间优化）或移去无用的部分（例，死路径消退）。4 .增加。额外代码被产生象

12、代码爱护免受一个潜在被O除。在模型和代码之间结构不同将节5.3接着。4代码生成器测试4.1 测试的基本原理测试是一个可执行的测试对象，通过一个有限测试例子，带着发觉错误的意图。测试案例是为了一测试对象关于它的说明可能的输入。假如他们有时间依靠，测试案例的依次叫做测试向量。一个收集或套测试用例是常常称为测试套件。测试能显示出席了错误而不能显示缺席的错误11。因些，主要的挑战在测试是设计错误敏感的测试案例。这个任务最终确定测试的范围和质量。测试是到目前为止唯一的方法，在真实的环境允许动态检测程序的行为。对于基于模型的代码测试，我们将4.4节论证在真实的应用环境进行模型和程序行为比较是多么重要。功能

13、设计测试技术（也叫做黑盒测试技术）和结构设计技术（也称作白盒测试技术）是最突出的测试案例设计方法12。功能测试是基于测试对象的需求说明书和通过测试案例覆盖尽可能多的需求。测试对象被假定是一个黑盒，它的实现细微环节不被测试设计考虑。对比功能测试，结构测试可以保证覆盖每个程序元素。一个常见的结构测试的缺点是不能保证功能的正确。由于这个缘由，一个好的测试策略是应当是一个功能和结构测试的组合。这样的一个功能和结构测试的组合定义为灰盒测试61.这个策略将被应用到代码生成器测试（5.3节和5.4节）6251*-ordertestcaselinker/loadert(Testoutputs图.3.动态代码生

14、成揩测试方法4.2 代码生成器的范围测试为一个“完全的代码生成器测试，单独地验证全部的翻译功能是明显不足够的。一个完全的代码生成器测试应当更多的测试目标的考虑。例，翻译规则的组合，健壮性，算法异样的处理，或者将以前从释放版本知道的漏洞作为重点重测目标。在我们方法常规范围内，对于代码生成器的每个测试目标作为一个特定的测试模块对待。全部的测试模块组成一个相应的代码测试套件。这扁论文焦点在模块测试规则优化，因为优化是在代码生成器翻译中最简洁出错的。但是，即使我们聚焦在代码生成翻译上，技术显示也可适应其它类型翻译。4.3 代码生成器测试案例在第一级，假如无效测试模块被拒绝和有效的测试模块被翻译成“功能

15、等价”代码，代码生成器测试是胜利的。最近的检查显示功能等分估计须要一个二级的考虑。有效模块同代码生成器一样的行为必需用通过/失败确定来比较。为了那个目标，测试模块和被生成代码必需被执行用同样的一套测试套件来比较模块和代码行为(看图.3,左)。因此，一个有效的基于模型的代码器的测试案例通常组成测试模型(第一阶测试案例)同一套相应的这个模型的测试向量一样(其次阶测试案例)。由于这个测试模型可能处理内部状态，它不是充分的执行它用一个简洁的测试案例(例，常量值)，更准确地讲，其次阶测试案例必需是时间依靠测试向量,(测试向量i(t),看图3.左工相应的模型和代码执行(测试输出o(t),看图.3.右)的测

16、试结果又是有时间标记的向量。4.4 动态代码生成器测试和功能等效翻译过程的正确性，例如，无论如何模型的语义己经被保存下来，是确定所谓背背测试了。在背背测试中，模型测试输出和来自他们用标识测试向量i(t)执行结果的输出进行比较。假如模型和代码显示同样测试输出，关于这套测试向量他们考虑被执行正确性在下面，在主机PC上模型上模拟叫做模型环绕模拟(MIL),在主机PC代码执行叫做软件环绕模拟(SIL),和在目标处理器代码执行叫做处理器环绕模拟(PlL)。有时间测试依靠的测试输出MIL,SIL,和PIL是。MIL(t),oSIL(t),和OPlL(t)(看图.3,右)。全部的三个输出是通过背靠背方式成对地比较。请留意，全部三个开发构件，即，在主机PC模型，在主机PC的上生成的代码，并