Le cours sur les méthodes formelles présente leur rôle crucial dans la modélisation, la spécification et la vérification des systèmes informatiques, face à la complexité croissante de ces derniers. Il aborde des concepts tels que la sûreté de fonctionnement, les étapes de développement d'un logiciel, ainsi que des exemples illustrant des échecs notables dus à des bugs. Les méthodes formelles, basées sur des outils mathématiques, se distinguent par leur exhaustivité et leur efficacité dans la vérification des systèmes, malgré une phase de conception plus longue.

1. MÉTHODES FORMELLES
COURS1: INTRODUCTION
Sana Younes Dridi
younessana@yahoo.fr
1
Faculté des Sciences de Tunis
Département des Sciences de l’Informatique
Section Mastère 1 Info

2. PRÉSENTATION
 Ce cours intitulé:
 Méthodes formelles
 Formal methods
 L'objectif principal est d'introduire des méthodes
formelles et présenter leurs utilisation pour:
 La modélisation
 La spécification des systèmes informatiques
 La vérification
 Cours intégré: TD réalisé pendant les séances de
cours
 Evaluation: DS+Examen 2

3. PLAN DE L’INTRODUCTION
 Pourquoi a-t-on besoin de méthodes formelles?
 C’est quoi les méthodes formelles?
 C’est quoi la spécification formelle?
 C’est quoi la vérification formelle?
3

4. SÛRETÉ DE FONCTIONNEMENT
 Les systèmes logiciels deviennent de plus en plus
grand et complexe.
 Besoin de concevoir un système sûr.
 Sûreté de fonctionnement d'un système: ensemble
de propriétés qui permet à l'utilisateur d'avoir
confiance dans le service offert par le système.
 Besoin de méthodes rigoureuses pour la
vérification de la sûreté de fonctionnement.
 Parmis ces méthodes il y a les méthodes formelles
qui se basent sur des outils mathématiques.
4

5. BESOIN DE VÉRIFICATION
 IL est impossible de prévoir toutes les fautes
susceptibles d'affecter un système complexe.
 Un système complexe: un logiciel, satellites, transport
terrestre ou spatial, lanceurs…….
 Termes liés à la sûreté de fonctionnement (Attributs)
 Fiabilité: absence de défaillance sur un intervalle de temps
[0,T]
 Disponibilité: instantanée (transitoire), moyenne ou
stationnaire (asymptotique)
 Sécurité:
 absence d'évènements catastrophiques (exemple: dans les
transports),
 confidentialité des données (exemple: distributeur de monnaie)
 Maintenabilité: capacité à être réparé, temps moyen de
réparation 5

6. BESOIN DE VÉRIFICATION
 Enjeux de sureté de fonctionnement:
 Transports terrestres (métro, train), aériens, espace …
 Médical: télé-chirurgie, imagerie,…
 Téléphonie, commerce électronique
 Industriels: processus industriels, nucléaires, banques
6

7. ETAPES POUR DÉVELOPPER UN LOGICIEL
 Etude du système: cahier de charge avec
description des besoins et contraintes des clients
 Analyse fonctionnelle: identification des grands
modules (composants) utiles
 Spécification: définition du rôle de chaque module
 Codage: implémentation
 Intégration: assemblage des différents modules
 Test: vérification de la conformité des spécification
 Maintenance: permettre l'évolution du logiciel
7

8. CYCLE DE VIE D'UN LOGICIEL
8

9. COÛT DE LA CORRECTION DE BUGS
9

10. BUGS LOGICIELS
 Le bug est un dysfonctionnement du logiciel
 Il peut arriver:
 Lorsque la spécification du système est non respectée
 Ou bien lorsqu'un comportement inattendu est arrivé et
n'est pas couvert par la spécification
 Un bug peut couter très cher.
10

11. THERAC25 (1985-1987):
 Machine de radiothérapie pour le
traitement du cancer
 Evolution du model Therac20
 Au moins 5 vies humaines qui ont
reçu une dose massive d'irradiation
 Cause: bug dans le logiciel de
contrôle (écrit en assembleur).
11
Plus d’informations sur http://en.wikipedia.org/wiki/Therac-25

12. LA FUSÉE ARIANE VOL501
 Crash de la fusée européenne Ariane 5 en 1996:
explose 40s après le décollage
 Cause: bug dans le système informatique du pilotage
 dépassement de capacité d’une variable entière, réutilisation
d’un code source pour les modèles de fusées précédente
 Coût: 370 millions de dollars
12
Plus d’informations sur http://fr.wikipedia.org/wiki/Vol_501_d'Ariane_5

13. CRASH AT&T
 Coupure du réseau AT&T
pendant 9h dans une grande
partie des USA, en 1990
 5 millions d’appels bloqués
 Coût: plusieurs centaines de
millions de dollars
 Cause: bug dans le système de
contrôle des switchs (mauvaise
interprétation d’un break dans
du code C)
 Résolution: revenir à la version
précédente du logiciel
13
Plus d’informations sur http://www.phworld.org/history/attcrash.htm

14. EXEMPLE
int abs( const int x)
{ int y;
if (x < 0)
y=-x;
else
y=x;
return y;
}
 Que fait ce code? est ce qu'il contient une erreur?
14

15. EXEMPLE
15
int abs( const int x)
{ int y;
if (x < 0)
y=-x;
else
y=x;
return y;
}
 Calcul du valeur absolue en C
 Valeur entière entre -231 et 231-1 sur un processeur
32 bits
 Et si x = 231

16. EXEMPLE DANS JDK DE SUN
 Dans java.util.Arrays, il y a ce programme de recherche dichotomique
dans un tableau trié
 Il est où le bug?
public static int binarySearch(int[] a, int key) {
int low = 0;
int high = a.length - 1;
while (low <= high) {
int mid = (low + high) / 2;
int midVal = a[mid];
if (midVal < key)
low = mid + 1
else if (midVal > key)
high = mid - 1;
else
return mid; // key found
}
return -(low + 1); // key not found.
}
16

17. EXEMPLE DANS JDK DE SUN
 public static int binarySearch(int[] a, int key) {
int low = 0;
int high = a.length - 1;
while (low <= high) {
int mid = (low + high) / 2;
int midVal = a[mid];
if (midVal < key)
low = mid + 1
else if (midVal > key)
high = mid - 1;
else
return mid; // key found
}
return -(low + 1); // key not found.
}
si low + high>231-1
 En java ceci throws l'exception ArrayIndexOutOfBoundsException
 Ce bug a impacté plusieurs utilisateurs de Java
 La solution c'est de remplacer l'instruction en rouge par:
 int mid = low + ((high - low) / 2); 17

18. ENTRAVES
 Erreur : Manifestation Faute dans système
 Défaillance : Manifestation Erreur sur service
 faute -> erreur -> défaillance -> faute -> erreur -> … 18

19. EXEMPLE D’ENTRAVES
 Considérons le code suivant :
int a, b, x, y, k, ...
...
if (a == b) {
...
x = a - b;
}
if (k == 1) y /= x;
 Supposons que l’instruction `x = a - b;‘ soit une faute (il fallait
écrire, disons, `x = a + b;’).
 Si lors d’une exécution, a et b ne sont pas égaux à chaque fois
que ce bloc est exécuté, il n’y aura peut être pas d’erreur (malgré
la présence de la faute).
 Dans le cas contraire, si k ne prend pas la valeur 1 lors de cette
exécution, il n’y aura pas de défaillance (malgré l’erreur).
 Dans le cas contraire, on divise par 0 et on a effectivement une
défaillance
19

20. EXEMPLE D’ENTRAVES
 Système considéré: un code dans un noeud
(commutateur, routeur, …) d’un réseau de
télécommunications.
 Dans ce code, le programmeur a écrit `i = 0;‘ au lieu de
`i = 1;’, qui était l’instruction correcte. Il y a donc une
faute dans le système.
 A un moment particulier, l’ordinateur exécute cette
instruction, et, suite à un certain calcul, un tampon est
dimensionné à 10 au lieu d’être dimensionné à 100 ; on
a donc une erreur.
 Les conditions d’utilisation du réseau font
qu’exceptionnellement, ce jour-là, la charge est telle que
le tampon reçoit un trafic trop important. Il y a alors trop
de pertes (plus que les niveaux maximaux spécifiés) :
on a une défaillance.
20

21. TEST DU LOGICIEL
 Quand: après codage
 But: trouver des erreurs
 Deux types de test:
 Test statique: lire et faire lire et faire analyser le code
par un outil d'analyse
 Test dynamique: faire exécuter le programme sur un
ensemble de données significatives
21

22. TEST STATIQUE
 S'effectue avant l'exécution
 Test des erreurs les plus courantes
 Initialisation des variables
 Validité des prédicats dans les conditionnelles (=, <, ≤, etc …)
 Bornes inferieures et supérieures des tableaux
 Vérification des allocation dynamiques(allocation/
désallocation)
 Passages des paramètres dans les fonctions/méthodes
 Vérification des accolades dans les boucles
 Vérification des parenthèses dans les expressions
booléennes
 Traitement des exceptions
 50% des erreurs sont des erreurs de logique et de
programmation 22

23. TEST DYNAMIQUE
 Entrée: jeux de tests (ensemble de données pour
tester une partie ou tous le logiciel)
 Difficultés: quels sont les bon jeux de test,
automatisation
 Quand arrêter le test
 Le test statique ou dynamique n'est pas suffisant:
besoin de méthodes de vérification avant
l'implémentation
23

24. RÉSUMÉ: TECHNIQUES DE VÉRIFICATION
 Test statique ou Inspection manuelle du code
 Pas d’exécution du code.
 Inconvénient: les erreurs subtiles sont difficiles à détecter,
toutes les erreurs ne sont pas détectées.
 Test dynamique:
 Basée sur l’exécution du code, qu’on soumet à différents
scénarios.
 Inconvénient: temps, méthode non-exhaustive, en général
plus de temps est passé à faire du test qu’à concevoir le
système, peut détecter la présence d’une erreur mais pas son
absence.
 Dijkstra (1970) : Program testing can be used to show the
presence of bugs, but never to show their absence!
 Méthodes formelles:
 Basée sur des outils mathématiques.
 Inconvénient: phase de conception plus longue.
 Avantage: exhaustivité, efficacité.
24

25. PLAN DE L’INTRODUCTION
 Pourquoi a-t-on besoin de méthodes formelles?
 C’est quoi les méthodes formelles?
 C’est quoi la spécification formelle?
 C’est quoi la vérification formelle?
25

26. LES MÉTHODES FORMELLES?
 Utiliser la logique mathématique pour vérifier la
sûreté de fonctionnement des systèmes (logiciels et
matériels)
26

27. EXEMPLES D'USAGE INDUSTRIEL DES
MÉTHODES FORMELLES
27
 Un survey sur l'utilisation des méthodes formelles en
industrie montre qu'elles sont utilisées dans le domaine
de transport (16%) et dans le secteur de finance (12%)
Formal methods: Practice and experience Jim Woodcock,
Peter Gorm Larsen Juan Bicarregui John Fitzgerald
 Métro 1: sans conducteur, le métro doit s'arrêter dans
les gares à des points précis
 Métro 14: vérification est réalisée par la méthode B,
beaucoup d'erreurs ont été corrigés.
 Aucun bug n'a été trouvé dans la phase de test
 Aucune panne n'a été signalée depuis sa mise en fonction
depuis 1998
 OrlyVal - Navette sans conducteur à l'aéroport d'Orly:
vérifiée de la même manière que le métro 14. Elle est
opérationnelle depuis 2007

28. PLAN DE L’INTRODUCTION
 Pourquoi a-t-on besoin de méthodes formelles?
 C’est quoi les méthodes formelles?
 C’est quoi la spécification formelle?
 C’est quoi la vérification formelle?
28

29. SPÉCIFICATION FORMELLE
 Pour la description du système et des propriétés
qu’il doit les vérifier.
 Expression dans un langage formel à syntaxe et
sémantique précises du système à développer
 La spécification formelle est effectuée dans la
phase d'analyse
 Spécification du rôle de chaque module.
 Il y a plusieurs formes selon la nature du système
 Parmi les langages de spécification formelle:
 Machine d’états fini, automates. logiques, méthode Z,
méthode B, algèbres de processus, les réseaux de pétri
29

30. FORMALISMES DE MODÉLISATION DES
SYSTÈMES
 Automates (fini et infini)
 Automates temporisés: le temps est spécifié dans le
modèle
 Réseaux de Pétri:
 Les réseaux de Pétri sont apparus en 1962, dans la
thèse de doctorat de Carl Pétri.
 Logiques modales
 Modalités: traiter les différents schémas de
raisonnement
 Algèbre de processus
30

31. EXEMPLE SIMPLE DE SPÉCIFICATION
FORMELLE
31
 Dans une station de train, il y a deux signaux
entrants S1 et S2 pour deux routes qui ne doivent
jamais être actifs en même temps.
 Une spécification formelle de cette propriété peut
être exprimée par cette formule logique
 S1 et S2 sont deux variables booléennes qui
représentent l'états des deux signaux. Elles sont
true si les signaux sont actifs false sinon
 La formule signifie que sur tous les états
atteignables du système, toujours S1 et S2 ne sont
vrais en même moment

32. PLAN DE L’INTRODUCTION
 Pourquoi a-t-on besoin de méthodes formelles?
 C’est quoi les méthodes formelles?
 C’est quoi la spécification formelle?
 C’est quoi la vérification formelle?
32

33. VÉRIFICATION
 S'assurer que le système fonctionne correctement
 Preuve de propriété de sûreté de fonctionnement
sur un modèle du système
 Technique de preuve formelle: model checking,
preuve de théorème (theorem proving),
 D'autres techniques de vérification: simulation,
Model checking: Le système vérifie-t-il la propriété P
Si la propriété n'est pas vérifiée, corriger le système avant sa construction
33

34. VÉRIFICATION FORMELLE
Appliquée pour les :
 Software (génie logiciel): construction des logiciels
 Hardware (matériel): construire des matériels
(ordinateurs)
 Où se situe exactement dans la procédure vérification
34

35. APPROCHE GÉNÉRALE
 Spécifier le système à vérifier
 Vérifier certaines propriétés sur cette spécification
 Raffiner la spécification en cas de besoin
 Plusieurs des outils de vérifications formels
 Les pluparts sont disponibles gratuitement
35

36. VÉRIFICATION FORMELLE VS SIMULATION
 Vérification par simulation:
 On produit stimuli d'entrée aléatoires ou spécifiques à
une fonctionnalité particulière
 On compare les résultats de sorties avec les résultats
attendues
 Pb: non exhaustive pas de garantie pour les séquences
non simulées
 Vérification formelle:
36

37. VÉRIFICATION FORMELLE VS SIMULATION
 Vérification formelle est exhaustive pour certaine
propriété et peut produire un contre exemple en cas
d'échec
 Simulation: peut s'appliquer sur des gros systèmes
 Vérification formelle:
 Très gourmande en mémoire: Problème d'explosion
d'espace d'états
 Taille de mémoire est liée à la taille des systèmes à
vérifier
 Il y a les structures de données BDD (Binary Decision
Diagram)
 Ce sont deux techniques complémentaires: la
vérification formelle et la simulation 37

38. APPROCHES DE VÉRIFICATION FORMELLE
Parmi les approches de vérification on note:
 Preuve du théorème (theorem proving): une
relation entre une spécification et une
implémentation est vue comme un théorème à
prouver
 Model checking
 Test d'équivalence (Equivalence checking): test de
l'équivalence entre une spécification et une
implémentation du système.
 Exemple: vérification pour les circuits modélisés au
niveau RTL (Register Transfert Level). Cette
modélisation peut être codée avec VHDL ou Verilog 38

39. VÉRIFICATION PAR MODEL CHECKING
 Model checking est une méthode de vérification
formelle
 Principe: vérifier qu'un modèle satisfait une certaine
spécification formelle qui traduit une exigence du
système
 Le modèle est constitué d’un ensemble d'états et
de transitions qui décrivent l'évolution du système
 Les contraintes expriment comment le système doit
évoluer
 Les outils de vérification par model checking
s'appellent des model checkers
39

40. PROCESSUS DE MODEL CHECKING
 Un système qui doit
système un certain
nombre de contrainte
(exigences non-
formelles)
 Etape1: créer le modèle
du système et
formaliser les
contraintes suivant une
spécification formelle
 Etape 2: utiliser un
model checker pour
tester si le système
satisfait ou non la
propriété désirée
40

41. MODEL CHECKING
 Le model checker teste la propriété après une
exploration exhaustive sur tous les états
atteignables du système.
 Bien sur l'exploration exhaustive s'effectue dans le
cas des modèles finis.
 Le model checker retourne:
 Oui dans le cas où la propriété est satisfaite
 Non sinon avec un contre exemple (une description de
l'exécution qui a menée à l'état qui ne satisfait pas le
propriété)
41

42. MODEL CHECKING EXEMPLE: FEU DU TRAFIC
42
Etats et transitions du système

43. SPÉCIFICATION RSL (RAISE SPECIFICATION
LANGUAGE)
43

44. DESCRIPTION DU MODÈLE
 Spécification avec trois variables booléennes: red,
yellow et green
 Le système est composé de 8 états qui
correspondent aux 8 combinaisons possibles des
valeurs de 3 variables.
 L'état initial est (T,F,F) qui correspond:
red = T, yellow = F, green =F
 Il y a 4 transitions séparées par le symbole []
 Une transition est de la forme:
pre-condition ->post-condition
 Les variables qui ne sont pas mentionnées dans le
post-condition sont les variables qui ne changent
pas de valeurs après la transition
44

45. SPÉCIFICATION DES PROPRIÉTÉS
 Etats dangereux que le système ne doit
jamais atteindre (T,F,T) et (T,T,T)
 Le RSL model checker commence à partir
de l'état initial qui vérifie cette propriété et
explore tous les états du systèmes qui
doivent vérifier cette propriété.
45

46. QUE PEUT ON CONCLURE SUR LES
MÉTHODES FORMELLES
 Les méthodes formelles sont des bon moyens pour
améliorer la qualité du matériel et logiciel
 Beaucoup d'approches
 Beaucoup d'outils sont disponibles les pluparts sont
gratuit
46

47. PLAN DES COURS
Outils de modélisation formelle
 Automates
 Automates temporisés
 Les réseaux de petri
 Les réseaux de petri stochastiques
Outils de spécification formelle
 Les logiques de spécification formelles LTL, CTL CTL*,
 Extension probabiliste PCTL, CSL
Outils de vérification formelle
 Le model checking
 Le model checking stochastique
47