Vers une approche mixte de validation de logiciels synchrones : preuve, test, animation Ioannis Parissis Laboratoire Logiciels, Systèmes et Réseaux - Institut IMAG BP 53 38041 Grenoble Cedex 9 France Ioannis.Parissis@imag.fr Résumé Cet article se place dans le cadre des méthodes formelles et les outils de spécification, de programmation et de validation des logiciels synchrones à l aide du langage LUSTRE. Nous avons étendu l environnement de validation de ces logiciels en lui adjoignant des outils d animation de spécifications et de test. Plus précisément, nous proposons des techniques de construction automatique de simulateurs aléatoires des spécifications du logiciel. La simulation de la spécification de l environnement externe constitue un moyen de test aléatoire du logiciel. Une variante de ce type de test, le test des propriétés de sûreté, favorise les comportements de l environnement capables de mettre en évidence des violations de ces propriétés. La spécification de ces dernières peut elle-même être animée au moyen d un simulateur. Enfin, une technique de test structurel s appuyant sur le réseau d opérateurs associé à un programme LUSTRE complète la panoplie d outils de validation proposés. 1 Introduction Un logiciel réactif est qualifié de synchrone si sa réaction à ses entrées est instantanée ou, d une manière plus pratique, s il est assez rapide pour prendre en compte toute variation significative de son environnement. Cette hypothèse, dite de synchronisme, est à l origine de l approche synchrone [1] qui a connu un grand essor depuis une dizaine d années, en particulier grâce à l apparition de langages qui lui sont propres, tels que LUSTRE, ESTEREL et SIGNAL. Ces langages disposent de compilateurs produisant un code très efficace du point de vue du temps d exécution. De plus, la sémantique de ces langages étant définie de manière rigoureuse, ils peuvent servir de support à la spécification formelle et à la preuve de programmes [2]. Cet article porte plus particulièrement sur le langage synchrone LUSTRE [3]. Conçu au Laboratoire de Génie Informatique de l IMAG, LUSTRE a été l objet de plusieurs travaux de recherche portant sur sa compilation [4] et sur son utilisation à des fins de vérification [5] [6]. Poursuivant la voie ouverte par [7], ces travaux ont mis en évidence que LUSTRE peut servir à la fois de langage de programmation et de logique temporelle du passé. Il est ainsi utilisable pour l expression de certaines propriétés que doit satisfaire le logiciel, dites de sûreté, qui expriment l absence de comportements particulièrement indésirables. Dans ces conditions, l outil LESAR [6] permet de prouver automatiquement qu un programme LUSTRE satisfait une propriété de sûreté. Cet outil construit un modèle fini du programme (un automate) qui est exhaustivement parcouru afin de montrer que la propriété est satisfaite dans tous ses états ( model-checking ). Les propriétés de sûreté sont en général des relations simples entre les signaux d entrée et de sortie du logiciel. De ce fait, les modèles manipulés par la preuve restent souvent d une taille raisonnable. Toutefois, il n est pas rare que la preuve se heurte au problème classique des techniques de ce type : l explosion du nombre d états des modèles. En effet, ce nombre devient prohibitif au fur et à mesure que la complexité et la taille du programme et des propriétés à vérifier augmentent. La manipulation symbolique de modèles apporte parfois une solution à ce problème en comprimant la représentation des ensembles d états, mais, en contrepartie, elle rend les traitements plus longs (voire impossibles).
Quelle que soit la technique utilisée, la preuve de programmes LUSTRE vise exclusivement à montrer la satisfaction des propriétés considérées mais elle ne permet pas d affirmer que le logiciel répond réellement à nos attentes et ceci au moins pour deux raisons : L absence de validation des spécifications : les propriétés de sûreté peuvent être insuffisantes ou fausses. En cas d échec de la preuve, il peut être difficile de décider si nous sommes en présence d un défaut du logiciel ou d un défaut dans l expression de ses propriétés. Réciproquement, une preuve réussie ne montre que la satisfaction de propriétés dont on n a aucun moyen d assurer la pertinence. Ce point de vue est conforté par la définition donnée dans [8] : une défaillance se définit par rapport à la fonction du système, et non par rapport à sa spécification. La preuve s intéresse uniquement aux propriétés de sûreté du logiciel. Or, certains défauts du logiciel n ont pas d impact sur la préservation de ces propriétés et passeront, de ce fait, inaperçus. Notons, enfin, que si un manque de ressources physiques empêche la preuve d aboutir, on ne peut rien conclure sur les chances du logiciel de satisfaire les propriétés. Pour toutes ces raisons, nous nous sommes intéressés à d autres moyens de validation et, plus précisément, à la définition de techniques permettant d animer les spécifications (afin de les valider) et de tester le logiciel (afin de détecter des défauts dans son implantation). Il s agit d introduire ainsi dans le processus de validation, d une part, des moyens aidant les concepteurs de logiciels synchrones à développer des spécifications avant la preuve et, d autre part, des techniques de validation complémentaires à cette dernière. Ces techniques sont entièrement automatiques et compatibles avec le processus de preuve, puisqu elles s appuient sur les mêmes spécifications que ce dernier. Ainsi, aucun effort de spécification supplémentaire n est demandé. De plus, elles sont formellement définies sur des modèles analogues à ceux utilisés pour la preuve. Toutefois, elles font intervenir de manière significative l observation par un être humain : on pourrait de ce fait les qualifier de semi-formelles. La suite de l article est organisée en deux parties. Le paragraphe 2 expose rapidement le principe de spécification en LUSTRE de logiciels synchrones tel qu il a été établi par les travaux sur la preuve. Ce principe est illustré sur un exemple de logiciel synchrone. Le paragraphe 3 présente les techniques d animation et de test que nous proposons et suggère une méthode de validation mixte s appuyant à la fois sur la preuve et sur le test mettant ainsi en évidence les apports des techniques proposées ainsi que leur complémentarité avec la preuve. 2 Spécification et vérification de logiciels synchrones 2.1 Principe de spécification Les travaux sur la preuve de programmes LUSTRE [6] ont mis en évidence un principe de description de logiciels synchrones par trois types de spécifications : Une spécification fonctionnelle décrivant au moyen d un nœud LUSTRE le comportement du logiciel en définissant le calcul exact des sorties du logiciel à partir de ses entrées. Une spécification de l environnement du logiciel, formée d un ensemble de propriétés invariantes que satisfait l environnement externe. Une spécification des propriétés de sûreté, composée de propriétés invariantes exprimant l absence de comportements dangereux du logiciel. Toutes ces spécifications peuvent être exprimées en LUSTRE. En effet, les opérateurs temporels les plus couramment utilisés pour l expression des propriétés de sûreté et des propriétés de l environnement s expriment sous forme de nœuds LUSTRE. Par exemple, l opérateur always_from_to(a, B, C) exprime le fait que la condition A a été continuellement vérifiée entre les deux dernières occurrences successives des conditions B et C tandis que l opérateur once_from_to(a, B, C) exprime le fait que la condition A a été vérifiée au moins une fois dans ce même intervalle [5].
monter stop descendre Moteur cabine requête[noétage] dessus[noétage] étage[noétage] dessous[noétage] portes_ouvertes portes_fermées Moteur portes allumer_intérieur[noétage] appel_descente[noétage] appel_montée[noétage] allumer_haut[noétage] fermer_portes ouvrir_portes allumer_bas[noétage] Figure 1: L ascenseur 2.2 Exemple : spécification d un logiciel de contrôle d ascenseur Considérons un logiciel réactif contrôlant un ascenseur d un immeuble de trois étages. L ascenseur, présenté dans la figure 1, comporte une cabine à ouverture et fermeture de portes automatique (commandées par les signaux ouvrir_portes et fermer_portes) se déplaçant dans sa cage de la manière habituelle. Les portes de la cabine sont munies de capteurs permettant au logiciel de connaître à tout moment leur état au moyen de deux signaux booléens, portes_ouvertes et portes_fermées. Trois capteurs par étage dessus, étage et dessous informent le logiciel de la position de la cabine. En particulier, le signal étage[noétage] est actif quand la cabine est arrêtée à l étage noétage. Les boutons de demande de déplacement de la cabine envoient au logiciel, au moment où ils sont actionnés, les signaux appel_montée[noétage], appel_descente[noétage] et requête[noétage]. Le moteur de la cabine est commandé par les signaux stop, monter et descendre. Enfin, les signaux allumer_intérieur[noétage], allumer_haut[noétage] et allumer_bas[noétage], servent à allumer les voyants lumineux des boutons. Le rôle du logiciel est d envoyer les commandes appropriées afin de satisfaire les requêtes des passagers ainsi que d assurer l allumage cohérent des voyants lumineux. La représentation en LUSTRE des signaux dessus, étage, dessous, appel_montée, appel_descente, allumer_haut, allumer_bas, allumer_intérieur et requête, se fait au moyen de tableaux 1 booléens de longueur quatre (d indice variant de 0, pour le rez-de-chaussée, à 3, pour le troisième étage), les signaux portes_ouvertes, portes_fermées, ouvrir_portes, fermer_portes, monter, descendre, stop étant représentés par des simples variables booléennes. Nous supposons que l environnement (i.e. les indications des capteurs) évolue à une vitesse permettant la prise en compte par le logiciel de tous les événements externes. Ceci est une interprétation pragmatique de l hypothèse de synchronisme dont la validité est nécessaire afin qu un logiciel synchrone puisse être utilisé pour cette application. 2.2.1 Spécification de l environnement Nous nous contentons de donner un petit nombre de contraintes d environnement associées à l ascenseur (une liste détaillée des contraintes est fournie dans [9]) : 1 Notons que les tableaux en LUSTRE sont une facilité uniquement syntaxique : lors de la compilation d un nœud, une variable est associée à chaque élément du tableau.
1. Les portes ne peuvent pas être simultanément ouvertes et fermées : not (portes_ouvertes and portes_fermées) 2. L état des portes ne change pas spontanément. En particulier, seule une commande appropriée du logiciel peut provoquer un tel changement d état : always_from_to(portes_fermées, portes_fermées, pre ouvrir_portes) et de manière similaire : always_from_to(portes_ouvertes, portes_ouvertes, pre fermer_portes) 2.2.2 Spécification des propriétés de sûreté Nous présentons d abord deux propriétés qui garantissent la sécurité des passagers : 1. Le logiciel ne doit jamais tenter de déplacer la cabine quand ses portes sont ouvertes et, inversement, il ne doit jamais tenter d ouvrir les portes si la cabine n est pas arrêtée à un étage : Implies(monter or descendre, portes_fermées) and Implies(ouvrir_portes, OR(4, étage)) 2. Le logiciel doit envoyer au moins une fois un signal d ouverture de portes entre l arrivée de la cabine à un étage et son nouveau départ. De plus, il ne doit pas ordonner le départ d un étage de la cabine si ses portes n ont pas été ouvertes au moins une fois depuis son arrivée à cet étage. Ainsi, un passager ne se trouve jamais bloqué dans la cabine : once_from_to(ouvrir_portes, front(or(4, étage)), not OR(4, étage)) and once_from_to(portes_ouvertes, front(or(4, étage)), monter or descendre) Les propriétés suivantes n ont pas de conséquences directes sur la sécurité des passagers mais excluent des comportements manifestement anormaux du logiciel. 3. Un seul des signaux monter, stop et descendre peut être vrai à un instant donné : #(monter, stop, descendre) 4. Un seul des signaux ouvrir_portes et fermer_portes peut être vrai à un instant donné : #(ouvrir_portes, fermer_portes) 2.3 Principe de vérification par la preuve La possibilité d utiliser LUSTRE comme une logique temporelle permet de prouver simplement la validité de ces propriétés dans un programme P. Il suffit pour cela de construire un nouveau programme P' incluant à la fois P, les propriétés de sûreté qu il doit vérifier et les hypothèses sur son environnement. L unique sortie booléenne de P est la conjonction des propriétés de sûreté. La preuve consiste alors à vérifier que quel que soit le comportement de P son unique sortie s vaut vrai. Le processus de preuve réalisé par l outil LESAR [6] transforme P en un automate d états finis. Dans ce modèle, l unique sortie du programme est fonction de l état et de la valeur des variables d entrée courants. Le modèle est ensuite exhaustivement parcouru suivant deux méthodes, communément appelées en avant et en arrière. La vérification en avant consiste à explorer de manière exhaustive les transitions du modèle depuis l état initial et à mémoriser l ensemble des états accessibles ainsi que les transitions permettant d y accéder. Pour chaque état q accédé depuis l état q pour une valeur des variables d entrée e, le triplet (q, e, q ) est mémorisé. Il suffit alors de vérifier que la valeur de la sortie de P est vraie pour tous les triplets (q, e, q ) ainsi mémorisés. L inconvénient de cette approche est que, si le nombre d états du modèle est élevé, l ensemble de triplets à parcourir devient prohibitif. Une amélioration peut être apportée par les techniques symboliques de représentation qui décrivent le modèle d un programme et les ensembles d états manipulés par des fonctions booléennes. La manipulation de ces fonctions est largement facilitée quand elles sont codées par des graphes de décision binaires (BDD : Binary Decision Diagrams ) [10]. Cette structure permet une représentation canonique des fonctions et une implantation efficace des opérateurs booléens. Ainsi, les ensembles d états manipulés peuvent être plus importants.
La méthode de vérification en arrière repose sur l application au programme P d un algorithme de génération de modèle minimal [11]. En quelques mots, il consiste à calculer les états prédécesseurs successifs des états violant les propriétés de sûreté. Il suffit alors de vérifier qu à la fin de ce calcul l état initial ne figure pas parmi ces états prédécesseurs. Quelle que soit la méthode de vérification utilisée, les violations des propriétés de sûreté dues à des valeurs d entrées ne respectant pas la spécification de l environnement (introduite dans le programme à vérifier au moyen de l opérateur assert) sont identifiées et ignorées. 3 Test et animation de spécifications 3.1 Présentation générale Le test est un moyen de validation qui, contrairement à la preuve, a pour but de mettre en évidence les défauts du logiciel. Comme nous l avons expliqué au paragraphe 2, un logiciel synchrone est décrit au moyen de trois spécifications. L objectif du travail présenté ici [9] est la définition de moyens de tester ces trois spécifications. Toutefois, nous utilisons le terme test pour les techniques servant à la validation de l implantation d un logiciel synchrone, préférant celui d animation pour celles ayant pour objet la validation de la spécification d environnement et des propriétés de sûreté. En effet, dans le cadre de la validation d un programme exécutable, la difficulté réside d une part dans le choix des données d entrée à fournir à ce programme afin de mieux détecter ses éventuels défauts (suivant un ensemble de règles, habituellement appelé critère de sélection ) et, d autre part, dans la détection de la manifestation des défaillances (problème de l oracle ). Ces activités génération de données de test et construction d oracles sont traditionnellement considérées comme relevant du test. En revanche, le non déterminisme de la spécification de l environnement et des propriétés de sûreté nécessite la définition d un modèle d exécution spécifique permettant d animer ces spécifications en vue de leur validation (d où le terme animation ). Nous avons d abord étudié la mise en œuvre du type de test le plus élémentaire, c est à dire le test aléatoire. Ce type de test est, en général, d une grande simplicité car il revient à tirer des valeurs dans des ensembles prédéfinis. Il s avère qu il n en est pas ainsi pour les logiciels synchrones. Dans ce cas, les données de test doivent être choisies parmi celles satisfaisant la spécification de l environnement. Ce type de génération de données de test est réalisé par la première technique que nous proposons, la simulation aléatoire de l environnement. Une telle simulation aléatoire peut être utile pour plusieurs raisons : Le logiciel étant testé avec des données valides, les défaillances dues à un comportement incohérent de l environnement et non à un défaut du logiciel ne perturberont pas le processus de test. C est un moyen simple de simuler le comportement de l environnement afin de valider sa spécification (utilisée éventuellement ensuite pour la preuve). Elle peut servir à mesurer la fiabilité du logiciel. Cette dernière ne peut être évaluée de manière significative que sur un comportement d environnement cohérent. La simulation de l environnement définit implicitement un premier critère de sélection de données de test, puisque ces dernières sont choisies en fonction de leur conformité à une spécification. Ce critère est le plus faible dans le cadre des logiciels synchrones (i.e. l ensemble de données de test résultant contient les données définies par tout autre critère). En d autres termes, la simulation de l environnement d un logiciel synchrone est synonyme de son test exhaustif. Nous avons ensuite étudié deux manières de prendre en compte les propriétés de sûreté du logiciel. La première, la simulation d un logiciel sûr, est une extension du principe de la simulation de l environnement. Elle consiste à reproduire, de manière aléatoire, les comportements du logiciel sous test conformes à l ensemble des propriétés. Cette technique d animation a pour but de valider les propriétés de sûreté.
Générateur aléatoire contraint Programme réactif Figure 2: Générateur aléatoire contraint La deuxième technique fondée sur la spécification des propriétés de sûreté, appelée test des propriétés de sûreté [12], permet d engendrer automatiquement des comportements de l environnement qui sont à la fois conformes à sa spécification et aptes à détecter des violations des propriétés. Elle définit ainsi un deuxième critère de sélection de données de test. Ce critère est inclus dans la simulation de l environnement et cerne mieux le problème de la vérification des propriétés de sûreté. Les techniques ci-dessus sont regroupées sous le nom de génération aléatoire sous contraintes, les contraintes étant la spécification de l environnement (avec éventuellement une aptitude élevée de détection des violations des propriétés de sûreté) ou des propriétés de sûreté. Notons qu à l exception du code exécutable, nous n avons besoin d aucune information sur l implantation du logiciel à tester (qui peut être faite dans un langage quelconque) pour appliquer ces techniques. La dernière technique de test que nous proposons est de type structurel et concerne plus spécifiquement les programmes écrits en LUSTRE. Elle consiste en la définition de critères de sélection (et des moyens de génération automatique associés) exprimés en termes de couverture du réseau d opérateurs associé à ces programmes. En introduisant cette technique, nous espérons pouvoir détecter des défauts qui sont généralement issus d erreurs de programmation et qui n affectent pas forcément la validité des propriétés de sûreté. Concernant l oracle de test, une solution évidente consiste à encapsuler dans un nœud LUSTRE l expression des propriétés de sûreté. Le programme ainsi obtenu peut s exécuter en même temps que le logiciel sous test et calculer à chaque cycle de son exécution la valeur logique des propriétés après lecture des entrées et des sorties. 3.2 Techniques de génération aléatoire sous contraintes 3.2.1 Principes Un générateur aléatoire contraint est un programme animant une spécification LUSTRE, qui, rappelons-le, peut être assimilé à une formule de logique temporelle du passé. Quelle que soit la technique de simulation (parmi celles présentées dans les paragraphes suivants), les générateurs utilisés ont un point commun : les données produites sont calculées de manière dynamique. Cela signifie qu un générateur est construit pour interagir avec un programme réactif et pour calculer des entrées conformes à la spécification qu il simule (cf. figure 2). Lors de chaque réaction, le calcul d une donnée satisfaisant la spécification dépend des données engendrées lors des réactions précédentes, mais aussi des réponses du programme réactif à ces données. Le choix d une génération de nature dynamique est justifié par l hypothèse que les réactions du programme réactif ne peuvent pas être calculées à l avance (i.e. nous ne faisons aucune hypothèse sur la fonction réalisée par ce programme, dont on ne connaît que les variables d entrée et de sortie). La simulation d environnement, présentée au paragraphe 3.2.2, considère que le programme réactif est le logiciel sous test, auquel cas il s agit d une technique de test boîte noire, ou bien ne fait aucune hypothèse sur la fonction réalisée par ce programme, auquel cas elle peut uniquement servir à valider la robustesse des hypothèses sur l environnement.
L utilisation du test des propriétés de sûreté (cf. paragraphe 3.2.3), au contraire, n a de sens que si l on suppose que le programme réactif sous test doit satisfaire ces propriétés. Enfin, la simulation d un logiciel sûr ne peut être vue que comme une technique d animation, considérant que le programme réactif est, cette fois, l environnement du logiciel simulé. La mise en œuvre de cette technique est très proche de celle de la simulation d environnement et n est pas, de ce fait, exposée dans la suite. 3.2.2 Simulation d environnement Considérons de nouveau l exemple du logiciel de contrôle de l ascenseur et, plus particulièrement, la spécification simplifiée de son environnement : not (portes_ouvertes and portes_fermées) always_from_to (portes_fermées, portes_fermées, pre ouvrir_portes) and always_from_to(portes_ouvertes, portes_ouvertes, pre fermer_portes) Grâce au compilateur LUSTRE [4], ces propriétés sont automatiquement traduites en un modèle (un automate d états finis). Comme dans le cadre de la preuve, ce modèle est représenté de manière symbolique et donc compacte. En effet, les états sont décrits au moyen de variables d état booléennes : un état correspond à une valeur particulière de ces variables. Dans l exemple des propriétés considérées, le modèle comporte sept variables d état, (v i ) i=1,7 (donc au plus 2 7 états). La fonction de transition du modèle est composée d un ensemble de fonctions booléennes de transition partielles associées aux variables d état. Chacune de ces fonctions permet de calculer la valeur de la variable d état associée dans l état successeur de l état courant. L avantage de ce type de représentation est double : d une part les états sont codés de manière très succincte (n variables suffisent pour représenter 2 n états); d autre part, les fonctions de transition partielles sont beaucoup moins complexes qu une seule fonction de transition globale. Les propriétés de l environnement sont traduites en une fonction booléenne calculable à partir des variables d état et d entrée [9]. Cette fonction permet d identifier pour un état donné (i.e. pour une valeur donnée des variables d état) l ensemble des valeurs des entrées qui respectent la spécification. La représentation de cette fonction sous forme de graphe de décision binaire pour les propriétés de l exemple est donné dans la figure 3 (0 et 1 sont des abréviations pour false et true respectivement). Ce graphe est l instrument essentiel de la génération aléatoire de séquences d entrées. Chaque élément d une telle séquence est calculé au moyen d un parcours du graphe, défini de la manière suivante : 1. Dans un premier temps, on détermine le sous-graphe correspondant à la valeur courante des variables d état. Ce sous-graphe ne comporte donc que des variables d entrée. Par exemple, la figure 3 présente le graphe obtenu pour la valeur des variables d état v 1 = v 2 = true. 2. Ensuite, on affecte aux variables d entrée du sous-graphe ainsi obtenu une valeur aléatoire correspondant à un chemin menant à une feuille de valeur 1 (i.e. une valeur pour laquelle la spécification est vérifiée). Lorsque plusieurs valeurs sont possibles, le choix d une telle valeur peut se faire de manière équiprobable, grâce à un étiquetage approprié du sous-graphe, ou suivant des probabilités explicitement définies (on parle alors de profils opérationnels [13]). L existence pour tout état du modèle associé à la spécification d une valeur d entrée conforme à cette dernière est supposée être une qualité de toute spécification d environnement bien construite [9]. Dans le cas opposé, l environnement pourrait se trouver dans des situations où il ne peut émettre aucune réaction valide, ce que nous considérons comme un défaut de spécification. 3.2.3 Test des propriétés de sûreté La technique de test des propriétés de sûreté effectue une sélection plus fine des données d entrée que le simple test aléatoire effectué par la simulation d environnement. Elle favorise les données qui testent les propriétés de sûreté, c est à dire celles facilitant la détection des violations des ces proprié-
v 1 v 4 v 3 v 2 v 2 v 5 v 6 v 7 portes_ouvertes portes_ouvertes portes_ouvertes 0 portes_fermées 0 1 portes_fermées portes_ouvertes 0 1 1 0 portes_fermées 1 1 0 Figure 3: Graphe de décision binaire de la propriété et sous-graphe pour v 1 = v 2 =1. tés. Il s agit donc d une variante de la simulation d environnement qui s appuie à la fois sur la spécification de l environnement et sur celle des propriétés de sûreté. Cette technique nécessite de caractériser les données engendrées en fonction de leur pouvoir de détection de défauts liés aux propriétés de sûreté. Une première caractérisation simple pourrait être : Test = A l instant de l exécution t, une entrée e ne peut révéler un défaut que s il existe une sortie s pour laquelle la valeur des propriétés de sûreté est fausse à ce même instant t. La génération de données d entrée se distingue de celle intervenant lors de la simulation d environnement par la deuxième étape : la valeur des entrées sera en priorité choisie parmi celles testant les propriétés de sûreté. Notons qu il est fréquent qu une telle valeur n existe pas pour certains états du modèle : dans ce cas, les données engendrées ignorent cette contrainte et se contentent de vérifier la spécification de l environnement. Cette première définition simple des données testant les propriétés de sûreté permet une mise en œuvre de la technique facile et efficace. Mais, en contrepartie, elle présente un inconvénient : en définissant le pouvoir de détection de défauts d une donnée uniquement à partir de la satisfaisabilité des propriétés de sûreté à l instant courant, on écarte les séquences de données qui peuvent révéler un défaut à un instant ultérieur mais dont les éléments ne satisfont pas la définition ci-dessus à l instant courant [9]. Généraliser cette définition à toute séquence d entrées revient à considérer le prédicat Test(i) : Test(i) = A l instant de l exécution t, une entrée e ne peut révéler un défaut que s il existe une séquence de sorties de longueur i + 1 pour laquelle la valeur des propriétés de sûreté devient fausse à l instant t+i. Le test de propriétés de sûreté devrait être en mesure d engendrer des données satisfaisant : Test(0)... Test(n)... Toutefois, la mise en œuvre dans ce cas risque de se heurter aux mêmes problèmes de complexité que la preuve. Le calcul des entrées satisfaisant Test(1), par exemple, nécessite de calculer les états
node BoutonsCabine( requête, étage: bool^4; portes_ouvertes : bool; ) returns(allumer_intérieur:bool^4); let allumer_intérieur[0..3] = not (étage[0..3] and portes_ouvertes^(4)) and requête[0..3] -> not (étage[0..3] and portes_ouvertes^(4)) and (requête[0..3] or pre allumer_intérieur[0..3]); tel requête[i] étage[i] portes_ ouvertes pre a 8 a 1 a 2 a 3 a 4 a 5 a 7 a 6 -> allumer_intérieur[i] accessibles depuis l état courant et de calculer pour chacun d entre eux les entrées satisfaisant la spécification. Ce calcul d états successeurs doit se répéter n fois pour Test(n). Nos premières expériences ont montré que l approche actuellement retenue (qui revient en réalité à considérer la définition Test(0)) convient pour les propriétés de sûreté instantanées (i.e. ne faisant pas intervenir d opérateurs temporels) ainsi que pour de nombreuses propriétés temporelles simples. Nous sommes actuellement en train de faire évoluer cette technique afin que la définition de Test(n) puisse être prise en compte dans sa généralité. 3.3 Techniques de test structurel Figure 4: Un nœud LUSTRE et son réseau d opérateurs La majorité des techniques structurelles de test pour langages impératifs utilisent comme modèle du programme un graphe de contrôle. Les nœuds de ce graphe correspondent à une séquence d instructions contiguës, les arcs étant associés aux branchements du programme. Les techniques de test structurel ont comme objectif la couverture de ce graphe. Par exemple, la couverture d instructions est réalisée si tous les nœuds du graphe (toutes les instructions du programme) ont été exécutés au moins une fois pendant le test. Cette forme de représentation n est pas adaptée à un langage flux de données comme LUSTRE. Un programme LUSTRE est plutôt représenté par un réseau d opérateurs. En effet, un tel programme, n est qu un ensemble non ordonné d équations définissant des relations invariantes entre les entrées et les sorties. Considérons le nœud LUSTRE régissant l allumage des boutons à l intérieur de la cabine de l ascenseur de l exemple présenté dans la figure 4. Dans la même figure on représente le réseau d opérateurs associé à la définition de chacune des sorties du nœud (allumer_intérieur[i]). Nous définissons un chemin comme une suite finie d arcs contigus du réseau d opérateurs. Le premier arc du chemin est une entrée du réseau tandis que le dernier est une sortie. Dans l exemple de la figure 4, nous identifions, entre autres, les chemins suivants : p 1 = (requête[i], a 1, allumer_intérieur[i]), p 2 = (requête[i], a 6, a 7, allumer_intérieur[i]), p 3 = (étage[i], a 2, a 3, a 1, allumer_intérieur[i]). Il est facile de constater que le nombre de chemins peut être infini, suite à la présence de l opérateur pre qui permet d accéder à la valeur de son argument à l instant précédent. Un prédicat de chemin associé au chemin p, noté PP(p), est la condition pour que le calcul du dernier arc de p dépende du chemin p. En d autres termes, c est la condition pour que le chemin p soit traversé par le flux de données. Par exemple : PP(p 1 ) = a 3 and init, PP(p 2 ) = not a 8 and a 5 and not init, PP(p 3 ) = portes_ouvertes and requête[i] and init,
où init = true -> false. Nous pouvons maintenant définir des critères de couverture sur le réseau d opérateurs [14] tels que la couverture d opérateurs, la couverture des arcs ou la couverture des chemins. A partir d un ensemble de prédicats de chemin satisfaisant un critère de couverture donné, il est possible de procéder au test structurel d un programme LUSTRE de deux manières : Calculer à l avance les données d entrée nécessaires à l exécution de chemins. Cela est possible grâce à une utilisation astucieuse de l outil de preuve [15]. Exécuter le programme avec des données aléatoires (en utilisant, par exemple, un simulateur de son environnement) et évaluer, a posteriori, le taux de couverture obtenu. 3.4 Vers une approche mixte de validation Pour récapituler, en essayant d identifier les démarches de validation les plus appropriées, nous distinguons le cas où le test est utilisé en complément à la preuve de celui où il est le seul moyen de validation utilisé. Dans le premier cas, nous supposons que l implantation du logiciel en LUSTRE ainsi que la spécification des invariants d environnement et des propriétés de sûreté sont disponibles. Les techniques de test peuvent être utilisées de la manière suivante : Afin de valider la spécification de l environnement, on peut procéder à l exécution du logiciel en lui fournissant des entrées produites par simulation de l environnement. L observation des comportements de l environnement produits peut nous révéler des éventuels défauts. Il est également envisageable de ne pas utiliser le logiciel dans cette opération en se contentant de fournir en entrée du simulateur d environnement des données purement aléatoires. La validation des propriétés de sûreté peut, ensuite, avoir lieu de deux manières : - En les transformant en un oracle introduit dans le processus de test du logiciel, on peut confirmer, par observation, que leur satisfaction correspond aux comportements souhaités. - En effectuant conjointement une simulation de l environnement et une simulation de comportement sûr du logiciel simultanées on peut également par observation déceler des incohérences éventuelles dans la spécification des propriétés de sûreté. Cette situation est obtenue en faisant interagir les deux simulateurs. Considérons maintenant que le test est le seul moyen envisagé de validation. Cela peut être le cas quand la preuve est trop gourmande en ressources ou quand l implantation du logiciel n est pas faite en LUSTRE. En supposant que les contraintes d environnement et les propriétés de sûreté sont toutes disponibles et exprimées en LUSTRE, nous distinguons deux cas : Le logiciel est lui aussi implanté en LUSTRE (ce cadre est identique à celui de la preuve, du point de vue des spécifications disponibles). Le logiciel est développé dans un langage quelconque; seul son code exécutable est disponible. Dans les deux cas nous définissons trois objectifs pour le test : 1. Valider la spécification de l environnement. 2. Valider la spécification des propriétés de sûreté. 3. Vérifier et valider le logiciel. Pour la réalisation des deux premiers objectifs le langage d implantation du logiciel est sans importance. Ces objectifs sont atteints de la même manière que pour le cas de l utilisation du test en complément de la preuve. Pour la vérification et la validation du logiciel le choix du langage d implantation a une incidence. En résumé, nous suggérons l application des techniques de test dans l ordre suivant : 1. L application de la simulation de l environnement en phase initiale de test devrait permettre de détecter rapidement des défauts dans le logiciel par la simple observation de son comportement.
2. Ensuite, l application de la technique de test des propriétés de sûreté peut permettre la mise en évidence des défauts liés aux propriétés de sûreté, dont la détection par la seule simulation de l environnement est difficile (i.e. des conditions très spécifiques doivent être réunies pour que ces défauts se manifestent). 3. Dans le cas où le logiciel est implanté en LUSTRE, l utilisation de la technique de test structurel est recommandée. Elle peut avoir lieu avant ou après le test des propriétés de sûreté. D ailleurs, on peut engendrer les données de test en utilisant un simulateur d environnement, si on opte pour un mode de génération aléatoire. 4 Conclusion La récente parution d un ensemble de travaux ayant pour objet le test des logiciels synchrones et plus particulièrement des logiciels spécifiés en LUSTRE, montre que ce thème suscite un certain intérêt aussi bien pour la recherche que pour l industrie. En particulier, trois approches tentent d adapter au cas de LUSTRE un ensemble de techniques conçues dans d autres contextes et dont les auteurs cherchent à montrer l adéquation au problème particulier du test des programmes synchrones. Le test statistique de programmes a été appliqué avec succès aux programmes séquentiels [16]. Il consiste à analyser la structure du graphe de contrôle et à déterminer une loi de distribution pour les données d entrée assurant une probabilité élevée de satisfaction des critères de couverture retenus. Cette technique est adaptée à la couverture de l automate produit par le compilateur LUSTRE [17]. Une autre approche tente d appliquer au cas de LUSTRE une méthode de génération de jeux de test à partir de l analyse d une spécification algébrique [18]. Cette méthode considère que la spécification du programme à tester est donnée sous la forme d un module comportant des variables, des opérations ainsi qu un ensemble d axiomes spécifiant ces opérations. Un jeu de test est sélectionné pour chacun de ces axiomes. [19] a exploré la possibilité d adapter cette méthode à LUSTRE. Enfin, [20] propose l utilisation conjointe de techniques de test systématique et de vérification formelle (LESAR). Pour une comparaison détaillée de ces approches avec le travail que nous avons présenté dans cet article on pourra se référer à [9]. Nous pouvons cependant noter qu à la différence des techniques cidessus, notre approche aborde le problème de la validation des logiciels spécifiés en LUSTRE avec un souci de complémentarité et de compatibilité avec la technique de vérification existante qui se traduit en l utilisation de formalismes et de techniques de manipulation de modèles similaires ainsi qu en un effort d intégration de nos techniques dans le processus de preuve. Enfin, parmi les perspectives de ce travail, nous pouvons citer : La généralisation de la définition du test des propriétés de sûreté, qui devrait permettre une meilleure identification automatique des séquences à engendrer. L extension des techniques à la prise en compte des contraintes portant sur des valeurs numériques. Nous nous sommes, en effet, limités dans un premier temps au cas des variables booléennes (cette restriction est également présente dans la preuve). L intégration d outils d aide à la localisation de défauts. Ces outils sont en cours de développement au sein d un environnement interactif de test. 5 Remerciements Je tiens à remercier Farid Ouabdesselam pour l aide qu il m a apportée lors de la rédaction de cet article. 6 Bibliographie [1] A. Benveniste and G. Berry. The Synchronous Approach to Reactive and Real-Time Systems. Proceedings of the IEEE, 79(9):1270 1282, Septembre 1991.
[2] N. Halbwachs, D. Pilaud, F. Ouabdesselam, and A.-C. Glory. Specifying, Programming and Verifying Real-Time Systems, using a synchronous declarative language. In Workshop on automatic verification methods for finite state systems, LNCS 407, Grenoble, France, Juin 1989. Springer Verlag. [3] N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. The Synchronous Data Flow Programming Language LUSTRE. Proceedings of the IEEE, 79(9):1305 1320, Septembre 1991. [4] P. Raymond. Compilation efficace d un langage déclaratif synchrone : le générateur de code LUSTRE-V3. Thèse, Institut National Polytechnique de Grenoble, Grenoble, France, Novembre 1991. [5] A.-C. Glory. Vérification de propriétés de programmes flots de données synchrones. Thèse, Université Joseph Fourier, Grenoble, France, Décembre 1989. [6] C. Ratel. Définition et réalisation d un outil de vérification formelle de programmes LUSTRE: Le système Lesar. Thèse, Université Joseph Fourier, Grenoble, France, Juin 1992. [7] D. Pilaud and N. Halbwachs. From a synchronous declarative language to a temporal logic dealing with multiform time. In Symposium on Formal Techniques in Real Time and Fault Tolerant Systems, Warwick, Septembre 1988. Springer Verlag. [8] J. E. Laprie. Guide de la sûreté de fonctionnement. Cépaduès, 1995. [9] I. Parissis. Test de logiciels synchrones spécifiés en LUSTRE. Thèse, Université Joseph Fourier, Grenoble, France, Septembre 1996. [10] R. Bryant. Graph-based algorithms for boolean functions manipulation. IEEE Transactions on Computers, pages 667 692, Août 1986. [11] A. Bouajjani, J. Fernandez, and N. Halbwachs. Minimal model generation. In Workshop on Computer-Aided Verification, Rutgers (N.J.), Juin 1990. [12] I. Parissis and F. Ouabdesselam. Specification-based Testing of Synchronous Software. In ACM SIGSOFT Fourth Symposium on the Foundations of Software Engineering, pages 127 134, San Francisco, USA, Octobre 1996. [13] F. Ouabdesselam and I. Parissis. Constructing Operational Profiles for Synchronous Critical Software. In 6th International Symposium on Software Reliability Engineering, pages 286 293, Toulouse, France, Octobre 1995. [14] F. Ouabdesselam and I. Parissis. Testing Synchronous Critical Software. In 5th International Symposium on Software Reliability Engineering, pages 239 248, Monterey, USA, Novembre 1994. [15] I. Parissis and F. Ouabdesselam. Techniques de Test pour des Logiciels Réactifs Synchrones. In Modélisation des Systèmes Réactifs, pages 11 18, Brest, France, Mars 1996. [16] H. Waeselynck. Vérification de logiciels critiques par le test statistique. Thèse, Institut National Polytechnique de Toulouse, Toulouse, France, Janvier 1993. [17] C. Mazuet. Stratégies de Test pour des Programmes Synchrones - Application au Langage LUS- TRE. Thèse, Institut National Polytechnique de Toulouse, Toulouse, France, Décembre 1994. [18] G. Bernot, M.-C. Gaudel, and B. Marre. Software testing based on formal specifications : a theory and a tool. Software Engineering Journal, 6:387 405, 1991. [19] N.-C. Hsiao. Sélection de tests de propriétés de sûreté à partir d une modélisation algébrique de programmes LUSTRE. Thèse, Université Paris-Sud, Orsay, France, Octobre 1994. [20] M. Müllerburg, L. Holenderski, O. Maffeis, A. Merceron, and M. Morley. Systematic Testing and Formal Verification to Validate Reactive Programs. Software Quality Journal, 4(4), 1995.