Abonnez-vous à DeepL Pro pour traduire des fichiers plus volumineux.

Visitez www.DeepL.com/pro pour en savoir plus.

Sureté des systèmes

Master 1 Informatique
Année académique 2017/2018
Dr.-Ing. Franklin Tchakounté
 Objectifs
• Apprendre la vérification des
modèles
• Comprendre l'analyse de l'espace
d'état
• Apprendre les applications sur le
modèle
vérification

CHAP2. VÉRIFICATION DU MODÈLE

2
Introduction

3
 I. Introduction
• Lorsqu'ils testent un logiciel, les testeurs réfléchissent
généralement à la fonctionnalité prévue du logiciel et
créent ensuite autant de scénarios de test qu'il est
nécessaire pour tester toutes les fonctionnalités
souhaitées. Par exemple, lors du test d'une page de
connexion, un testeur peut vérifier les points suivants
– Page de connexion permettant de se connecter lorsqu'un nom
d'utilisateur et un mot de passe valides sont saisis
– La page de connexion refuse de se connecter lorsqu'un nom
d'utilisateur et un mot de passe non valides sont saisis
– Page de connexion refusant la connexion lorsqu'un nom
d'utilisateur et un mot de passe valides sont saisis mais que le
compte a été administrativement désactivé et affichant un
message approprié.
– Page de connexion permettant de se connecter avec un mot de
passe expiré mais exigeant de l'utilisateur qu'il change
 immédiatement son mot de passe.
– Page de connexion désactivant le compte après un nombre
prédéterminé de tentatives de
connexion4
 II. Introduction
• Si cette liste peut constituer un ensemble approprié de
scénarios de test et de résultats escomptés pour une page
de connexion, elle ne dit rien de la variabilité des résultats
en fonction des modifications apportées aux données
d'entrée.
• Par exemple, il ne vérifie pas toutes les chaînes de
caractères possibles pour les noms d'utilisateur et les mots
de passe, ainsi que leurs combinaisons.
• Personne ne fait cela ! Cela peut être considéré comme un
test trop poussé d'un petit composant d'un système plus
large.
• Cela représente en effet un travail considérable pour
tester uniquement la fonctionnalité de connexion d'un
5
système plus vaste, surtout si votre équipe effectue
régulièrement des tests de régression chaque fois que le
logiciel est modifié, éventuellement dans une autre partie
du système plus vaste.

6
 III. Introduction
• Mais que se passe-t-il si vous écrivez un logiciel
pour effectuer ce contrôle exhaustif à votre place
? Deux problèmes se posent :
– Vous devriez personnaliser le logiciel de test pour
chaque type de fonctionnalité que vous ajoutez à
votre système, ce qui implique du temps et des
efforts supplémentaires pour écrire les tests
automatisés.
– L'exécution prendrait encore trop de temps si l'on
essayait de procéder par force brute et de créer
toutes les chaînes de caractères possibles pour les
noms d'utilisateur et les mots de passe, ce qui
7
nécessiterait des ressources matérielles
supplémentaires.

8
 IV. Introduction
• Pour la plupart des logiciels écrits aujourd'hui, les deux raisons
susmentionnées suffisent à décourager la réalisation de tests
exhaustifs de ce type et à considérer que la liste précédente de
scénarios de test est suffisante à cette fin.
• Cependant, de nombreux systèmes qui soutiennent la vie
humaine ont une raison valable de relever ce défi et de faire
l'effort supplémentaire de valider le logiciel pour chaque entrée
possible.
• Cette tâche devient de plus en plus complexe lorsque le logiciel
testé a des dépendances temporelles ou de réseau
informatique et que les chemins d'exécution qu'il emprunte
pour différentes exécutions ne sont pas identiques, même pour
les mêmes données d'entrée.
• En d'autres termes, même si les données d'entrée sont
identiques, le chemin d'exécution, et donc le résultat, sera
différent pour chaque exécution, simplement parce que 9 le
logiciel a été exécuté ou parce que deux autres ordinateurs du
même réseau ont décidé de communiquer l'un avec l'autre
pendant la durée de l'exécution.

1
0
 V. Introduction
• Le Model Checking peut être utile dans certains de ces
cas.
• Il parcourt automatiquement le logiciel à tester,
détermine tous les chemins d'exécution possibles du
logiciel et les stocke dans sa structure de données
interne.
• Il est alors prêt à parcourir son modèle interne de
tous les chemins d'exécution et à vérifier.
• La plupart des logiciels de vérification des modèles
sont livrés avec quelques vérifications de base.
• Par exemple, la division par zéro, les blocages, les
conditions de concurrence, etc. sont tous néfastes
1
1
pour l'exécution normale des programmes. Toutes
ces vérifications sont intégrées dans les outils
modernes de vérification de modèle.

1
2
 VI. Introduction
• Ces contrôles sont appelés propriétés.
• Il est relativement facile de créer des propriétés
personnalisées pour un logiciel de Model Checking.
• Ces propriétés personnalisées peuvent vérifier la logique
commerciale applicable au système contrôlé, ce à quoi les
développeurs du logiciel de Model Checking n'auraient pas
pu penser lors de la mise au point du logiciel de Model
Checking.
• La création de propriétés est indépendante du
fonctionnement interne du logiciel Model Checking.
• Par exemple, lors du test d'un logiciel contrôlant un
moteur de fusée àun moteur de fusée à carburant liquide, un testeur
peut vouloir s'assurerquelecarburant n'est pompé au-delà d'un
certain taux que lorsque le moteur est mis à feu et qu'il n'y
a pas plus qu'une certaine quantité totale.moteur est allumé et
qu'une certaine quantité totale n'est pas pompée si le moteur
n'est pas mis à feu. 9
 VII. Introduction
• En interne, le Model Checking peut comporter
des graphes ou des arbres.

10
 VIII. Introduction
• Le graphique de gauche est généré directement à partir du
programme analysé.
• Chaque nœud représente un état du programme.
• Les flèches entre les nœuds représentent les transitions d'un
état à un autre.
• En d'autres termes, lorsque les variables d'un programme
changent, l'état de ce programme change et il passe donc d'un
état à un autre.
• Le flux d'exécution ou les transitions d'un état à un autre sont
contrôlés par des instructions de branchement ou de boucle. Ce
type de graphique est souvent appelé Automate à états finis.
• Tout Automate à états finis peut être converti d'une forme de
graphe à une forme d'arbre.en forme d'arbre. L'état de départ,
ici S0, devient la racine de l'arbre. Chaque nœud enfant du
nœud actuel est visité et, au fur et à mesure que le graphe est
analysé, l'arbre associé est produit.aufuretàmesurequele graphe est analysé,
l'arbre associé est produit,généralement selon la méthode "Breadth
First". 11
I- Construction d'un automate à
états finis

Exemple de micro-ondes
12
 I.1. Automate à états finis
• Construisons un Automate à État Fini à partir d'un
programme.
• Ce logiciel simule un four à micro-ondes. Si la
porte est fermée, elle peut être ouverte. Si elle
est ouverte, elle peut être fermée.
• De même, si le chauffage est éteint, il peut être
rallumé, mais seulement si la porte est fermée.
• Si le chauffage est allumé, il peut être éteint.
• Cette logique simple peut être représentée à
l'aide du lelogiciel suivant.
13
 I.2. Automate à états finis
public class Microwave { public void closeDoor() {
boolean doorOpen = false if (doorOpen) {
; boolean heatOn = false ; doorOpen = false ;
}
}
public Microwave() {
} public void turnHeatOn() {
public void openDoor() { if (!heatOn && !doorOpen) {
if (!doorOpen) { heatOn = true ;
}
doorOpen = true ; }
}
}
public void turnHeatOff() {
if (heatOn) {
heatOn = false ;
}
} 14
I.3. Automate à états finis

15
 I.4. Automate à états finis
• La figure décrit comment l'état du programme,
essentiellement stocké dans les variables membres
doorOpen et heatOn du programme, peut être
modifié.
• Le programme peut passer d'un état à l'autre en
utilisant les méthodes ou les flèches.
• Pourquoi ne pas créer un diagramme d'état des
deux variables ensemble ?

16
I.5. Automate à états finis

17
 I.6. Automate à états finis
• Nous voyons que les quatre états découlent de deux variables
booléennes.
• L'état des variables est inscrit à l'intérieur des cercles d'état,
ainsi que le nom de l'état.
• Le système peut passer d'un état à un autre en utilisant les
méthodes.
• L'état dans lequel la porte est ouverte et le chauffage est en
marche est S2. Cet état est un état dangereux et est
représenté par un contour rouge.
• S'il est possible d'appeler la méthode turnHeatOn() à partir deS3, il
ne serait pas possible de faire passer l'état à S2 parce quecette
méthode n'effectue la transition que lorsque la porte est
fermée(parexemple,passage de S0 à S1), mais l'appel de cette méthode
à partir de S3 n'aurait aucun effet sur l'état S2.depuis S3 n'aurait
aucun effet sur l'état. Ceci est représentéparuneflèche grise entre
S3 et S2. 18
 I.7. Automate à états finis
• Il reste cependant un moyen pour le système
d'atteindre l'état S2. Le système peut y parvenir en
se plaçant d'abord dans l'état S1, puis e n
appelant la méthode doorOpen().
• En d'autres termes, en ouvrant la porte alors que le
chauffage est déjà en marche. Ce chemin n'était
peut-être pas évident pour le lecteur lorsqu'il a lu le
premier code et même lorsqu'il a examiné les
transitions d'état dues à une seule variable à la fois.
Il n'est devenu évident que lorsque le diagramme
d'état pour tous les états possibles a été construit.
19
II. Analyse de l'espace d'état

20
 II.1. Analyse de l'espace d'état
• Une fois que le Model Checking dispose d'un modèle
du programme à tester et d'une liste de propriétés à
tester, il est prêt à effectuer la vérification.
• Il analyse chaque chemin d'exécution possible
et vérifier la validité des propriétés répertoriées.
• Pour chacun des états, il vérifie toutes les propriétés
pour voir si elles sont valables. Lorsque toutes les
propriétés sont vérifiées, il passe à l'état suivant.
• Lorsque tous les états d'un chemin d'exécution sontvérifiés, il
passe au chemin d'exécution suivant. De cetteAinsi, il parcourt
l'ensemble de l'espace d'états, en vérifiant toutes les
propriétés. propriétés. 21
 II.2. Analyse de l'espace d'état
• Si, à un moment donné, il constate qu'une
propriété n'est pas respectée, il le signale et,
puisqu'il sait comment il est arrivé à cet état, il
signale également le chemin d'exécution qu'il a
emprunté.
• Ceci est très utile à des fins de diagnostic.
L'utilisateur peut choisir d'arrêter l'exécution du
processus de vérification du modèle à la première
violation de propriété, puis d'ajuster le modèle, ou
de poursuivre le processus et de signaler toutes les
violations dans l'ensemble de l'espace d'état.
22
 II.3. Exemple de division par zéro
• Ce programme produit des résultats différents à chaque
exécution sur la base d'un générateur de nombres
aléatoires (RNG).
import java.util.Random ;

public class Rand {

public static void main (String[] args) {
Random random = new Random() ; // (1)

int a = random.nextInt(2) ; // (2)

System.out.println("a=" + a) ;

//... beaucoup de code ici

int b = random.nextInt(3) ; // (3)

System.out.println(" b=" + b) ;

int c = a/(b+a -2) ; // (4)

System.out.println(" c=" + c)
;
23
 II.4. Exemple de division par zéro
• Ici, dans la méthode principale, le programme produit
différents résultats en fonction du générateur de nombres
aléatoires (RNG) intégré à JAVA et utilisé sur la ligne marquée
1.
• L'appel random.nextInt(2) sur la ligne marquée 2 demande
un nombre aléatoire entre 0 et 1.
• De même, l'appel random.nextInt(3) à la ligne marquée 3
demande un nombre aléatoire entre 0 et 2.
• Sur la ligne marquée 4, nous pourrions diviser par zéro
chaque fois que a + b est égal à 2.
• Ce programme peut s'exécuter plusieurs fois etse terminer
normalement avant de signaler une division par zéro. Si vous
remplacezles paramètres passés à random.nextInt() sur les lignes lignes
marquées2et 3 par des nombres beaucoup plus grands, disons 2 000
000 et3 000 000, le programme peut s'exécuter normalement
pendant beaucoup plus de tempsavant de signaler une division par
zéro. 24
 II.5. Exemple de division par zéro
• Dans ce cas, une approche traditionnelle consistant à fournir des
valeurs prédéterminées pour les variables a et b donnerait très
probablement les résultats escomptés, mais pour certaines valeurs
de a et b, l'exécution du programme s'arrêterait en raison d'une
division par zéro.
• Voyons comment le Model Checking aborde ce problème. Le chemin
rouge indique un chemin d'exécution normalement terminé.

25
 II.6. Exemple de division par zéro
• La vérification du modèle permet d'envisager tous les scénarios
possibles, comme indiqué ci-dessus.
• Les déclarations situées à droite proviennent du programme et
correspondent aux nœuds situés à ce niveau dans l'arbre ci-dessus.
• Le chemin rouge est un chemin possible, peut-être l'un des chemins
probables, qui se termine par une fin normale du programme.
• Cependant, il existe d'autres chemins qui mènent à la division par
zéro. Le model checking effectuerait une recherche en
profondeur (DFS) sur l'arbre pour simuler l'exécution de tous les

26
états de tous les chemins d'exécution

27
 II.7. Exemple de division par zéro
• Les flèches en pointillés violets indiquent la manière dont le Model
Checking traverserait l'arbre des états.
• Les coches vertes aux feuilles de l'arbre indiquent une fin normale du
programme. La croix rouge sur la troisième feuille en partant de la
gauche représente une exception d'exécution due à une division par
zéro et une fin anormale du programme.
• Dans cette figure, le processus de Model Checking a été arrêté à
l'apparition de la première violation de propriété. Il existe un autre
cas, représenté par la deuxième feuille en partant de la droite, où la
division par zéro se produit également.

28
 II.8. Exemple de division par zéro
• À chaque état, représenté par un nœud dans l'arbre, le chemin
vers ce nœud depuis la racine est connu.
• Ce chemin comprend tous les changements d'état effectués
depuis le début de l'exécution de ce chemin d'exécution jusqu'au
moment où la propriété a été violée. Ce chemin, également connu
sous le nom de contre-exemple, est l'information de diagnostic
qui peut être affichée pour que le modélisateur ajuste le modèle
ou que le testeur signale l'échec.

29
 II.9. Exemple de division par zéro
• Dans les cas où les variables d'un programme à analyser
peuvent prendre de nombreuses valeurs, le modèle (ou l'arbre)
comportera un grand nombre d'états (ou de nœuds).
• Cela peut prendre une quantité importante de mémoire et
consommer toute la mémoire disponible dans l'ordinateur.
C'est ce qu'on appelle l'explosion de l'espace d'état. Il existe
plusieurs façons de contenir ce problème, mais il reste néanmoins
un problème dans le domaine de la vérification de modèles.
• Le Model Checking peut aider à détecter des erreurs difficiles à
trouver ou à reproduire, en particulier si le code concerné est
alambiqué ou obscurci par d'autres gros morceaux de code. Il
peut être incorporé dans les environnements de
développement intégrés (IDE) modernes. Pour chaque contre-
exemple ou violation découvert, le Model Checking fournit des
informations détaillées sur la manière dont il y est parvenu.
30
 II.10. Logiciels
• Il existe des outils logiciels dans l'industrie qui font de la
modélisation.
• La plupart sont adaptés à un langage de programmation
spécifique.
• Vous pouvez en rechercher pour les langages de
programmation que vous utilisez.
– Java - PathFinder de la NASA, BANDERA, CBMC, DBRover
– C/C++ - BLAST, CBMC, PCAchecker, DBRover, DSVerifier, ESBMC,
SATABS,
– Ada - DBRover,

31
III. Exercices

32
 III.1. Exercices
1. Vous construisez une machine de traitement du cancer. La machine
peut émettre deux types de faisceaux ; pour simplifier, appelons-les A
et B. Deux plaques différentes peuvent être placées devant le faisceau ;
appelons-les 1 et 2. Lorsque vous mettez la machine en marche, elle
démarre toujours avec le faisceau réglé sur A et la plaque réglée sur 1.
C'est l'état initial.
• Pour des raisons de sécurité, nous ne voulons jamais que la machine
se trouve au niveau du faisceau B et de la plaque 2. Si cela se produit,
une dose limite de rayonnement sera émise et le patient en mourra.
Mais toutes les autres combinaisons de faisceaux et de plaques sont
valables.
• Un développeur écrit un code pour automatiser cette machine. Il
affirme que son logiciel empêchera la machine d'être dans l'état
33
 faisceau = A et plaque = 2.
• Voici son code. Utilisez le Model Checking pour résoudre ce
problème.

34
 III.1. Exercices
1. On construit une machine de traitement du cancer. La machine peut
émettre deux types de faisceaux (beam) : A et B.
Il y a deux plaques différentes (plate) qui peuvent être placées devant le
faisceau : plaque 1 et plaque 2. Lorsque vous allumez la machine, elle
démarre toujours avec le faisceau réglé sur A et la plaque sur 1. C'est
l'état initial.
• Pour des raisons de sécurité, nous ne voulons jamais que la machine
soit au faisceau B et à la plaque 2. Si cela se produit, une dose de
rayonnement limite sera émise et le patient sera tué. Mais toutes les
autres combinaisons de poutres et de plaques sont valables.
• Un développeur écrit un code pour automatiser cette machine. Il
prétend que son logiciel empêchera la machine d'être à l'état beam =
A et plate = 2.
35
 III.2. Exercices
1.
Méthode setBeam(str beamType)
Si beamType = B et plaque = 1
Set beam = B Else
Régler la poutre = A
Method setPlate(int
plateType) If plateType = 2 and
beam = A Set plate = 2 Else Set
plate = 1.
A-t-il raison ?
A. Vous pouvez atteindre l'état (B, 2) en appelant setBeam(B) à partir de
l'état (A, 2).
B. Vous pouvez atteindre l'état (B, 2) en appelant setPlate(2) à partir de
36
 l'état (B, 1).
C. Ce code ne permet pas d'atteindre l'état (B, 2).
D. Vous pouvez atteindre l'état (B, 2) en appelant setBeam(B) à partir de
l'état (A, 1).

37
 III.3. Exercices
2. Lorsque vous utilisez le logiciel Model Checking, vous pouvez
programmer différentes situations que le Model Checker vérifiera.
Comment s'appellent ces vérifications ?

A. Modèles
B. Conditions
C. Propriétés

3. Le matériel utilisé pour ce sujet contient un exemple de micro-

ondes. Voici le code. Pour vous rafraîchir la mémoire, nous ne voulons
jamais arriver à un état où la porte est ouverte et le chauffage allumé.
Le développeur prétend avoir corrigé le défaut découvert par la
vérification du modèle. Sa correction est reflétée dans le code ci-
dessous. Effectuez à nouveau la vérification du modèle sur le code.
38
 III.4. Exercices
3. public class public void closeDoor()
Microwave
{ boolean doorOpen = false ; A. Oui, c'est maintenant correct.
B. Non, il y a encore un problème.
boolean heatOn = false ;
public Microwave() { }
public void openDoor()
{
if (!doorOpen)
{
if (heatOn) { heatOn = false ;
} doorOpen = true ;
}
}

Ce logiciel est-il corrigé ?

{ if (doorOpen)
{ doorOpen = false ; } }

public void turnHeatOn()

{ if (!heatOn &&
!doorOpen)
{ heatOn = true ; } }

public void turnHeatOff()

{
si (heatOn)
{ heatOn = false ; }
}
}
36
 III.5. Exercices
4. des Des typesdeproblèmes énumérés ci-dessous, lequel est
le plus approprié pour utiliser la vérification de la modélisation ?
lequel est le plus approprié pour utiliser la vérification de la
modélisation ?
A. Un environnement d'hébergement en nuage peut prendre en charge
un nombre spécifique d'utilisateurs simultanés.
B. Un calcul complexe est correct.
C. Un entrepôt de données peut contenir une quantité spécifique de
données.
D. Propriété selon laquelle deux avions ne peuvent pas décoller de la
même piste en même temps.
37