Cours1.pptx

Cours1.pptx
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
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
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
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
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
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
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
CYCLE DE VIE D'UN LOGICIEL 8
COÛT DE LA CORRECTION DE BUGS 9
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
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
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
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
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
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
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
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
ENTRAVES  Erreur : Manifestation Faute dans système  Défaillance : Manifestation Erreur sur service  faute -> erreur -> défaillance -> faute -> erreur -> … 18
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
MODEL CHECKING EXEMPLE: FEU DU TRAFIC 42 Etats et transitions du système
SPÉCIFICATION RSL (RAISE SPECIFICATION LANGUAGE) 43
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
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
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
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

Cours1.pptx

Check these out next

Cours1.pptx

Recomendados

Más contenido relacionado

Similar a Cours1.pptx(20)

Último(20)

Cours1.pptx