3.3.2/ G ´ENERATION DE TESTS´ A PARTIR D` ’UN AUTOMATE A PILE`
Il existe dans la litt ´erature plusieurs m ´ethodes de g ´en ´eration de tests `a partir d’un PA. Nous en pr ´esentons quelques unes ici.
3.3.2.1/ G ´ENERATION DE TESTS´ A PARTIR DE GRAMMAIRES`
Les grammaires alg ´ebriques sont des structures fondamentales en informatique. Elles sont un mod `ele tr `es utilis ´e, notamment dans les compilateurs. Il existe plusieurs al- gorithmes classiques qui permettent la transformation d’un automate `a pile en une grammaire alg ´ebrique (par exemple [Sip96]). Produire des mots `a partir d’une gram- maire, selon diff ´erents crit `eres de couverture ou d’autres contraintes, est n ´ecessaire dans de nombreux domaines tels que l’analyse/compilation, la g ´en ´eration des cas de test, la bioinformatique, etc. Les auteurs de [XZC11] proposent un outil de g ´en ´eration de tests `a partir d’une grammaire donn ´ee. La g ´en ´eration de tests est bas ´ee sur des algorithmes et des techniques de couverture de r `egles, telle que celle qui est d ´efinie dans [Pur72][ZW09][AV08].
3.3.2.2/ G ´ENERATION AL´ EATOIRE´ -UNIFORME D’ARBRES DE DERIVATION´
Les auteurs de [FZC94][FS09] proposent des techniques combinatoires pour g ´en ´erer al ´eatoirement et uniform ´ement des arbres d’ex ´ecution `a partir de grammaires alg ´ebriques. Plusieurs outils existants comme GenRgenS [PTD06] ou le module CS de Mupad [DDZ98] peuvent ˆetre utilis ´es `a cet effet.
3.3.2.3/ M ´ETHODE DE TEST ALEATOIRE D´ ’UN PROGRAMME RECURSIF´
Une technique qui permet de combiner la g ´en ´eration al ´eatoire avec un crit `ere de couverture, `a partir d’une grammaire alg ´ebrique ou d’un automate `a pile est d ´efinie dans [DHK13][DHKM14a]. Cette approche de g ´en ´eration des tests abstraits consiste `a :
1. g ´en ´erer le graphe de flot de contr ˆole du programme r ´ecursif,
3. g ´en ´erer une grammaire alg ´ebrique `a partir de l’automate `a pile,
4. g ´en ´erer al ´eatoirement et uniform ´ement des arbres de d ´erivation de la grammaire
alg ´ebrique,
5. traduire ces arbres de d ´erivation en chemins dans le programme,
6. calculer des valeurs d’entr ´ee du programme r ´ecursif, afin que les ex ´ecutions corre-
spondent aux chemins g ´en ´er ´es.
3.4/
G ´
ENERATION DE TESTS´
A PARTIR DE`
TAIO
Il existe de nombreux travaux sur la v ´erification des automates tempo-
ris ´es [ACH94][DOY94][DY95][BER94]. Certains outils [DOTY96][BLL+98] ont ´et ´e d ´evelopp ´es `a cet effet. Mais d’autres diff ´erentes m ´ethodes de g ´en ´eration de tests `a partir des syst `emes temporis ´es ont ´et ´e propos ´ees. Nous pr ´esentons dans cette partie des m ´ethodes formelles de test des syst `emes temps-r ´eel bas ´ees sur des TAIO.
3.4.1/ TEST DE CONFORMITE´ A PARTIR D` ’UNTAIO
Plusieurs relations de conformit ´e ont ´et ´e introduites dans la litt ´erature pour les syst `emes temporis ´es. On trouve par exemple comme bisimulation temporis ´ee [SVD01], re- lation d’inclusion de traces [HLM+08a][KJM04], relation de conformit ´e relativis ´ee rtioco [LMN05], relation de conformit ´e vtioco [BB04], relation de conformit ´e ti-
oco [KT09], etc. Plusieurs m ´ethodes de test de conformit ´e `a partir d’un TAIO sont propos ´ees [KT09][Fou02].
Dans cette partie, nous allons d ´ecrire les ´el ´ements permettant de d ´efinir la relation tioco pour des TAIO. Le principe est similaire `a ioco en consid ´erant l’ ´ecoulement du temps comme une sortie. Il existe deux types de tests consid ´er ´es pour le test de conformit ´e qui sont : les tests analogiques pour lequel le temps est dense et est mesur ´e par une horloge exacte, et les tests digitaux [HMP92] o `u le temps est mesur ´e par une horloge p ´eriodique.
3.4.1.1/ RELATION DE CONFORMITE´ tioco
Dans cette partie, on d ´efinit la relation de conformit ´e tioco [KT09] pour les TAIO. Cette relation est une extension de la relation de conformit ´e ioco de Tretmans [Tre99] pour les automates non temporis ´es avec entr ´ees/sorties. tioco est une adaptation pour les syst `emes temporis ´es de ioco qui consid `ere l’ ´ecoulement du temps comme une sortie ob- servable. La principale diff ´erence est que ioco prend en compte la notion de quiescence, contrairement `a tioco [KT09] o `u les d ´elais sont explicitement sp ´ecifi ´es. Les hypoth `eses sont que la sp ´ecification est un TAIO non bloquant et l’impl ´ementation est un TAIO non bloquant et complet en entr ´ee. Pour pr ´esenter la relation de conformit ´e tioco pour un TAIO T = hL, l0, Σin∪Σout∪ {τ}, X, ∆, Fi, on a besoin de d´efinir les notations suivantes : soit
ρ ∈ RT (Σin∪Σout) une trace d’ex ´ecution :
• T after ρ = {s ∈ ST | ∃ρ0.(ρ0 ∈ RT (Σ
τ) ∧ sT0 →ρ0 s ∧ PΣ(ρ0) = ρ)} est l’ensemble d’ ´etats de T atteignables par une trace ρ0 dont la projection PΣ(ρ0) sur les actions observables et contr ˆolables est ρ.
• ObsTTraces(T ) = {PΣ(ρ) | ρ ∈ RT (Στ) ∧ sT0 →ρ} est l’ensemble des traces tempo- ris ´ees observables pour un TAIO T .
• elapse(s)= {t | t > 0∧∃ρ.(ρ ∈ RT({τ})∧Time(ρ) = t∧s →ρ)} est l’ensemble des d ´elais qui peuvent s’ ´ecouler `a partir de l’ ´etat s sans qu’une action ne soit observ ´ee. • out(s)= {a ∈ Σout | s →a} ∪ elapse(s) est l’ensemble des actions de sortie ou d ´elais
qui peuvent ˆetre observ ´es `a partir de l’ ´etat s.
D ´efinition 14 : tioco [KT09] - Relation de conformit ´e tioco
Soit T = hL, l0, Στ, X, ∆, Fi une sp´ecification et I = hLI, lI0, ΣIτ, XI, ∆I, FIi une
impl ´ementation de T . Formellement, I est conforme `a T not ´e I tioco T ssi ∀ρ.(ρ ∈ ObsT T races(T ) =⇒ out(I after ρ) ⊆ out(T after ρ)).
Elle signifie que l’impl ´ementation I est conforme `a la sp ´ecification T si et seulement si apr `es toute trace de T , chaque action de sortie ou d ´elai de I est sp ´ecifi ´e par T .
Exemple 3.4.1. La Fig. 3.8.(a) pr ´esente un exemple d’une sp ´ecification T o `uΣin= {A} et
Σout = {B}. La sp´ecification T est non bloquante. Les Figures 3.8.(b), 3.8.(c), 3.8.(d)
et 3.8.(e) pr ´esentent des exemples d’impl ´ementations appel ´ees I1, I2, I3 et I4. Ces
impl ´ementations sont non-bloquantes. On suppose que I1, I2, I3 et I4 sont compl `etes
en entr ´ees. La sp ´ecification T doit envoyer B au plus tard 6 unit ´es de temps et au plus t ˆot 2 unit ´es de temps apr `es la r ´eception de A. L’impl ´ementation I1 est conforme `a T parce
qu’elle produit B entre 3 et 5 unit ´es de temps apr `es avoir rec¸u A. L’impl ´ementation I2n’est
pas conforme `a T parce que, par exemple, out(I2 a f ter ?A ) = R+ * out(T a f ter ?A ) = {B} ∪ [0, 6]. L’impl ´ementation I3 n’est pas conforme `a T parce que, par exemple, out(I3
a f ter?A ) = {C} ∪ [0, 5] * out(T a f ter ?A) = {B} ∪ [0, 6]. L’impl´ementation I4 est conforme
`a T bien que l’action ?D ne soit pas sp ´ecifi ´ee dans T : la relation ne porte que sur les sorties et les d ´elais, c’est `a dire ce qui est observable de l’ext ´erieur. Comme la trace ?D n’appartient pas `a obsT T races(T ), I4est conforme.
l0 l1 l2
(a).T ?A, x 6 3, lazy, {x} !B, 2 6 x 6 6, delayable, {x}
l0 l1 l2
(b).I1 ?A, x 6 3, lazy, {x} !B, 3 6 x 6 5, delayable, {x}
l0 l1
(c).I2 ?A, x 6 3, lazy, {x}
l0 l1 l2
(d).I3 ?A, x 6 3, lazy, {x} !C, 3 6 x 6 5, delayable, {x}
l0 l1 l2
(e).I4 ?D, x 6 6, lazy, {x} !B, 3 6 x 6 9, delayable, {x}