2.3 V ÉRIFICATION DES CONSTITUANTS RÉACTIFS
2.3.1 Techniques de vérification formelle
2.3.1.2 L’évaluation sur modèle ... 55 2.3.2 Vérification par la méthode de test ... 56 2.3.2.1 Le test structurel ... 58 2.3.2.2 Le test fonctionnel ... 59 2.3.3 Le test de conformité pour la vérification de constituants réactifs ... 63 2.3.3.1 Spécification, Implantation & relation de conformité ... 63 2.3.3.2 Le processus de test de conformité selon la norme ISO9646 ... 64
2.4 LES MÉTHODES ET LES OUTILS DE GÉNÉRATION DE SCÉNARIOS DE TEST DE CONFORMITÉ ...68
2.4.1 Les méthodes de génération de test par dérivation de spécification ... 69 2.4.1.1 Méthodes fondées sur les automates ... 69 2.4.1.2 Méthodes fondées sur les systèmes de transitions ... 71 2.4.2 Les outils utilisés dans la génération de scénarios de test de conformité ... 84 2.4.2.1 L’outil TorX ... 84 2.4.2.2 L’outil TGV ... 85
2.5LA COUVERTURE DES SCÉNARIOS DE TEST ...88
2.5.1 La couverture des états ... 89 2.5.2 La couverture des branches ... 89 2.5.3 La couverture des paires de branches ... 89 2.5.4 La couverture des chemins ... 90 2.5.4 La couverture par hypothèse de test ... 90
2.6CONCLUSION ...91
2.1 Introduction
C
CC
C
e chapitre a pour objectif de préciser le positionnement scientifique de notre travail. Nous avons souligné au chapitre précédent que le déploiement du système de contrôle commande et de signalisation ferroviaire ERTMS nécessite de longues phases de vérification et de test. Il s’agit d’un système réparti et complexe dont la validation nécessite la vérification de ses constituants réactifs. Par réactif, nous entendons un constituant qui réagit aux stimuli de son environnement.Dans ce chapitre, nous décrivons deux techniques de vérification : la vérification formelle et le test. La vérification formelle permet de s’assurer que les modèles d’un système ou d’un programme sont corrects. Cette technique s’effectue sur un modèle du système et non pas sur le système lui-même dans son environnement d’exécution. Quant à la technique du test, elle reste incontournable dans le contexte de validation de systèmes réactifs et représente la technique la plus utilisée. Nous avons choisi cette technique pour la vérification de nos constituants réactifs et en particulier le test de conformité. Ce type de test appelé test boîte noire convient parfaitement à notre contexte industriel. Les constituants réactifs que nous voulons vérifier sont des constituants dont le code est inconnu et seule l’interface est accessible. Le test de conformité détaillé dans la section 2.3.3 permet de vérifier si le comportement d’une implantation réelle d’un système réactif est correct par rapport à la spécification. Il inclut plusieurs notions : spécification, implantation sous test, génération de cas de test, exécution des cas de test et verdicts de test. Cependant l’écriture manuelle de cas de test est consommatrice en temps et en coût. C’est l’un des arguments qui a encouragé l’automatisation du processus de génération de tests en se basant sur des méthodes formelles. Ces méthodes augmentent la confiance dans les résultats des tests obtenus.
De manière générale, les techniques de test possèdent des caractéristiques communes : fournir des entrées à l’implantation sous test pour la stimuler et observer les sorties, ensuite comparer ces sorties avec les sorties attendues pour conclure enfin sur la correction ou non. Le test ne garantit jamais la correction et ne peut pas être exhaustif. C’est la raison pour laquelle, des tests raisonnables (en termes de coût) mais suffisamment complets doivent être sélectionnés afin d’acquérir une confiance suffisante dans le système quand celui-ci passe correctement les tests. Cette sélection se base sur des critères de couverture (cf. section 2.5) structurels du code dans le cas où ce dernier est connu. Dans le cas de code inconnu (test boîte noire), l’estimation de la qualité des tests peut se faire en faisant des hypothèses (cf. section 2.5.4) sur les implantations à tester [Jéron, 2004].
La première section de ce chapitre introduit les systèmes répartis et les constituants réactifs. Dans la section suivante, nous définissons un état de l’art des techniques de vérification de constituants réactifs. Ensuite, les diverses méthodes et outils de génération automatique de scénarios de test de conformité sont détaillés. A la fin de ce chapitre, nous définissions les critères de couverture de tests.
2.2 Système réparti & constituant réactif
2.2.1 Système répartiLe système ERTMS constitue le contexte industriel de nos travaux de thèse. Il est en effet un système complexe et réparti, composé par des constituants réactifs.
Définition 2.2.1 Définition 2.2.1Définition 2.2.1
Définition 2.2.1 Système répartiSystème répartiSystème réparti. Un système réparti (ou distribué, «distributed system»), Système réparti est composé de plusieurs systèmes calculatoires autonomes (sinon, c’est un système non réparti) sans mémoire physique commune (sinon c'est un système parallèle) qui communiquent par l’intermédiaire d’un réseau (quelconque) [Tardieu-01].
Les systèmes répartis sont caractérisés par les points suivants [Tardieu-01]:
Accès distant: un même service peut être utilisé par plusieurs acteurs, situés à des endroits différents,
Redondance: des systèmes redondants permettent de pallier une faute matérielle, ou
de choisir le service équivalent avec le temps de réponse le plus court,
Performance: la mise en commun de plusieurs unités de calcul permet d’effectuer des calculs parallèles en des temps plus courts,
Confidentialité: les données brutes ne sont pas disponibles partout au même moment, seules certaines vues sont exportées.
Le système réparti est alors vu comme une entité composée d’un certain nombre de processus interconnectés par un certain nombre de liens et d’un système de communication. Ce dernier définit une méthode de communication par variables partagées ou par envoi de messages. Comme nous l’avons déjà décrit dans l’introduction générale et dans le chapitre 1, ERTMS est composé de constituants qui interagissent ensemble par l’envoi de messages et l’appel de procédures. Ces constituants sont appelés des constituants réactifs. Comment définit-on un constituant ERTMS réactif ?
2.2.2 Constituant réactif
Dans un contexte ferroviaire, le système ERTMS est composé de constituants.
Un constituant Un constituant Un constituant Un constituant
ERTMS n’est autre qu’un composant logiciel
ERTMS n’est autre qu’un composant logicielERTMS n’est autre qu’un composant logiciel
ERTMS n’est autre qu’un composant logiciel
car ce dernier représente une boîte qui encapsule du logiciel. Il possède des interfaces au travers desquelles sont fournis des services. Ces interfaces peuvent être fournies par un composant qui joue le rôle deprestataire du service, ou requises par un composant qui joue alors le rôle de client [Pareaud, 2009]. Cette définition de composant logiciel correspond parfaitement à celle du constituant ERTMS.
L’avantage de baser notre méthodologie sur une approche par composants est le fait que ces derniers permettent la réutilisation. De plus, ils facilitent l’ingénierie des architectures dirigées par les modèles en considérant le logiciel comme un ensemble d’entités qui interagissent et s’échangent des services. Le
composant est constituécomposant est constituécomposant est constituécomposant est constitué
par [Pareaud, 2009] :Un
contenucontenucontenucontenu
composé par des variables et des instructions, il s’agit d’un algorithme au sens informatique du terme ;Des
interfacesinterfacesinterfacesinterfaces
qui permettent d’abstraire le contenu du constituant aux services qu’il rend ou dont il a besoin (appel de procédures, évènements, communication). Les interfaces sont de deux types :Fournies si le composant rend le service ;
Requises si le composant nécessite le service pour rendre un service correct;
D’autresD’autresD’autresD’autrescomposantscomposantscomposantscomposants
. Dans ce cas, le composant est qualifié de composite.Suite à cette définition des composants, il est possible de représenter un logiciel complexe comme une composition de boîtes interconnectées à travers un modèle à composants. En effet, le modèle à composants constitue une abstraction du logiciel simplifiant ainsi toute modification de ce dernier pour deux raisons différentes :
La première concerne l’isolement de l’algorithme et ses données susceptibles d’être modifiées dans un composant.
La deuxième concerne les interactions entre les composants à travers des interfaces fournissant ou demandant des services.
La description des services est indépendante de leur implémentation, il est alors possible de remplacer l’implémentation d’un service par un autre pour satisfaire à des besoins non-fonctionnels de ce service par exemple, sa consommation de ressources système. Pour intégrer un composant dans son environnement, il suffit de le créer, connecter ses interfaces requises aux interfaces fournies par les composants existants dans le système et puis le démarrer. Ainsi, d’autres composants peuvent être connectés aux interfaces qu’il fournit. Ce même composant peut être supprimé en suivant les étapes inverses : les composants sont déconnectés des interfaces qu’il fournit, le composant est ensuite arrêté, puis ses interfaces requises sont débranchées, et enfin, le composant est détruit.
Le constituant est dit
réactifréactifréactifréactif
quand il réagit continûment à son environnement physique à une vitesse déterminée par ce dernier [Lesens, 1997]. Ce concept s’oppose d’une part auxsystèmes transformationnels
systèmes transformationnelssystèmes transformationnels
systèmes transformationnels
et d’autre part auxsystèmes interactifssystèmes interactifssystèmes interactifssystèmes interactifs
. Les systèmes transformationnels sont des systèmes classiques en informatique qui disposent des entrées dès leur initialisation, opèrent sur ces données d’entrée un ensemble de transformations complexes et fournissent les résultats à la fin de leur exécution (cf. Fig.2.14); le compilateur est un exemple de ce type de systèmes.Figure 2.14: Les systèmes transformationnels
Quant aux
systèmes interactifssystèmes interactifssystèmes interactifssystèmes interactifs
, ils sont semblables aux systèmes réactifs. Ils interagissent en effet à leur environnement mais à une vitesse qui leur est propre (cf. Fig.2.15). Autrement dit, ils peuvent mémoriser certaines entrées avant de les prendre en compte sans que cela ait une influence sur le fonctionnement du système. Les systèmes d’exploitation constituent un exemple de ce type de système [Jourdan, 94].Figure 2.15: Les systèmes interactifs
Nous nous intéressons aux
systèmes réactifssystèmes réactifssystèmes réactifssystèmes réactifs
particulièrement utilisés dans le cadre du contrôle des systèmes critiques comme le transport, le domaine nucléaire, la commande de processus industriels, etc. Les systèmes réactifs sont des systèmes critiques et doivent impérativement satisfaire des contraintes strictes de fonctionnement. Une erreur peut entraîner des coûts considérables, aussi bien en terme financier qu'en terme humain. Quand ils interagissent avec leur environnement, les systèmes réactifs ne maitrisent pas le rythme de ces interactions. Ce rythme est en effet imposé par l’environnement, c’est la caractéristique principale des systèmes réactifs qui interdit la perte des entrées. Les sorties produites dépendent alors des valeurs de ces entrées et de leur instant d’occurrence, il s’agit de systèmes déterministes (cf. Fig.2.16).Figure 2.16: Les systèmes réactifs
Ces systèmes sont aussi parallèles car ils contiennent un ensemble de composants fonctionnant en parallèle afin de réaliser le comportement global souhaité. Ce fonctionnement parallèle des différents composants n’exige pas forcément une implantation parallèle du système [Jourdan, 1994].
Dans la section suivante, nous présentons un état de l’art des différentes techniques de vérification de constituants réactifs. Nous définissons en premier lieu les méthodes formelles et en second lieu la méthode du test, en particulier le test de conformité.
2.3 Vérification des constituants réactifs
LLLLa complexité des systèmes informatiques ne cesse pas de croître ce qui peut provoquer la présence d’erreurs durant la conception de ces derniers. Malheureusement, dans certains cas de logiciels critiques, un comportement erroné peut conduire à des conséquences dramatiques. D’ailleurs, il existe plusieurs exemples, tristement célèbres, d’erreurs qui ont provoqué des dégâts matériels ou financiers et même parfois des pertes humaines. Un des exemples le plus connu est celui du crash d'Ariane 5, qui aurait pu être évité suite à une vérification plus rigoureuse ([Herbreteau, 2001], [Fleury, 2001]). De plus, dans la plupart des drames qui se produisent, les coûts des dégâts engendrés sont disproportionnés par rapport à la simplicité de l’erreur conduisant au problème.
Dans le cas des transports avioniques et ferroviaires, le niveau de criticité est beaucoup plus élevé car un logiciel erroné peut conduire à la perte de vies humaines. Il est alors indispensable de vérifier le bon fonctionnement de ces systèmes tout au long de leur cycle de développement en V (cf. Fig.2.17). Avant la mise en œuvre d’un produit final, ce cycle contient une phase d’analyse, une phase de conceptualisation, une phase de réalisation et une phase de vérification de la conformité du produit final par rapport aux exigences. La phase d’analyse entraîne la conception des architectures fonctionnelle et opérationnelle à partir de l’analyse des besoins du système. L’architecture opérationnelle est la base de la réalisation physique du système. Les différents constituants du système sont conçus et programmés de manière indépendante puis intégrés pour la conception du système global [Godary, 2004].
Chacune des différentes phases du cycle de développement a sa propre méthodologie de vérification (cf. Fig.2.17) afin de détecter les erreurs à des stades moins avancés. Quant à la vérification du produit final, elle se fait par rapport aux fonctionnalités attendues rédigées dans les spécifications du système. Le cahier des charges permet de décrire ces spécifications de manière informelle. Les méthodes de modélisation formelle permettent de modéliser les spécifications en résolvant les problèmes de redondance, d’ambiguïté et d’erreur liés à la formulation en langage naturel des spécifications décrites dans le cahier des charges. Ces
méthodes formelles produisent des modèles de spécifications qui respectent une sémantique statique et dynamique et offrent des outils permettant de vérifier les fonctionnalités du système concerné. C’est ainsi que plusieurs techniques de vérification peuvent s’appliquer à des niveaux différents du cycle de développement du système selon que l’on souhaite vérifier les modèles formels du système ou bien le produit livré à la fin (cf. Fig.2.17). Dans la section suivante, nous allons détailler ces méthodes formelles de vérification et donner quelques exemples.
Figure 2.17: Le cycle de développement de logiciel en V
2.3.1 Techniques de vérification formelle
Les techniques de vérification formelle ont été développées dans les années 80 dans le but de vérifier un ensemble de propriétés sur le modèle formel conformément aux besoins informels (exprimés par les utilisateurs). Deux grandes familles de vérification formelle existent [Evrot et al, 2006a] :
llll’’’’évaluation sur modèleévaluation sur modèleévaluation sur modèleévaluation sur modèle
(« model-checking ») etla preuve de la preuve de la preuve de la preuve de
théorème
théorèmethéorème
théorème
(« theorem-proving »).2.3.1.1 La preuve de théorème
Dans la vérification basée sur la démonstration de théorème, nous considérons une spécification formelle et nous essayons de démontrer que les propriétés sont bonnes. Il s’agit d’une approche syntaxique et axiomatique qui permet de déduire des faits d’autres faits en se servant des propositions, des axiomes et des règles de déduction. Les assistants de preuve sont des outils informatiques de démonstration qui permettent de finaliser une preuve suggérée par l’utilisateur grâce aux méthodes de déduction automatique [Chapurlat, 2007]. Parmi les assistants de preuve, nous notons : PVS (Prototype Verification System) [Owre et al,
1996], Coq [Coq Development Team, 2002], HOL [Melham and Gordon, 1993] et Isabelle [Paulson, 1994].
Les techniques de preuve se basent sur des démonstrations mathématiques pour vérifier la compatibilité des modèles. Elles permettent de déduire des conclusions à partir d'une description d'évènements ou d'opérations permettant de faire évoluer le système. L’automatisation complète des techniques de preuve est rarement possible même en utilisant les assistants de preuve. En effet, l’utilisateur est souvent obligé de guider la preuve en interagissant avec l’assistant [Evrot, 2008]. Dans les travaux de [Roussel et Denis, 2002], la technique de preuve a été utilisée dans un contexte de Système à Evènements Discrets (SED) afin de vérifier si les propriétés sont satisfaites par l’ensemble automate et logiciel. Ensuite, dans les travaux de ([Kim et al, 2005], [Son&Seong, 2003]), les outils de vérification de preuve ont été utilisés afin de vérifier les modèles de spécifications du logiciel dans le contexte de systèmes exigeant la sécurité. Cette utilisation a provoqué une contrainte supplémentaire, à savoir la formalisation des spécifications du logiciel dans un langage acceptable par l’assistant de preuve et la traduction des exigences système de sécurité fonctionnelle sous forme de propriétés.
Quant aux méthodes de model-checking, elles se basent généralement sur des modèles de comportement du type états/transitions ; un modèle semblable aux formalismes utilisés pour spécifier les logiciels de contrôle-commande.
2.3.1.2 L’évaluation sur modèle
Les techniques d’évaluation sur modèle permettent à partir d’un modèle à états finis d’un système et d’une propriété énoncée formellement de vérifier si cette propriété est vraie pour ce modèle. Les deux ouvrages de référence qui détaillent ces techniques sont : [Clarke
et al
, 1999] et [Bérardet al
, 2001].Le principe du
model-checking
est d’examiner tous les scénarios et les comportements possibles du système à travers son modèle tout en parcourant l’ensemble des états atteignables. Ainsi, cette technique permet de s’assurer qu’aucun des états ne viole les propriétés à vérifier. Ces propriétés comme par exemple la recherche d’une situation de blocage sont à formaliser lors la phase de modélisation. Des méthodes d’analyse automatique du modèle permettent de vérifier ces propriétés et de parcourir les différents états du système. Ces méthodes sont implémentées dans des outils spécifiques : les model-checkers. Ces derniers peuvent générer un contre-exemple, c'est-à-dire une trace du chemin d’exécution ayant mené à un état dans lequel une des propriétés à vérifier n’est pas respectée. L’analyse de cette trace, souvent en utilisant un simulateur, permet de détecter plus facilement l’origine de la défaillance [Rushby, 2002]. Le model-checking permet alorsune vérification formelle exhaustive des propriétés sur le modèle du système [Ortmeier
et al
, 2003]. Les trois model-checker connus et souvent utilisés sont :PRISMPRISMPRISMPRISM
développé à l’Université de Birmingham par l’équipe de Marta Kwiatkowska,SMVSMVSMVSMV
développé par les laboratoires Cadence de Berkeley, etUPPAALUPPAALUPPAALUPPAAL
développé par une collaboration entre le département d’Information Technology de l’université d’Uppsala (Suède) et le département de Computer Science de l’université D’Aalborg au Danemark [Evrot, 2008].Les techniques de vérification par
model-checking
ont l’avantage d’avoir un processus complètement automatisé, à partir du moment où l’utilisateur fournit les modèles formels des propriétés et du système à vérifier. Néanmoins, plusieurs verrous rendent l’utilisation de ces techniques à une échelle industrielle un peu difficile. Le problème bien connu est celui de l’explosion combinatoire qui restreint l’utilisation du model-checking à des systèmes de petite taille. En effet, la taille des structures de données croît très rapidement si les paramètres du système augmentent. L’algorithme de vérification est alors contraint par la puissance des calculateurs disponibles actuellement. Une des solutions consiste à utiliser un raisonnement compositionnel. Il s’agit en effet de vérifier chaque composant du système de façon indépendante, puis de conclure sur la correction de la composition des composants entre eux. Le système n’est plus vérifié dans son ensemble mais composant par composant. Ceci engendre deux contraintes :(1)(1)(1)(1)
pouvoir définir les propriétés locales qu’un composant doit respecter ;(2)(2)(2)(2)
prouver que la conformité des composants aux propriétés locales implique la conformité de l’ensemble du logiciel aux propriétés globales.Les techniques de vérification formelles que nous venons de décrire nous permettent de détecter rapidement les erreurs après la phase d’analyse et la phase de conception du cycle de vie du logiciel (cf. Fig.2.17).