在早期的设计阶段,开发者可开发纯粹的行为模型,以阐明并定义软件的详细要求。 : c9 b4 k# ?# i+ [2 Z & O+ l: v4 y4 t. X/ L0 n1 c) Y 虽然此类模型已经具备了基本解决方案的轮廓,但是它们依然独立于目标平台。这些目标独立的行为模型将用于设计验证和早期的需求确认。8 ]$ k G( Q, E- B9 [; z c
0 O/ t! `, f3 B& s/ K 用于捕获关键需求、在仿真中展示正确行为以及展示对高层需求可追溯性的模型通常被称为“可执行规范”。5 Q1 a$ E$ R3 ~, ~" J5 N
$ O5 T( ?' q- q; X/ p! ? 对可执行规范的进一步开发和具体实现可产生代表最终实现的模型的定义。这就是用于产品代码生成的模型。通常,这些模型会对代码生成做优化;它将从数据类型、目标架构以及要求的代码风格。所有这些变更需要一个验证过程,确保产品代码生成模型中引入的变更不会改变软件的行为。确认生产代码生成模型以及生成代码的正确行为的测试为代码验证。 把验证分布在设计验证和代码验证阶段允许我们更早地开始验证工作,更多的关注在测试上和更短的时间去修复在测试中检测到的错误。在本文的其余部分,我将介绍两个设计验证方法: / Q& `! N/ X! Y0 k: H0 ^ 5 G4 Y/ w2 c' T! p1 X; x6 Q% G ·模型在环测试# L# R) q+ c$ r2 Y: b
·软件在环测试 G2 @* B) B8 T3 D, a+ ?
) Q3 R( ]: F; e( t( H8 a9 d
以及用于代码验证的两个方法:; l& y0 T2 Z* P9 r8 g4 K" J) Y
9 K4 _+ D; s" c) @' U0 M0 j* J! v
·处理器在环测试 * z7 z# q1 }/ U9 d% ?, f
·硬件在环测试 9 F* {; v9 q. v # s* C# D7 x' I6 e0 ~% G2 设计验证 4 e7 g/ y- W' J ( a% K- a. C2 f; b" K! v7 x: t# F 设计验证的主要目的是确认所有关键要求和设计概念是否已正确体现在设计模型中。' s" [! G1 j4 O+ l
6 |( y- j! x9 s" T+ t# D: r ·模型在环测试 1 t) x8 P& Z* ^9 C' E$ e- M( i/ A
与“静态”的书面设计不同,可在仿真过程中评估可执行规范。通常,通过改变一组模型参数或输入信号,或通过查看输出结果或模型的响应,来完成这一操作。依据模型执行的仿真顺序也称为模型在环测试。 7 M5 K, N# O9 q2 c5 q6 b9 Q 0 x* p8 ]! h' F: f) k1 h1 G 模型在环测试的测试数据可来自测试矢量数据库,或来自实际系统的模型,在后一种情况下,我们讨论闭环控制系统。 * i: _! J1 o3 _3 ]7 t X ( K, S$ S+ p& n. l 可执行规范通常不仅仅包含功能设计模型和软件逻辑,还包括设备和环境模型、高层需求的链接以及其他文件。它通常还包括用于自动化仿真结果评估的验证数据。 模型在环测试的结果可用于验证软件行为是否正确,并确认开发流程的初始需求。通过仿真收集的信息会成为代码验证的基准。 ; R/ K. I- s1 T3 Z# _- @7 o- E 5 \& t$ B; A3 B4 R ·软件在环 (SIL) 2 @$ P! @- P' N" N3 Q! K5 {: D( T0 N) ^$ [3 k V, x$ G; \
在许多情况下,在目标环境中部署软件之前,确保所设计的系统的软件组件能够按预期运行,这一点非常重要。 # ~* T( r% W0 [$ J/ t3 n8 D9 J4 l5 d9 Q- ~; i) V: z5 X