SlideShare une entreprise Scribd logo
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
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
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
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
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
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
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

Contenu connexe

Tendances

Systeme embarque
Systeme embarqueSysteme embarque
Systeme embarque
Mohammed TIGHREMT
 
Cours ALGR M1.pdf
Cours ALGR M1.pdfCours ALGR M1.pdf
Cours ALGR M1.pdf
KhemissaSahraoui
 
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriUML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouri
Mansouri Khalifa
 
Igl cours 3 - introduction à uml
Igl   cours 3 - introduction à umlIgl   cours 3 - introduction à uml
Igl cours 3 - introduction à uml
Mohammed Amine Mostefai
 
réseaux de neurones artificiels
réseaux de neurones artificiels réseaux de neurones artificiels
réseaux de neurones artificiels
Oussama Werfelli
 
Chp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGLChp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGL
Lilia Sfaxi
 
Comprendre l’intelligence artificielle [webinaire]
Comprendre l’intelligence artificielle [webinaire]Comprendre l’intelligence artificielle [webinaire]
Comprendre l’intelligence artificielle [webinaire]
Technologia Formation
 
Systèmes d'Exploitation - chp6-synchronisation
Systèmes d'Exploitation - chp6-synchronisationSystèmes d'Exploitation - chp6-synchronisation
Systèmes d'Exploitation - chp6-synchronisation
Lilia Sfaxi
 
La méthode z validation
La méthode z validation La méthode z validation
La méthode z validation
Sid Ahmed Benkraoua
 
Programmation de systèmes embarqués : Systèmes temps réel et PRUSS
Programmation de systèmes embarqués : Systèmes temps réel et PRUSSProgrammation de systèmes embarqués : Systèmes temps réel et PRUSS
Programmation de systèmes embarqués : Systèmes temps réel et PRUSS
ECAM Brussels Engineering School
 
Programmation de systèmes embarqués : Introduction aux systèmes embarqués
Programmation de systèmes embarqués : Introduction aux systèmes embarquésProgrammation de systèmes embarqués : Introduction aux systèmes embarqués
Programmation de systèmes embarqués : Introduction aux systèmes embarqués
ECAM Brussels Engineering School
 
Projet de fin d'etude sur le parc informatique
Projet  de fin d'etude sur le parc informatiqueProjet  de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatique
Hicham Ben
 
Intelligence Artificielle - Algorithmes de recherche
Intelligence Artificielle - Algorithmes de rechercheIntelligence Artificielle - Algorithmes de recherche
Intelligence Artificielle - Algorithmes de recherche
Mohamed Heny SELMI
 
Présentation pfe
Présentation pfePrésentation pfe
Présentation pfe
Abdelghafour Zguindou
 
Ia project Apprentissage Automatique
Ia project Apprentissage AutomatiqueIa project Apprentissage Automatique
Ia project Apprentissage Automatique
Nizar Bechir
 
Systeme embarque td1
Systeme embarque td1Systeme embarque td1
Systeme embarque td1
SinGuy
 
Introduction aux systèmes répartis
Introduction aux systèmes répartisIntroduction aux systèmes répartis
Introduction aux systèmes répartis
Heithem Abbes
 

Tendances (20)

Systeme embarque
Systeme embarqueSysteme embarque
Systeme embarque
 
Cours ALGR M1.pdf
Cours ALGR M1.pdfCours ALGR M1.pdf
Cours ALGR M1.pdf
 
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriUML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouri
 
Presentation,PFE
Presentation,PFEPresentation,PFE
Presentation,PFE
 
Igl cours 3 - introduction à uml
Igl   cours 3 - introduction à umlIgl   cours 3 - introduction à uml
Igl cours 3 - introduction à uml
 
réseaux de neurones artificiels
réseaux de neurones artificiels réseaux de neurones artificiels
réseaux de neurones artificiels
 
Chp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGLChp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGL
 
Comprendre l’intelligence artificielle [webinaire]
Comprendre l’intelligence artificielle [webinaire]Comprendre l’intelligence artificielle [webinaire]
Comprendre l’intelligence artificielle [webinaire]
 
Systèmes d'Exploitation - chp6-synchronisation
Systèmes d'Exploitation - chp6-synchronisationSystèmes d'Exploitation - chp6-synchronisation
Systèmes d'Exploitation - chp6-synchronisation
 
La méthode z validation
La méthode z validation La méthode z validation
La méthode z validation
 
Tp 1
Tp 1Tp 1
Tp 1
 
Prez PFE
Prez PFEPrez PFE
Prez PFE
 
Programmation de systèmes embarqués : Systèmes temps réel et PRUSS
Programmation de systèmes embarqués : Systèmes temps réel et PRUSSProgrammation de systèmes embarqués : Systèmes temps réel et PRUSS
Programmation de systèmes embarqués : Systèmes temps réel et PRUSS
 
Programmation de systèmes embarqués : Introduction aux systèmes embarqués
Programmation de systèmes embarqués : Introduction aux systèmes embarquésProgrammation de systèmes embarqués : Introduction aux systèmes embarqués
Programmation de systèmes embarqués : Introduction aux systèmes embarqués
 
Projet de fin d'etude sur le parc informatique
Projet  de fin d'etude sur le parc informatiqueProjet  de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatique
 
Intelligence Artificielle - Algorithmes de recherche
Intelligence Artificielle - Algorithmes de rechercheIntelligence Artificielle - Algorithmes de recherche
Intelligence Artificielle - Algorithmes de recherche
 
Présentation pfe
Présentation pfePrésentation pfe
Présentation pfe
 
Ia project Apprentissage Automatique
Ia project Apprentissage AutomatiqueIa project Apprentissage Automatique
Ia project Apprentissage Automatique
 
Systeme embarque td1
Systeme embarque td1Systeme embarque td1
Systeme embarque td1
 
Introduction aux systèmes répartis
Introduction aux systèmes répartisIntroduction aux systèmes répartis
Introduction aux systèmes répartis
 

Similaire à Cours1.pptx

Test logiciel
Test logicielTest logiciel
Test logiciel
Youness Boukouchi
 
Test de logiciels
Test de logiciels Test de logiciels
Test de logiciels
Bilel Abed
 
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
hbadir
 
Owf 2013 rii panorama leroy
Owf 2013 rii panorama leroyOwf 2013 rii panorama leroy
Owf 2013 rii panorama leroyPatrick MOREAU
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
Frederic Hardy
 
Bbl sur les tests
Bbl sur les testsBbl sur les tests
Bbl sur les tests
Idriss Neumann
 
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
Benoît de CHATEAUVIEUX
 
Ingénierie du test 0.9
Ingénierie du test 0.9Ingénierie du test 0.9
Ingénierie du test 0.9
Stéphane Salmons
 
05 - Realisation méthodologie agile.pptx
05 - Realisation méthodologie agile.pptx05 - Realisation méthodologie agile.pptx
05 - Realisation méthodologie agile.pptx
SteevePaladin
 
Radical Quality From Toyota to Tech - Devoxx France.pptx
Radical Quality From Toyota to Tech - Devoxx France.pptxRadical Quality From Toyota to Tech - Devoxx France.pptx
Radical Quality From Toyota to Tech - Devoxx France.pptx
Flavian Hautbois
 
PrésQL.pdf
PrésQL.pdfPrésQL.pdf
PrésQL.pdf
badrfathallah2
 
Contrôle de la qualité logiciel
Contrôle de la qualité logicielContrôle de la qualité logiciel
Contrôle de la qualité logiciel
Sylvain Leroy
 
Aql métriques logicielles
Aql métriques logiciellesAql métriques logicielles
Aql métriques logicielles
marwa baich
 
cours logiciels de simulation.docx
cours logiciels de simulation.docxcours logiciels de simulation.docx
cours logiciels de simulation.docx
ssuser0dbd4e
 
chapitre1 supervision industrielle.pdf
chapitre1     supervision industrielle.pdfchapitre1     supervision industrielle.pdf
chapitre1 supervision industrielle.pdf
MINKAIssam
 
Chap XII Analyse Numerique
Chap XII Analyse NumeriqueChap XII Analyse Numerique
Chap XII Analyse Numerique
Mohammed TAMALI
 
Qualite1
Qualite1Qualite1
Qualite1
Rachid Lajouad
 
Test unitaires
Test unitairesTest unitaires
Test unitaires
Mohamed Akrouh
 
Support POO Java Deuxième Partie
Support POO Java Deuxième PartieSupport POO Java Deuxième Partie
Support POO Java Deuxième Partie
ENSET, Université Hassan II Casablanca
 
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
Philippe Beraud
 

Similaire à Cours1.pptx (20)

Test logiciel
Test logicielTest logiciel
Test logiciel
 
Test de logiciels
Test de logiciels Test de logiciels
Test de logiciels
 
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
 
Owf 2013 rii panorama leroy
Owf 2013 rii panorama leroyOwf 2013 rii panorama leroy
Owf 2013 rii panorama leroy
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
 
Bbl sur les tests
Bbl sur les testsBbl sur les tests
Bbl sur les tests
 
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
 
Ingénierie du test 0.9
Ingénierie du test 0.9Ingénierie du test 0.9
Ingénierie du test 0.9
 
05 - Realisation méthodologie agile.pptx
05 - Realisation méthodologie agile.pptx05 - Realisation méthodologie agile.pptx
05 - Realisation méthodologie agile.pptx
 
Radical Quality From Toyota to Tech - Devoxx France.pptx
Radical Quality From Toyota to Tech - Devoxx France.pptxRadical Quality From Toyota to Tech - Devoxx France.pptx
Radical Quality From Toyota to Tech - Devoxx France.pptx
 
PrésQL.pdf
PrésQL.pdfPrésQL.pdf
PrésQL.pdf
 
Contrôle de la qualité logiciel
Contrôle de la qualité logicielContrôle de la qualité logiciel
Contrôle de la qualité logiciel
 
Aql métriques logicielles
Aql métriques logiciellesAql métriques logicielles
Aql métriques logicielles
 
cours logiciels de simulation.docx
cours logiciels de simulation.docxcours logiciels de simulation.docx
cours logiciels de simulation.docx
 
chapitre1 supervision industrielle.pdf
chapitre1     supervision industrielle.pdfchapitre1     supervision industrielle.pdf
chapitre1 supervision industrielle.pdf
 
Chap XII Analyse Numerique
Chap XII Analyse NumeriqueChap XII Analyse Numerique
Chap XII Analyse Numerique
 
Qualite1
Qualite1Qualite1
Qualite1
 
Test unitaires
Test unitairesTest unitaires
Test unitaires
 
Support POO Java Deuxième Partie
Support POO Java Deuxième PartieSupport POO Java Deuxième Partie
Support POO Java Deuxième Partie
 
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
 

Dernier

Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
Daniel Bedard
 
PROVINLAIT - Bâtiment et bien-être estival
PROVINLAIT - Bâtiment et bien-être estivalPROVINLAIT - Bâtiment et bien-être estival
PROVINLAIT - Bâtiment et bien-être estival
idelewebmestre
 
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
Institut de l'Elevage - Idele
 
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
Institut de l'Elevage - Idele
 
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Daniel Bedard
 
QCM de révision pour la haute qualité.pdf
QCM de révision pour la haute qualité.pdfQCM de révision pour la haute qualité.pdf
QCM de révision pour la haute qualité.pdf
ffffourissou
 
SRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdfSRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdf
Henri Gomez
 
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
Institut de l'Elevage - Idele
 
Rénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdfRénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdf
idelewebmestre
 
Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024
idelewebmestre
 
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
Institut de l'Elevage - Idele
 
S210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermiqueS210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermique
ALIIAE
 
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
Institut de l'Elevage - Idele
 

Dernier (13)

Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
 
PROVINLAIT - Bâtiment et bien-être estival
PROVINLAIT - Bâtiment et bien-être estivalPROVINLAIT - Bâtiment et bien-être estival
PROVINLAIT - Bâtiment et bien-être estival
 
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
 
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
 
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
 
QCM de révision pour la haute qualité.pdf
QCM de révision pour la haute qualité.pdfQCM de révision pour la haute qualité.pdf
QCM de révision pour la haute qualité.pdf
 
SRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdfSRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdf
 
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
 
Rénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdfRénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdf
 
Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024
 
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
 
S210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermiqueS210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermique
 
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
 

Cours1.pptx

  • 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