1.2 L’ingénierie système : contexte académique
1.2.2 La vérification des exigences
Si le rôle de la spécification est la réécriture des besoins des clients d’une façon claire et précise. La vérification a pour rôle de vérifier que les exigences, résultantes de la spécifica- tion, sont respectées durant tout le cycle de développement. Son objectif est de détecter les erreurs introduites dans chaque étape de développement. La vérification répond à la question : "Faisons-nous le produit correctement ?". Selon la norme ISO 9000, la vérification consiste à : Définition 1.4 [ISO 2000] La confirmation par des preuves tangibles que les exigences spé- cifiées ont été satisfaites.
A partir de cette définition, on peut constater que la vérification utilise des preuves tan- gibles, c.à.d. des méthodes, pour déterminer si les exigences sont satisfaites ou non. Nous présentons, dans la section suivante, un aperçu de la littérature des différentes méthodes de vérification.
1.2.2.1 Les méthodes de vérification
Une méthode de vérification consiste à s’assurer que le système satisfait une exigence (pro- priété). Les méthodes de vérification les plus utilisées, dans la littérature, sont : le test, la simu- lation et les méthodes formelles.
1.2.2.1.1 Le test
Le test permet de détecter les erreurs d’un système par rapport à un ensemble de scénarios définis antérieurement [Beizer 2003]. De ce fait, cette méthode est loin d’être exhaustive. Le test est pratiqué généralement après l’intégration du système, une fois que ce dernier est opéra- tionnel. La correction des erreurs détectées à ce stade de développement (intégration), reste la plus coûteuse [Boehm et al. 1981]. Néanmoins, cette méthode de vérification reste la plus utili- sée dans l’industrie [Bjørner et Havelund 2014], car elle peut être réalisée sur des systèmes de taille importante. Elle permet aussi de vérifier le système réel et pas seulement une abstraction de celui-ci, comme dans le cas de la simulation ou des méthodes formelles.
1.2.2.1.2 La simulation
La simulation consiste à reproduire le comportement d’un système afin de vérifier son bon fonctionnement. Le comportement simulé est capturé sous forme de modèles abstraits qui
sont, ensuite, exécutés sur des plateformes dédiées. La simulation consiste, alors, à faire des expérimentations sur des modèles abstraits [März et al. 2010]. En effet, l’analyste peut jouer des scénarios sur le simulateur afin de vérifier les performances du système.
Comme le test, la simulation peut être utilisée pour vérifier des systèmes de taille réelle, ce qui justifie son importante utilisation dans l’industrie. Mais, contrairement au test, la simulation peut être pratiquée dans des étapes en amont à l’implémentation et à l’intégration. Cela permet de détecter les erreurs avant que le système ne soit implémenté et ainsi réduire les coûts de correction. En revanche, la simulation souffre de plusieurs inconvénients comme le degré de réalisme ou granularité du simulateur. En effet, elle ne couvre pas la totalité du comportement du système, ce qui limite le nombre de scénarios vérifiables. De ce fait, la simulation n’est pas exhaustive.
1.2.2.1.3 Les méthodes de vérification formelle
Les méthodes formelles, telle que définies parBjørner et Havelund[2014], sont des tech- niques basées sur les mathématiques. Elles permettent de vérifier formellement des spécifi- cations écrites en langages formels. Elles assurent que le système est correct en vérifiant un ensemble de propriétés. Elles donnent, ainsi, une cartographie des propriétés satisfaites et non satisfaites du système développé. Le caractère mathématique de ces méthodes, les rend plus précises et exhaustives comparées aux tests [Bennion et Habli 2014] et à la simulation. Ainsi, ces techniques sont de plus en plus utilisées pour la vérification des systèmes actuels. Mais leur adoption dans l’industrie souffre de plusieurs obstacles [Bjørner et Havelund 2014], malgré les résultats encourageants de certaines études [Bennion et Habli 2014]. Les méthodes formelles sont de deux types : le Model-Checking et le Theorem-Proving.
Le Model-Checking. [Schnoebelen et al. 1999,Baier et al. 2008] est une méthode for- melle purement automatique, généralement supportée par un outil informatique "le Model- Checker". Elle consiste à vérifier automatiquement les propriétés souhaitées sur une spécifi- cation du système. Le système est généralement modélisé par des machines à états. Les pro- priétés à vérifier sont écrites dans une logique temporelle. Puis, sur la base des spécifications du système et des propriétés, le Model-Checker explore tout l’espace d’états. Il vérifie dans chaque état la satisfaction de la propriété désirée. Si la propriété est violée, le Model-Checker retourne un contre-exemple illustrant la trace de l’erreur, i.e, la succession d’états qui violent la propriété [Schnoebelen et al. 1999]. Cependant, pour les systèmes de taille importante, cette exploration exhaustive d’états peut dépasser la capacité des machines (ordinateurs), ce qui fait que la vérification échoue. Ce problème est connu sous le nom de l’explosion de l’espace des états.
Le Model-Checking est très utile pour la vérification des systèmes critiques complexes [Ben- nion et Habli 2014,Mesli-Kesraoui et al. 2016b;a]. En revanche, le problème de l’explosion de l’espace des états reste à ce jour, un vrai obstacle pour son adoption dans l’industrie. Afin d’évi-
1.2. L’ingénierie système : contexte académique 17
ter cette explosion de l’espace des états, plusieurs techniques sont proposées dans la littérature comme : les BDD, les SAT, l’abstraction et la symétrie [Xin-feng et al. 2009].
UPPAAL [Larsen et al. 1997]13est un exemple de Model-Checker, utilisé pour la vérifica- tion formelle des systèmes temporisés. Le Model-Checker SPIN [Holzmann 2004]14est utilisé pour la vérification des systèmes concurrents. Roméo [Gardey et al. 2005]15 est un Model- Checkerpour la vérification des systèmes temps réel modélisés par des réseaux de Petri.
Theorem-Proving. Les langages axiomatiques sont généralement vérifiés par le Theorem- Proving[Alagar et Periyasamy 2011]. Le Theorem-Proving est une méthode formelle basée sur les logiques mathématiques. Ces logiques sont utilisées pour spécifier le système et ses proprié- tés attendues (exigences). Ensuite, certaines règles d’inférence et axiomes sont appliqués afin de déduire et de prouver les propriétés à partir de la spécification du système. Ce procédé ne souffre pas du problème de l’explosion de l’espace des états, mais, selon l’expressivité de la logique utilisée, le Theorem-Proving peut être entièrement automatique ou nécessiter une in- tervention humaine [Almeida et al. 2011]. Cette technique requiert de l’expérience et de la connaissance formelle. Si la logique utilisée est moins expressive, comme la logique du pre- mier ordre par exemple, la construction de la preuve est entièrement automatique. C’est le cas par exemple du theorem prover ACL2 [Kaufmann et Moore 1996]. Par contre, si la logique est plus expressive, comme la logique d’ordre supérieur, l’automatisation de la preuve est partielle. Comme il n’existe pas de procédures de décision capables de prouver certaines propriétés dans cette logique [Almeida et al. 2011], l’assistant de preuve nécessite l’intervention de l’analyste pour conduire la preuve.
Isabelle/HOL [Nipkow et al. 2002] est un assistant de preuve pour la logique d’ordre su- périeur. PVS [Owre et al. 1999] est un langage de spécification formel et un démonstrateur de théorèmes. Why3 [Bobot et al. 2011] est une plateforme de vérification de programmes basée sur le langage de spécification WhyML. L’idée derrière Why3 est de "fournir autant que pos- sible d’automatisation"[Bobot et al. 2011]. En effet, le langage WhyML, basé sur la logique du premier ordre, est transformé aux formats d’entrées de différents démonstrateurs de théo- rèmes (PVS, Coq, Z3 ...). Les résultats montrent que why3 donne une meilleure performance de vérification que d’autres démonstrateurs de théorèmes, concernant le nombre d’obligations de preuves chargées [Mentré et al. 2012].
Après avoir présenté le contexte théorique de nos travaux de thèse, nous présentons, dans les sections suivantes, le contexte industriel et l’état de l’art technique du projet. Nous évoque- rons, ensuite, la problématique liée à nos travaux de thèse et les verrous scientifiques qui en ressortent.
13. http ://www.uppaal.org/
14. http ://spinroot.com/spin/whatispin.html 15. https ://romeo.rts-software.org/