Limites des approches existantes dans la prise en compte des besoins en validation 56

des tests. Comme nous l’avons discuté en 3.4, ce type de critère caractrise l’exploration qui est faite de l’espace d’état du point de vue de son étendue et de son uniformité, mais ne mesure que ce type de besoins. Par ailleurs, les auteurs exposent qu’il permet de caractériser l’amélioration de la dispersion ap- portée par un nouvel état visité à un ensemble existant, mais ne permet pas de comparer deux ensembles d’états quelconques.

Dans les travaux d’Esposito et al. [24] que nous avons présentés en3.3.2.2, le critère d’adéquation est classiquement paramétré par les dimensions de l’espace d’état (qui est supposé être un produit d’in- tervalles deR), ainsi que par le pas de la grille qui est superposé à cet espace d’état. La variation du pas de cette grille conduit à l’instantiation d’un critère différent et par suite à l’estimation d’un autre valeur de l’adéquation d’un jeu de test.

Intuitivement, plus le pas est grand, plus favorable sera l’estimation de l’adéquation. Ce critère d’adé- quation peut donc traduire des besoins de validation portant sur “la densité d’états à visiter” (un pas plus grand correspondant à des besoins plus faciles à satisfaire). La formalisation par les automates hybrides que nous faisons des propriétés induit l’existence demodesqui s’interprètent comme différents modes d’opération du système spécifié. Le critère d’Esposito peut être réutilisé en le définissantau niveau de l’espace d’état de chaque mode, puis en aggrégeant les mesures pour en dériver une adéquation globale.

Ceci permet, en utilisant un pas de grille distinct pour chaque mode de trduire des besoins de validation propres à chacun de ces modes.

Sur l’exemple du chauffage écologique que nous avons présenté au chapitre 3, si on dispose d’un

1ces états sont calculés et peuvent être exportés à la ligne 36 de l’algorithme4.1p.51et à la ligne 14 de sa sous-fonction présentée par l’algorithme4.2

ensemble d’étatsT observés lors des tests, on peut le partitionner en plusieurs ensemblesTwaitContract, Tsteady, etc ... correspondant à l’espace d’état de chaque mode. Dans chacun de ces modes, on utilise le critère d’Esposito avec un pas de grille spécifique (qui est un vecteur, avec une valeur associée à chacune des variables de l’automate).

Ce critère conserve plusieurs défauts cependant, liés au fait que cette mesure est destinée comme la première à caractériser la dispersion uniforme des états visités plutôt que le remplissage d’un ensemble d’objectifs. Il ne prend pas en compte les besoins en validation dans notre exemple, qui ne sont pas uniformes. Les états tels que (C−T) > ∆crit par exemple sont interdits ; par conséquent il n’est pas pertinent que le critère les prenne en compte : ils ne pourront jamais être visités par un système conforme.

De plus, supposons que le système ait davantage besoin d’être exercé lorsqueC etT sont proches (puisque le comportement décrit par la spécification dans ce cas de figure est relativement complexe), et moins testé lorsque leur écart est important (parce que cela correspond à une situation de grande chaleur où le chauffage n’est pas sensé être actif, et où le testeur sait que le risque de défaillance est faible). Une grille uniforme au niveau de l’espace d’état de chaque mode ne permet pas de faire de telles distinctions.

Enfin dans certains modes des variables peuvent être indéfinies. Ainsi dans l’étatwaitContract, la variable timeRemaining est indéfinie, alors qu’elle est définie dans le mode f ollowRamp. Pour l’inclure dans le critère d’un de ces deux modes seulement, il faudrait que la grille ne comporte pas toujours les mêmes variables. Ceci n’est pas prévu dans la proposition originale d’Esposito.

5.1.3 Utilisation d’un profil opérationnel pour caractériser des objectifs

Pour traiter ces questions, nous proposons de définir explicitement les besoins de validation à un niveau plus fin que le mode et d’associer uneimportanceexplicite à chacun des éléments de la spécifi- cation. Nous nous inspirons pour cela de la notion deprofil opérationnelintroduite par Musa [48] (nous emploierons indifféremment les termes de profil opérationnel ou de profil par la suite).

Nous avons présenté le concept de profil opérationnel en3.2.4comme une décomposition hiérar- chique des cas d’utilisation d’un système, au sein de laquelle chaque élément se voit affecter une fré- quence d’utilisation. Ceci permet d’expliciter les connaissances et l’expertise disponibles sur le système, et les utiliser dans le processus de validation. Le type de spécification que nous considérons pour les sys- tèmes hybrides possède pour ses éléments de haut niveau une décomposition hirérarchique en automates puis en modes qui permet de proposer une définition de profil semblable à celle de Musa. En revanche l’espace d’état de chaque mode d’un automate est infini dans le cas général. A ce niveau de décomposi- tion, nous associerons donc une fonction dite d’importanceou dedensitéqui associe individuellement à chaque état une importance.

Pour représenter les besoins de validation dans le profil, le testeur définit quantitativement l’impor- tance de chaque élément de la spécification (propriété, mode ou état) en lui affectant une valeur dansR₊. 0signifie qu’aucune exigence de validation n’est applicable à l’élément considéré. une valeur strictement positive indique que l’élément est plus ou moins important pour le critère en fonction de sa valeur. L’in- terprétation de ces données numériques sera détaillée dans la prochaine section ; nous nous limitons ici à illustrer la structure d’un profil, définie comme suit (et illustrée en Fig.5.1) :

waitContract

invalidContract validContract

steady followRamp

followRamp

loc = followRamp newContract = ...

newD = ...

T = ...

Pout = ...

....

Profil opérationnel hybride

Propriété P spécifiant l'exemple du système de chauffage écologique

Mode followRamp Un état x du mode followRamp

imp (P)_P Elément d'exemple

Autre propriété Autre mode

Autre état

imp (P,followRamp)_M

ω (x)P,followRamp Valeur associée par

le profil

Propriété P

FIG. 5.1 – Composition d’un profil opérationnel hybride

Soit une spécification S composée d’un ensemble d’IOHA² {A₁. . .An}. Un profil opérationnel applicable àSest un tupleP = (impP, impM)composé des éléments suivants :

– imp_P est une fonction qui associe à tout automateAune importanceimp_P(A)

– impM est une fonction qui associe à tout automate A et un de ses modes m une importance impM(A, m)

– imp_E est une fonction qui associe à tout modemd’un automateAune fonction de densitéω_A,m définie sur l’espace d’état dem à valeurs dansR^|V

A′|

+ , oùV_A^′ est l’ensembles des variables deA privé deloc.

On impose en outre que la somme des importances associées aux différents automates, ainsi que les sommes des importances des modes pour chacun de ces automates additionnées valent1. LorsqueAet mse déduisent du contexte, on noteraωà la place deω_A,m.