Méthodes de Conception et de Vérification

Francesco Belardinelli

Laboratoire IBISC

29 septembre 2017
Motivations

• Pourquoi utiliser des méthodes formelles pour la conception et le

développement du logiciel ?
Motivations

• Pourquoi utiliser des méthodes formelles pour la conception et le

développement du logiciel ?
• Pourquoi dépenser du temps et de l’argent à l’avance ?
Motivations

• Pourquoi utiliser des méthodes formelles pour la conception et le

développement du logiciel ?
• Pourquoi dépenser du temps et de l’argent à l’avance ?
• Pourquoi fréquenter un cours de méthodes de conception et vérification ?
Motivations

• Pourquoi utiliser des méthodes formelles pour la conception et le

développement du logiciel ?
• Pourquoi dépenser du temps et de l’argent à l’avance ?
• Pourquoi fréquenter un cours de méthodes de conception et vérification ?
• Est-ce qu’on peut réparer un système quand/s’il ne fonctionne pas ?
Motivations

• Notre dépendance du bon fonctionnement des systèmes TIC (Technologies

de l’Information et de la Communication) augmente rapidement.
Motivations

• Notre dépendance du bon fonctionnement des systèmes TIC (Technologies

de l’Information et de la Communication) augmente rapidement.
• On a estimé que nous utilisons 25 dispositifs TIC chaque jour (en 1995).
Motivations

• Notre dépendance du bon fonctionnement des systèmes TIC (Technologies

de l’Information et de la Communication) augmente rapidement.
• On a estimé que nous utilisons 25 dispositifs TIC chaque jour (en 1995).
• Les services tels que l’e-banking et la vente en ligne sont devenus une
réalité quotidienne.
Motivations

• Notre dépendance du bon fonctionnement des systèmes TIC (Technologies

de l’Information et de la Communication) augmente rapidement.
• On a estimé que nous utilisons 25 dispositifs TIC chaque jour (en 1995).
• Les services tels que l’e-banking et la vente en ligne sont devenus une
réalité quotidienne.
• La circulation d’argent via Internet est d’environ $1012 m par jour.
Motivations

• Notre dépendance du bon fonctionnement des systèmes TIC (Technologies

de l’Information et de la Communication) augmente rapidement.
• On a estimé que nous utilisons 25 dispositifs TIC chaque jour (en 1995).
• Les services tels que l’e-banking et la vente en ligne sont devenus une
réalité quotidienne.
• La circulation d’argent via Internet est d’environ $1012 m par jour.
• Environ 20% des coûts de développement des services de transport
(voitures, TGV, avions) est consacré aux systèmes de traitement de
l’information.
Motivations

• Notre dépendance du bon fonctionnement des systèmes TIC (Technologies

de l’Information et de la Communication) augmente rapidement.
• On a estimé que nous utilisons 25 dispositifs TIC chaque jour (en 1995).
• Les services tels que l’e-banking et la vente en ligne sont devenus une
réalité quotidienne.
• La circulation d’argent via Internet est d’environ $1012 m par jour.
• Environ 20% des coûts de développement des services de transport
(voitures, TGV, avions) est consacré aux systèmes de traitement de
l’information.
• Les fautes peuvent être coûteuses en termes de dégâts causés et de
profits/fonctionnalités perdus.
Motivations

• Notre dépendance du bon fonctionnement des systèmes TIC (Technologies

de l’Information et de la Communication) augmente rapidement.
• On a estimé que nous utilisons 25 dispositifs TIC chaque jour (en 1995).
• Les services tels que l’e-banking et la vente en ligne sont devenus une
réalité quotidienne.
• La circulation d’argent via Internet est d’environ $1012 m par jour.
• Environ 20% des coûts de développement des services de transport
(voitures, TGV, avions) est consacré aux systèmes de traitement de
l’information.
• Les fautes peuvent être coûteuses en termes de dégâts causés et de
profits/fonctionnalités perdus.
• On estime qu’une interruption de service de 24h dans le système de
réservation d’une compagnie aérienne engendrait sa faillite.
Motivations

• Notre dépendance du bon fonctionnement des systèmes TIC (Technologies

de l’Information et de la Communication) augmente rapidement.
• On a estimé que nous utilisons 25 dispositifs TIC chaque jour (en 1995).
• Les services tels que l’e-banking et la vente en ligne sont devenus une
réalité quotidienne.
• La circulation d’argent via Internet est d’environ $1012 m par jour.
• Environ 20% des coûts de développement des services de transport
(voitures, TGV, avions) est consacré aux systèmes de traitement de
l’information.
• Les fautes peuvent être coûteuses en termes de dégâts causés et de
profits/fonctionnalités perdus.
• On estime qu’une interruption de service de 24h dans le système de
réservation d’une compagnie aérienne engendrait sa faillite.
• La sécurité des applications critiques a besoin de vérification et de
validation.
Motivations

• Notre dépendance du bon fonctionnement des systèmes TIC (Technologies

de l’Information et de la Communication) augmente rapidement.
• On a estimé que nous utilisons 25 dispositifs TIC chaque jour (en 1995).
• Les services tels que l’e-banking et la vente en ligne sont devenus une
réalité quotidienne.
• La circulation d’argent via Internet est d’environ $1012 m par jour.
• Environ 20% des coûts de développement des services de transport
(voitures, TGV, avions) est consacré aux systèmes de traitement de
l’information.
• Les fautes peuvent être coûteuses en termes de dégâts causés et de
profits/fonctionnalités perdus.
• On estime qu’une interruption de service de 24h dans le système de
réservation d’une compagnie aérienne engendrait sa faillite.
• La sécurité des applications critiques a besoin de vérification et de
validation.
• Aujourd’hui, aucun système important n’est déployé qu’avec une
vérification et une validation systématiques.
Échecs de Logiciels
LSE Taurus (Transfer and Automated Registration of Uncertificated Stock, 1984)

• Programme pour transférer les communications à la Bourse de Londres du

papier à un système automatisé.
• Problème : objectif pas clair ⇒ dérive des objectifs et dépassement du
budget.
• Taurus a coûté £75m.
• Il a fait £500m de dommages.
• En 1993 il a été remplacé par CREST.
Échecs de Logiciels
Surdosage de Radiations du Therac-25 (1985-87)

• Appareil de radiothérapie pour le traitement des malades de cancer.

• Au moins 6 cas de surdosage (≈ 100×dose).
• Trois patients sont décédés.
• Source : verrouillage matériel de sécurité remplacé par verrouillages
logiciels . . .
• . . . mais, erreur de conception dans le logiciel de contrôle (race condition)
Échecs de Logiciels
Panne du Réseau Téléphonique AT&T (1990)

• Un problème à New York a engendré 9h de coupure de courant dans la

plupart du réseau téléphonique des EUs
• Coûts : plusieurs 100m de US$
• Source : mauvaise interprétation d’une instruction break en C
Échecs de Logiciels
LASCAD (London Ambulance Service Computer-Aided Dispatch, 1992)

• Attentes de 11h.
• Jusqu’à 30 personnes auraient pu mourir.

Leçon apprise ?
Échecs de Logiciels
LASCAD (London Ambulance Service Computer-Aided Dispatch, 1992)

• Attentes de 11h.
• Jusqu’à 30 personnes auraient pu mourir.

Leçon apprise ?
• Le 8 Juin 2011, le LAS a essayé de mettre en place un nouveau système
CAD (coût £18m).
• Lors de sa mise en œuvre le système a développé des problèmes techniques.
• Finalement, il a été remplacé par stylo et papier jusqu’à quand on est
revenu à l’ancien système.
Échecs de Logiciels
Aéroport de Denver - système de livraison des colis (1993)

• Les $186m de coût du système ont augmenté de $1.1m/j pendant les 9

mois de modifications et réparations.
Bug FDIV du Pentium 5 (1994)

• Bug dans l’unité de division (Floating point DIVision unit) du Pentium 5.

• Certains divisions produisaient des résultats incorrects (1 cas sur 9mrd)
4.195.835
• valeur correcte : 3.145.727
= 1, 333820449136241002
4.195.835
• valeur du P5 : 3.145.727
= 1, 333739068902037589
• Unités retirées du marché. Perte ≈450m US$.
• Enorme perte d’image pour Intel.
• Intel a commencé à investir en méthodes formelles.
1996 Lancement du Satellite Ariane 5 (vol 501)

Figure : Ariane 5G V88/501, 4 Juin 1996 12 :34 :06 UTC

1996 Lancement du Satellite Ariane 5 (vol 501)

Figure : Ariane 5G V88/501, 4 Juin 1996 12 :34 :43 UTC

Ariane 5

• Réutilisation du logiciel, mais le module 5 était plus rapide au décollage

que le module 4.
• La majeure vitesse a engendré la conversion d’un nombre à 64-bit dans un
entier à 16-bit (des considérations d’efficacité avaient conduit à désactiver
ce contrôle !).
• Buses dirigées par des données fausses.
• Trajectoire du vol incorrecte.
• Panne du système de pilotage inertiel primaire et de secours.
• Autodestruction : module et charge perdus !
• Coût : plus de 500m US$.
Importance de l’Exactitude du Logiciel

L’intégration des TIC dans les différentes applications augmente rapidement :

• systèmes intégrés (bio-informatique)
• protocoles de communication et securité
• systèmes de transport
⇒ de manière croissante leur fiabilité dépend du logiciel !
Les défauts peuvent être mortels et extrêmement coûteux :
• objets en production de masse
• systèmes de securité critiques
Vérification Automatique

Dans ce cours on va découvrir des techniques pour la vérification automatique.

• Validation : Le processus d’évaluation du logiciel afin de déterminer s’il

satisfait les exigences spécifiées. [IEEE-STD-610]
• C’est à dire, “construisons-nous le système correct” ?

• Vérification : le processus d’évaluation du logiciel pour déterminer si les

produits d’une phase de développement donnée satisfont les conditions
imposées au début de cette phase. [IEEE-STD-610].
• C’est à dire, “construisons-nous le système correctement” ?
Techniques de Vérification du Logiciel

Peer reviewing :
• technique statique : inspection manuelle du code, pas d’exécution du
logiciel.
• réalisée par une équipe d’ingénieurs qui, de préférence, n’a pas été
impliquée dans le développement du logiciel sous analyse.
• on détecte entre 31% et 93% de défauts avec une médiane de 60%
environ.
• une quelque forme de peer review est utilisée dans presque 80% de tous les
projets de génie logiciel.
• Problème : les erreurs subtiles (défauts de simultanéité et dans
l’algorithme) sont difficiles à découvrir.
Techniques de Vérification du Logiciel

Testing :
• technique dynamique dans laquelle le logiciel est exécuté.
• de 30% au 50% du coût des projets des logiciels est consacré au testing.
• la comparaison entre la sortie réelle du logiciel et la sortie telle qu’elle est
documentée dans la spécification du système est généralement effectuée
par des ingénieurs.
• seulement une petite partie des exécutions du logiciel est analysée.
• plus de temps et d’efforts sont consacrés à la validation qu’au codage.
• densité de défauts acceptée : environ 1 défaut pour 1.000 lignes de code.
A la recherche des bugs

Figure : Source : Baier, Katoen ; Principles of Model Checking, MIT Press, 2008.

• Les coûts de réparation d’un erreur dans le logiciel en phase d’entretien

sont environ 500 fois supérieur à ceux d’une correction en phase de
conception.
• Environ 50% de tous les défauts sont introduits lorsque du codage.
• Seulement 15% des erreurs sont détectées dans les phases initiales de
conception, alors que la plupart des erreurs sont détectées pendant le
testing.
Méthodes Formelles

Déscription intuitive :
• les méthodes formelles sont les ”mathématiques appliquées à la
modélisation et à l’analyse des systèmes TIC”.
Les méthodes formelles ont un grand potentiel pour :
• obtenir aussitôt une intégration de la vérification dans le processus de
conception du logiciel.
• fournir des techniques de vérification plus efficaces (couverture plus élevée)
• réduire le temps de vérification
Utilisation des méthodes formelles.
• Fortement recommandées par CEI, FAA et NASA pour les logiciels
critiques.
Les méthodes formelles devraient faire partie de la formation de
chaque informaticien et ingénieur en logiciel, tout comme la
branche appropriée des mathématiques appliquées est une partie
nécessaire de la formation de tous les autres ingénieurs.

• Exemple : ligne 14 du métro de Paris (Méthode B).

Techniques de Vérification Formelle pour la Propriété P

Méthodes déductives
• méthode : fournir une preuve formelle que P est vrai.
• outil : démonstrateur des théorèmes / assistant de preuve ou proof-checker
(Coq, Isabelle, Pandora)
• applicable si : le système est présenté sous forme d’une théorie
mathématique (par exemple, tableaux)
Model-checking
• méthode : contrôle systématique de P dans tous les états
• outil : model checker (Spin, NuSMV, UppAal, . . . )
• applicable si : le système génère un modèle fini de comportements

Simulation ou testing basé sur modèles

• méthode : tester P en explorant les comportements possibles.
• applicable si : le système définit un modèle exécutable.
Simulation et Testing

Procédure de base :
• prendre un modèle (simulation) ou une réalisation (testing)
• introduire certaines entrées (à savoir, des tests)
• observer la réaction et vérifier si c’est “désirable”
Inconvénients importants :
• le nombre de comportements possibles est très grand (voire infini)
• les comportements inexplorés peuvent contenir le bug fatal

À propos du testing . . .
“Le testing peut montrer la présence d’erreurs, pas leur
absence.”Dijkstra
Étapes de la Vérification Formelle

• Exactitude des programmes mathématiques (Turing, 1949)

• Technique basée sur la syntaxe pour les programmes séquentiels (Hoare,
1969)
I pour chaque entrée, est-ce qu’un logiciel génère la sortie correcte ?
I basée sur des règles de preuve compositionelles, exprimées dans la logique
des prédicats.

• Technique basée sur la syntaxe pour les programmes concurrents (Pnueli,

1977)
I on manipule des propriétés concernant les états de la computation
I fondée sur des règles de preuve exprimées en logique temporelle

• Vérification automatique de programmes concurrents

I approche basée sur les modèles au lieu des règles de preuve
I est-ce que le programme concurrent satisfait une propriété (logique)

donnée ?
Qu’est-ce que c’est le Model Checking ?

• Déscription informelle :
Le model checking est une technique automatisée qui, compte tenu d’un
modèle à états finis d’un système et une propriété formelle, vérifie
systématiquement si cette propriété est vraie dans (un état donné de) le
modèle.
Le Model Checking en Bref

• Nous voulons vérifier si un système S satisfait une propriété P.

• On construit un modèle MS “approprié” pour S, représentant toutes les
computations possibles de S.
• On définit une formule appropriée φP qui exprime la propriété P.
• On vérifie automatiquement si φP est satisfaite par MS : MS |= φP .
Le Prix Turing de l’ACM

• Alan Turing (1912-1954)

• Mathématicien, logicien, spécialiste de cryptologie
• Modèle de calcul : machine de Turing
Prix Turing 2007

Consultez : http ://www.acm.org/press-room/news-releases-2008/turing-award-07

(a) Edmund Clarke (b) Allen Emerson (c) Joseph Sifakis

(CMU, USA) (U. Texas, USA) (IMAG Grenoble, F)

• Justification du jury
Pour leurs rôles dans le développement du model-checking dans
une technologie de vérification très efficace, largement adoptée
dans les industries des matériels informatiques et des logiciels.
Quels sont les modèles ?

Systèmes de transitions :
• états marqués avec des propositions simples.
• relation de transition entre les états.
• transitions marquées par des actions pour faciliter leur composition.
Expressivité
• les programmes sont des systèmes de transitions
• les programmes multi-thread sont des systèmes de transitions
• les processus communicants sont des systèmes de transitions
• les circuits sont des systèmes de transitions
• Quoi d’autre ?
Quelles sont les propriétés ?

Exemples des propriétés

• le système peut atteindre une impasse ?
• deux processus peuvent se trouver simultanément dans un état critique ?
• en cas de terminaison, est-ce que le programme donne la sortie correcte ?
Logique temporelle
• Extension de la logique des propositions.
• Opérateurs modaux tels que  “toujours” et  “éventuellement”
• Interprétée sur des séquences d’états (linéaire) . . .
• . . . ou sur des arbres d’états infinis (branchement)
Une Affaire d’Université ? !
Consultez :

Figure : Intel i7 Core

• Vérification formelle utilisée comme méthode de validation primaire pour

le groupe d’exécution de base (core execution cluster, composante
responsable du comportement fonctionnel de l’ensemble des
micro-instructions).
• Testing abandonné completement.
NASA Deep Space-1

• Le model-checking a été appliqué à plusieurs modules de ce vaisseau

spatial
Le Model Checker Spin

process Inc = while true do if x < 200 then x := x + 1 od

process Dec = while true do if x > 0 then x := x − 1 od

process Reset = while true do if x = 200 then x := 0 od

Est-ce qu’il est toujours vrai que x est compris entre 0 and 200 ?
La Procédure du Model Checking

• Phase de modélisation
I modéliser le système à l’étude à l’aide du langage de description de modèle

du model checker utilisé

I comme test de cohérence, on peut d’abord effectuer quelques simulations
I formaliser la propriété à vérifier en utilisant le langage de spécification

• Phase d’exécution
I exécuter le model checker pour vérifier la validité de la propriété dans le

modèle
• Phase d’analyse
I propriété satisfaite ? ⇒ vérifier la propriété suivante (le cas échéant)
I propriété violée ? ⇒

1. analyser le contre-exemple généré par simulation

2. affiner le modèle, le design du modèle ou la propriété
3. répéter l’ensemble de la procédure
I pas assez de mémoire ? ⇒ essayer de réduire le modèle et tester à nouveau
Les Pros du Model Checking

• largement applicable (hardware, logiciels, systèmes de protocoles, ...)

• permet une vérification partielle (uniquement les propriétés les plus
importantes)
• pas orienté vers les scénarios les plus probables (comme le testing)
• en cas de violation des propriétés, un contre-exemple est fourni
• technologie potentiellement “pousser-le-bouton” (software-tools)
• intérêt industriel en hausse rapide
• fondements mathématiques exacts et intéressants
Les Inconvénients du Model Checking

• accent sur les applications basées sur les instruction de contrôle (moins sur
les données)
• le model checking est aussi “bon” que le modèle du système
• très puissant, en principe, mais difficile à maı̂triser et coûteux à utiliser à
l’échelle industrielle (étant donné la formation nécessaire).
• pour ces raisons utilisé maintenant principalement pour les systèmes
critiques.
• difficile à appliquer à des espaces d’états larges (state explosion problem).
• aucune garantie quant à l’exhaustivité des résultats
• impossible de vérifier des généralisations

Néanmoins :
• de plus en plus les systèmes informatiques sont essentiels à nos vies :
tendance croissante dans l’analyse et vérification des systèmes.
• le model-checking est une technique efficace pour révéler les erreurs
potentielles dans la conception des logiciels.
Exemples de Succès du Model Checking

• Sécurité : protocole Needham-Schroeder de cryptage

I erreur qui n’avait pas été découvert pendant 17 ans

• Systèmes de transport
I modèle de train contenant 10476 états

• Model checkers pour C, Java et C++

I développés (et utilisés) par Microsoft, Digital, NASA
I domaine d’application : drivers de périphériques

• Barrage néerlandais anti-tempête dans la Nieuwe Waterweg

• Logiciel de la génération actuelle / prochaine des véhicules spatiaux

I NASA Mars Pathfinder, Deep Space-1, JPL LARS groupe
Objectifs du Cours

1. Apprendre à modéliser un système réactif dans le formalisme des systèmes

multi-agents.
2. Apprendre à utiliser les logiques temporelles, épistémiques, et autres
langages de spécification.
3. Comprendre les principes de la vérification par model checking.
4. Apprendre à faire ces contrôles de la manière la plus efficace possible.
5. Identifier les situations où le model checking ne doit pas être utilisé.
Organisation du Cours

• Introduction au cours. Motivations. Connaissances préalables.

• Systèmes de Multi-agents

• Vérification by the model checker MCMAS

Matériaux d’étude

• Diapositives du cours et autres matériaux distribués pendant les cours.

• le cours est self-contained.

Références utiles, mais pas essentielles.

• Baier, Katoen ; Principles of Model Checking, MIT Press, 2008.
• Fagin et al., Reasoning about knowledge, MIT Press, 1995.
• Huth, Ryan ; Logic in Computer Science, CUP, 2005.
• Clarke, Grumberg, Peled ; Model Checking, MIT Press, 2000.