Chapitre 2 Définitions Et Classification Des Méthodes Formelles

Technique Formelle : Définition
On appelle Technique Formelle, l'association :
1. d'un langage à sémantique formelle. Ce langage permet

la description abstraite des objets programmes à
développer. Un programme écrit dans un langage formel
constitue une spécification (ou modèle) formelle du
système à concevoir.
2. un système de preuve permettant d'exprimer et de

prouver des propriétés sur les modèles (approche pour
vérifier la cohérence d'un système par rapport à sa
spécification). Il existe actuellement deux principales
techniques de preuve sur modèle
Méthodes Formelles - O.Belkahla Driss 1

 Ces méthodes sont structurées et naturellement
modulaires
 Elles permettent des raisonnements
 La syntaxe et la sémantique sont accompagnées de règles
de déduction (permettant de démontrer des propriétés)
 Par exemple on peut utiliser la logique classique (formules

mathématiques, quantificateurs, etc.)
 La syntaxe est celle des formules du calcul des prédicats
 La sémantique est donnée par la théorie des modèles (un
ensemble de valeurs muni de prédicats et de fonctions
satisfaisant les formules)
 Les règles de déduction sont celles de la logique du
premier ordre
Le système de preuve :
 Il permet la démonstration des propriétés relevantes du

système.
 Il travaille sur un modèle du système
 La preuve sur programme permet de s’assurer que le

modèle que nous avons réalisé se comporte de la bonne
façon, c’est à dire qu’il vérifie des propriétés exigées, qu’il
n’a pas de bugs
“Program testing can be used to show the presence of bugs, but never
show their absence” – Edsger W. Dijkstra

Systèmes de preuves – Historique
1. Les débuts : travail des logiciens cherchant à formaliser le
raisonnement logique et mathématique
 300 avant JC : le logicien Aristote réalise le premier système
formel
 Année 30 : programme d’Hilbert (tentative d’unification de
l’ensemble des concepts mathématiques par le biais de la
logique), travaux de Gôdel (Théorème d’incomplétude)
 ⇒ logique propositionnelle, logique du premier ordre,
logique temporelle, théorie de la démonstration...
2. Suite à l’invention des ordinateurs : utilisation de ces concepts

pour tenir des raisonnements mathématiques ⇒ les systèmes
d’inférence : Prolog, Systèmes experts...
3. Puis création de programmes permettant le raisonnement sur

les programmes
⇒ Vérification formelleMéthodes Formelles - O.Belkahla Driss 4
Exemple de vérification formelle
• Comment vérifier que l’identité (a + b)2 = a2 + b2 + 2(a *b) est
correcte ?
• Une vérification naïve : examiner toutes les valeurs possibles de a, à

les croiser avec toutes les valeurs possibles de b (recherche
exhaustive)
⇒ Si les domaines de a et de b sont grands, cette vérification peut être
très longue. Et si les domaines sont infinis (par exemple les réels),
cette vérification ne peut pas être exhaustive
• En vérification formelle, on utilise des valeurs symboliques et on

applique les règles qui régissent le + et l' *
Les règles

Spécifier pour modéliser
• L’étape de spécification force à comprendre

ce que doit faire chaque composant
• La spécification permet d’argumenter sur la

cohérence du composant
• La spécification permet d’énoncer des

propriétés sur le système avant même son
développement

Spécifier pour valider
• La validation consiste à se demander si le texte

formel « dit bien » ce que l'on veut qu'il dise, s'il
« traduit » bien la demande informelle faite par
celui qui commande le logiciel
• La validation ne peut pas être automatisée
• La spécification permet de poser les bonnes

questions afin de s’assurer de l’adéquation des
composants au cahier des charges

Spécifier pour programmer
• Une spécification est un contrat que le

programmeur doit respecter quand il
décide du comment
– critères de langages, bibliothèques…
– critères de complexité
– critères de généricité
• La spécification est une référence pour la

suite du développement
Spécifier pour vérifier
• Une spécification permet à chaque étape du

développement de vérifier que la réalisation du
système respecte les attentes initiales
– En conception :
Cet algorithme calcule-t-il bien ce que j’ai spécifié ?
– En intégration :
Ce programme réalise-t-il bien le composant initialement
spécifié (notamment en termes de fonctionnalités)

Exemple : ce programme est-il correct ?
début
c:=0;
répéter
si a mod 2 ≠ 0 alors c := c + b ;
a := a div 2;
b := b x 2;
jusqu’à a =1;
c := c + b;
fin

Spécifier
• Définir le quoi pas le comment !

– Nom
– Des données en entrée
– Des résultats en sortie
– Une post-condition
• La définition des résultats en fonction des données d’entrée
– Une pré-condition
• Les conditions nominales = conditions sous lesquelles
l’opération doit garantir que le résultat est bien celui attendu

Spécification + Programme  Vérification
Quoi :
nom : multiplication russe
données : a,b deux entiers
résultat : c le produit de a par b
Comment :
début
c:=0;
répéter
a := a div 2;
b := b x 2;
jusqu’à a =1;
c:=c+b;
fin

Quel langage pour spécifier
• Informel, Semi-formel…
• L’approche formelle consiste à utiliser un langage
formel syntaxiquement et sémantiquement bien
défini
– par opposition à une spécification en langage naturel
qui peut donner lieu à différentes interprétations
– Par opposition à une spécification semi-formelle (ex.
UML) qui dispose d’une syntaxe précise mais pas d’une
sémantique bien définie

L’approche formelle
• L’intérêt de cette approche est qu’elle oblige le

« spécifieur » à énoncer sans ambiguïté ce que doit faire
son programme
Ainsi les problèmes sont soulevés dès le début et non durant
l’étape de conception où l’on pourra se consacrer aux difficiles
problèmes de l’optimisation
• Elle permet par ailleurs de prouver formellement des

propriétés sur le système dès sa spécification (il n’est plus
utile d’attendre son implémentation pour réaliser des
tests exhaustifs)

Spécification formelle
c  multiplication russe (a,b) =
PRE
a ∈ NATURAL ∧ b ∈ NATURAL ∧ a ≠ 0
THEN
c := a x b
END
début
c:=0;
répéter
a := a div 2;
b := b x 2;
jusqu’à a =1;
c:=c+b;
fin
L’approche formelle
• Les méthodes formelles ne sont pas limitées à la

spécification
– Conception : par reformulation formelle on passe de la
spécification à du pseudo-code
– Codage : puis on génère automatiquement du code
exécutable
– Test Preuve : On prouve à chaque étape le respect des
spécifications initiales

A quelles étapes les spécifications et les méthodes
formelles peuvent-elles être utilisées ?
Analyse et spécification :
– Description formelle des concepts clés du problème (domaine
d’application)
– Spécification formelle de la solution (comportement du système)
– Prototypage
Conception architecturale et détaillée :

– Spécification formelle de l’interface des modules.
– Méthode rigoureuse de raffinement
Codification :
– Preuves de programmes
– Synthèse automatique du code
– Utilisation d’assertions
Tests
– Génération automatique des tests
Comment appliquer les MF ?
• Quel est votre problème ? Qu’est-ce que vous

voulez garantir ?
– Trouver une méthode formelle qui corresponde
• À votre domaine d’application
• À vos problèmes
• À vos contraintes de temps et de coûts
• …
• Comment les mettre en œuvre ?
– Les intégrer à votre cycle de développement
• Retour à moyen/long terme
• Par ex. : mettre à jour la spécification formelle quand la
spécification ou le système réalisé change
– Prendre les conseils d’un expert dans la méthode
choisie Méthodes Formelles - O.Belkahla Driss 18
Plusieurs Facteurs
• Domaines d’application / Problèmes possibles
– Quand utiliser cette approche ? Points sensibles à regarder
• Niveau d’expertise / Niveau d’intervention

– Nul (cliquer un bouton) / Moyen (écrire une spec formelle) / Elevé
(faire une preuve)
– Que faut-il faire (modèle, annotations, propriétés, …) ?
• Couverture du cycle de développement / Fidélité au logiciel

– À quelles étapes du cycle de développement ?
– Vérifications sur un modèle du logiciel ou le logiciel lui-même ?
• Disponibilité des outils / Niveau d’automatisme
• Expressivité : qu’est-ce que je peux prouver ?

Bénéfices d’une spécification formelle
“Devoir en arriver à une meilleure compréhension de l’élément à

spécifier en forçant l’analyste à être abstrait tout en étant précis à
propos des propriétés du système peut être plus gratifiant que
d’avoir le document de spécification lui-même.” [Wing90]
Impact positif de l’effort de formalisation :
• Spécifications explicites, précises, non-ambigues

• Base pour la mise en œuvre et pour des vérifications formelles
• Outils (manipulation, analyse, simulation, génération de tests)
• Base pour le développement des tests

Avantages des méthodes formelles
En plus des avantages de la précision et de la non ambiguïté
 Exploiter des outils de preuve et d’évaluation symbolique
 Ecrire assez facilement des maquettes (en prolog par

exemple)
 Vérifier automatiquement les spécifications
 Engendrer automatiquement des jeux de tests
 Il est toujours possible de raffiner en une spécification

plus détaillée, voir de faire une implémentation abstraite
Objectifs des méthodes formelles
• Re-formuler la spécification en utilisant les
mathématiques force à être précis
– Un moyen d’avoir des spécifications claires
– On explicite le « quoi » mais pas le « comment »
• Au passage : aussi crucial d’expliciter le « pourquoi »,
documentez !
• Avec des outils automatiques fournir des
preuves de fiabilité
– 60 à 80% du coût total est la maintenance (source
Microsoft)
– 20 fois plus cher de gérer un bug en production
plutôt qu’en conception
• Exemples célèbres : Pentium FDIV bug (Jan. 1995, pre-tax charge of
$475 million for Intel), Therac 25 (5 morts), Ariane 501 (~$220 million), …
Bugs célèbres
1.La sonde climatique Mars Polar Lander : La firme ayant reçu le
mandat de bâtir le système de navigation avait bien reçu toutes les
indications de la NASA, mais a décidé d’utiliser le système impérial de
mesure au lieu du système métrique. Une décision désastreuse,
l’appareil s’est écrasé 125 millions de dollars plus tard.
2.Le vol 501 d’Ariane 5 : Un bug informatique n’a jamais été décelé sur
ce satellite, jusqu’à ce qu’il soit envoyé dans l’espace. Précisément 36,7
secondes après son déploiement, une boule de feu a embrasé le ciel. La
perte estimée s’élève à 8,5 MILLIARDS de dollars. Tout un bug
http://esamultimedia.esa.int/docs/esa-x-1819eng.pdf
3.Logiciel comptable défaillant : Il y a quelques années, l’Agence de

traitement des pensions alimentaires d’Angleterre a demandé à EDS de
créer un système de gestion. Ce qu’EDS fit, mais la firme présenta un
produit horriblement complexe et truffé d’erreurs d’incompatibilité. Une
perte d’un milliard de dollars.
Bugs célèbres
4. Explosion d’un oléoduc russe: En 1982 en pleine Guerre froide, la CIA estimait
que l’Union soviétique était en train de voler de la technologie américaine. Pour
se défendre, les États-Unis conçurent un bogue informatique afin d’empêcher
l’Europe de l’ouest de s’approvisionner en gaz naturel à partir de l’URSS. Le
résultat fut un désastre financier.
5.Lundi noir : Certains se rappelleront qu’en 1987, une enquête sur les marchés
financiers a fait paniquer les investisseurs qui ont décidé de se départir rapidement de
leurs actions, mais les systèmes informatiques n’ont pas suivi. Le marché s’est alors
effondré.
6.L’accélérateur médical Therac-25: Cet appareil fut construit en France afin d’aider
dans le traitement par radiation. Malheureusement, le système d’exploitation du
Therac-25 fut conçu par un informaticien plutôt inexpérimenté. Conséquence: le rayon
d’électrons était si concentré qu’il a tué cinq patients.
7.Du double dosage pour Multidata Systems: Multidata System International a conçu
un logiciel destiné à calculer la quantité de radiation que des patients doivent recevoir.
Toutefois, ce logiciel avait certaines limitations et les médecins ont tenté de
contourner le problème en jouant quelque peu avec les données. Le logiciel n’a pas
aimé du tout, et a commencé à doubler la quantité de radiation aux patients. Inutile
de dire que dédommager les victimesMéthodes a coûté- O.Belkahla
Formelles très cher.Driss 24
Bugs célèbres
8. Où vas-tu, missile? : Pendant la guerre du Golfe en 1991, un système antimissiles
fut mis en place afin de protéger les troupes sur place. Mais un bug informatique
a fait en sorte que le système calculait mal le temps de réponse, et certaines
cibles s’en trouvèrent totalement ignorées. Beaucoup d’argent gaspillé, mais
beaucoup plus triste, une centaine de vies aussi.
9.La Troisième guerre mondiale évitée: Un satellite russe a causé tout un vent de
panique quand il a confondu quelques réflexions solaires pour une volée de missiles
provenant des États-Unis. Dieu merci, le lieutenant colonel Stanislav Petrov a réalisé à
temps qu’il s’agissait d’une erreur, évitant une catastrophe mondiale.
10.La sonde spatiale Mariner: Lorsqu’un programmeur a entré le code de navigation
dans le système de la sonde, il a omis d’y intégrer une ligne de code. L’ordinateur a
totalement perdu le contrôle en tentant de réparer les erreurs pendant la mise à feu.
Après 237 secondes bien comptées, le Centre de contrôle n’a pas eu le choix et a
procédé à la destruction complète de l’appareil. Adieu, 18,2 millions de dollars.
Source : http://www.topito.com/top-10-des-erreurs-de-programmations-les-plus-
couteuses-de-lhistoire

Classification des Techniques Formelles
suivant la sémantique
1. Les approches constructives (opérationnelles, basées

sur état explicite)
2. Les approches algébriques ou fonctionnelles

1. Les approches constructives (opérationnelles,

basées sur état explicite)
 se fondent sur une sémantique à état de type automate

 l'état est modifié par les opérations qui modélisent
l'aspect comportemental du système
 Les propriétés sont exprimées par des expressions
logiques sur les variables du système
 Exple : les Systèmes de Transitions Etiquetés (STE), les
réseaux de Petri (RdP), B...

1. Les approches constructives (opérationnelles,

basées sur état explicite)
2. Les approches algébriques ou fonctionnelles
 Sémantique définie par une algèbre

 variables et opérations sont définies suivant cette
algèbre
 le système est décrit par un ensemble d'équations
 Ensemble d’équations = description du comportement
 Exple : parmi les langages formels suivant cette
approche : Z, VDM, LOTOS, LUSTRE...
Rappel de la définition de TF
On appelle Technique Formelle, l'association :
1. d'un langage à sémantique formelle
2. un système de preuve

Systèmes de preuves en informatique
 Quelques échecs retentissants (comme par exemple la panne

du réseau téléphonique aux USA en 1989 ou la destruction du premier
exemplaire de la fusée Ariane 5 en 1996) ont achevé de convaincre
de l'impérieuse nécessité de vérifier certains logiciels ou
systèmes de contrôle-commande.
 Il existe plusieurs techniques pour effectuer de telles

vérifications, les principales étant :
le test
la démonstration automatique (Theorem Proving)
la vérification sur modèle (Model Checking)

 Le test : indispensable et permet de découvrir de nombreuses
erreurs, mais il ne peut pas être exhaustif et n'apporte donc que
des réponses partielles
 La démonstration automatique (Theorem Proving) : capable de

répondre à toutes les questions de vérification qui se posent en
pratique, mais sa mise en œuvre est souvent lourde et compliquée
et les outils actuels sont seulement capables d'assister un
ingénieur à qui revient la charge de construire la preuve
 La vérification sur modèle (Model Checking) : l'intermédiaire

entre le test et la démonstration : il s'agit d'une méthode
exhaustive et en grande partie automatique. Le travail de
l'ingénieur se limite à la construction d'un modèle formel du
système et à la formalisation des propriétés à vérifier

Deux techniques de preuves sur modèle :
1) Theorem Proving (TP) ou vérification par preuves
2) Model-Checking (MC) ou vérification exhaustive

1) Theorem Proving (TP) ou vérification par preuves :
• Utilisation d’une axiomatique et d’un système de déduction

logique
• Preuve = Théorème du système axiomatique considéré
• Theorem prover : B, PVS, Coq ...
La plupart des outils sont disponibles gratuitement et/ou librement
ohttp://gulliver.eu.org/wiki/FreeSoftwareForFormalVerification
ohttp://www.atelierb.eu/php/telecharger-atelier-b-fr.php
• Consiste à démontrer de manière systématique, en utilisant

les règles d'inférences d'une logique, un théorème de
correction
Exemple : soit une spécification S, est-il possible de démontrer

automatiquement qu'une propriété ϕ est une conséquence
logique de S ? Méthodes Formelles - O.Belkahla Driss 33
2) Model-Checking (MC) ou vérification exhaustive :
• Se base une description du système sous forme d’automate

• Vérification d’une propriété par parcours exhaustif des états
du système => propriétés vraies quelque soit l’exécution du
système
• Model-Checker : SPIN, VDM ...
• Consiste à vérifier, de manière exhaustive en parcourant tous

les états possibles du système, que le théorème est satisfait.
Exemple : soit un système de transition T représentant le

fonctionnement d'un programme P, est-il possible de
démontrer automatiquement qu'une propriété ϕ est garantie
par T (et donc P), c'est-à-dire qu'aucune exécution de P ne
viole ϕ ? Méthodes Formelles - O.Belkahla Driss 34
 Ces méthodes ne sont pas concurrentes mais

complémentaires et aucune d'entre elles ne peut prétendre
apporter seule une réponse définitive aux problèmes de
sureté de fonctionnement
 Néanmoins, dans l'état actuel de leurs développements,

ces différentes techniques permettent déjà de traiter de
vrais exemples industriels, et ceci à coût maîtrisé
 De plus, les erreurs détectées auraient souvent eu des

conséquences financières, économiques ou humaines sans
commune mesure avec les investissements effectués

Méthodes formelles
“Les méthodes formelles sont des techniques basées sur les

mathématiques pour décrire des propriétés de systèmes
informatiques. Elles fournissent un cadre pour spécifier,
développer et vérifier des systèmes d’une façon
systématique, plutôt que d’une façon ad hoc” [Wing90]
Eléments clés d’une méthode formelle :

 Langage formel pour l’écriture de spécifications
 Règles pour évaluer la validité/qualité des spécifications
 Stratégies et règles pour raffiner (mettre en œuvre) les
spécifications et vérifier ces raffinements
 Fondation sur laquelle tout repose = spécification formelle
Méthodes formelles
Avec les méthodes formelles, les cycles de vie classiques ne
marchent plus. Il faut les adapter !
Le cycle de vie de BALZER représente la nouvelle famille de

cycles de vie adaptés au développement formel
Choix de
conception

Méthodes formelles
Présentation du développement formel

Chapitre 2 Définitions Et Classification Des Méthodes Formelles

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre 2 Définitions Et Classification Des Méthodes Formelles

Transféré par

Droits d'auteur :

Formats disponibles

Technique Formelle : Définition

On appelle Technique Formelle, l'association :

1. d'un langage à sémantique formelle. Ce langage permet

2. un système de preuve permettant d'exprimer et de

Méthodes Formelles - O.Belkahla Driss 1

 Par exemple on peut utiliser la logique classique (formules

 Il permet la démonstration des propriétés relevantes du

 Il travaille sur un modèle du système

 La preuve sur programme permet de s’assurer que le

Méthodes Formelles - O.Belkahla Driss 3

2. Suite à l’invention des ordinateurs : utilisation de ces concepts

3. Puis création de programmes permettant le raisonnement sur

• Une vérification naïve : examiner toutes les valeurs possibles de a, à

• En vérification formelle, on utilise des valeurs symboliques et on

Méthodes Formelles - O.Belkahla Driss 5

• L’étape de spécification force à comprendre

• La spécification permet d’argumenter sur la

• La spécification permet d’énoncer des

Méthodes Formelles - O.Belkahla Driss 6

• La validation consiste à se demander si le texte

• La validation ne peut pas être automatisée

• La spécification permet de poser les bonnes

Méthodes Formelles - O.Belkahla Driss 7

• Une spécification est un contrat que le

• La spécification est une référence pour la

• Une spécification permet à chaque étape du

Méthodes Formelles - O.Belkahla Driss 9

Méthodes Formelles - O.Belkahla Driss 10

• Définir le quoi pas le comment !

Méthodes Formelles - O.Belkahla Driss 11

Méthodes Formelles - O.Belkahla Driss 12

Méthodes Formelles - O.Belkahla Driss 13

• L’intérêt de cette approche est qu’elle oblige le

• Elle permet par ailleurs de prouver formellement des

Méthodes Formelles - O.Belkahla Driss 14

• Les méthodes formelles ne sont pas limitées à la

Méthodes Formelles - O.Belkahla Driss 16

Conception architecturale et détaillée :

• Quel est votre problème ? Qu’est-ce que vous

• Niveau d’expertise / Niveau d’intervention

• Couverture du cycle de développement / Fidélité au logiciel

• Disponibilité des outils / Niveau d’automatisme

• Expressivité : qu’est-ce que je peux prouver ?

“Devoir en arriver à une meilleure compréhension de l’élément à

Impact positif de l’effort de formalisation :

• Spécifications explicites, précises, non-ambigues

Méthodes Formelles - O.Belkahla Driss 20

En plus des avantages de la précision et de la non ambiguïté

 Exploiter des outils de preuve et d’évaluation symbolique

 Ecrire assez facilement des maquettes (en prolog par

 Vérifier automatiquement les spécifications

 Engendrer automatiquement des jeux de tests

 Il est toujours possible de raffiner en une spécification

3.Logiciel comptable défaillant : Il y a quelques années, l’Agence de

Méthodes Formelles - O.Belkahla Driss 25

1. Les approches constructives (opérationnelles, basées

2. Les approches algébriques ou fonctionnelles

Méthodes Formelles - O.Belkahla Driss 26

1. Les approches constructives (opérationnelles,

 se fondent sur une sémantique à état de type automate

Méthodes Formelles - O.Belkahla Driss 27

1. Les approches constructives (opérationnelles,

2. Les approches algébriques ou fonctionnelles