GLII: Spécification formelle et vérification de la sémantique dynamique Cours original proposé par : Prof.Leila Ben Ayed Cours repris et mis à jour par: Dr. Fadoua Ouamani

Plan du cours 01 Introduction 02 Introduire la specification et la vérification formelle des logiciels 02 La méthode B AMN (Abstract Machine Notation) Spécifier des machines abstraites en langage B, les raffiner et calculer des obligations de preuves 03 Le méthode Event-B Spécifier des systèmes abstraits en langage B, les raffiner et calculer des obligations de preuves 04 La vérification sur modèle (Model checking) Exprimer des propriétes en différentes logiques temporelles et appliuer des algorithmes de Model checking sur des automates pour savoir s’ils vérifient bien les formules temporelles.

Objectifs du cours 01 Connaissance Compétence 2 04 Compétence 5 04 Expliquer les concepts de spécification et de véification formelles Compétence 2 Vérifier la préservation des propriétés énoncées (invariant) en calculant des obligations de preuves 04 Compétence 5 Ecrire des formules en logiques temporelles PLTL, CTL, CTL* pour exprimer les propriétés à vérifier 04 Compréhension Comprendre l’utilité des techniques formelles dans le cycle de développement de logiciels 02 Compétence 3 Utiliser le langage B pour spécifier des systèmes abstraits et les raffiner 05 Compétence 6 Appliquer des models cheker pour savoir si les modèles des systèmes satisfont les propriétés 05 Compétence 1 Utiliser le langage B pour spécifier des machines abstraites et les raffiner 03 Compétence 4 Vérifier la cohérence et le raffinement en code exécutable par le calcul des obligation de preuves 06 Esprit critique et approche Prendre des décisions quand aux choix de la technique de vérification, des méthodes ou algorithmes à appliquer 06

Evaluation ou Comment réussir le cours GLII Assiduité et participation (10%) Soyez à l’heure et toujours présent 01 DS (50%) don’t panic!! 04 GLII Sucess configuration Quizes en début de séance (10%) Réviser vos cours de la dernière séance avant de venir pour réussir ces quizzes 02 Mini-projet (20%) Modéliser un système et vérifier ses propriétés 05 Apprentissage outils (10%) Se familiariser avec les outils à utiliser avant de venir 03 Examen: Evaluation finale Be psyched-up!! 06

Références/ livres 1992 The Temporal Logic of Reactive and Concurrent Systems: Specification Zohar Manna, Amir Pnueili, 01 1996 The B-book: assigning programs to meaning Jean Raymond Abrial 02 1996 The B language and method: a guide to practical formal development, Springer Kevin Lano 03 1998 Modeling reactive systems with statecharts:The statemate approach David Harel, Michal Politi 04 1999 Vérification de logiciels Techniques et outils du model-checking, Philippe Schnoebelen 05 2008 Principles of Model-Checking Christel Baier, Joost-Pieter Katoen 06 2010 Modeling in Event-B: System and software engineering 07 Jean Raymond Abrial

Références/ Etudes de cas http://www.irisa.fr/celtique/pichardie/teaching/L3/LOG/cours12.pdf Thèse Olfa Mosbahi, Développement Formel des Systèmes automatisés, Nancy-FST, 2008, http://docnum.univ- lorraine.fr/public/INPL/2008_MOSBAHI_O.pdf http://labri.fr/perso/sutre/Teaching/B/ Thèse Yousra Hlaoui BenDaly, Une Approche Dirigée par les Modèles pour la Spécification et la Vérification des Applications Workflow Composées à partir de Services de Grille, FSEGS – LaTICE, 2010

Deux outils Atelier B 01 NuSMV 02 http://www.atelierb.eu/en/atelier-b-support-maintenance/download-atelier-b/ 01 NuSMV http://nusmv.fbk.eu/distrib/NuSMV-2.5.2-i586-pc-mingw32msvc.exe 02

GLI versus GLII GLI GLII Vs Souci: bien développer le bon logiciel Qualité logiciel: différents critères Bon choix du Modèle du cycle de vie logiciel le plus adéquat Bonne gestion du projet de développement logiciel Phases : Analyse et spécification des besoins, Conception, Implémentation, TEST Spécification : informelle, semi-formelle ou formelle Vérification: Tests statiques vs. Tests dynamiques GLII Souci: bien développer le bon logiciel Qualité logiciel: sureté de fonctionnement Tests statiques « précoces » Méthodes formelles Spécification et vérification formelle Raffinement, abstraction, modularité Fondement et Notions mathémtiques Deux techniques de vérification rigoureuse: Preuve de théorèmes Model checking Vs

Chapitre I Introduction

Plan du chapitre I 01 Pourquoi la vérification? 02 La modélisation 03 Systèmes automatisés sûrs de fonctionnement 04 Nécessité des méthodes formelles 05 Spécification, validation et vérification 06 Comportement, environnement, propriétés 07 Formalismes pour représenter des spécifications 08 Techniques de vérification

Pourquoi la vérification? Absence de blocage Vérification??? Les diagrammes suivants contiennent-ils des erreurs? Le premier se bloque depuis le début de l’exécution (l’entrée dans l’activité 1 dépend de sa fin) L’entrée dans l’activité 4 dépend de la fin des deux activités 1 et 2 or une d’entre elles peut être entrée (ou exclusif) Vérification de l’absence de blocage

Pourquoi la vérification? Out of bounds error Vérification??? Exemple3: Calcul de la somme de deux nombres entiers en langage C Int somme(int x, int y) { int z; z = x+y; return z; } Ce code admet un problème : Solution : si x = 232 -1 et y = 1 232 n’existe pas, seulement 231-1 en entier donc un débordement peut avoir lieu

Pourquoi la vérification? Contrôle de saisie Ok or not? Vérification??? Exemple 4: Vérifier que la saisie d’un utilisateur est une séquence alphanumérique qui se termine par ab1. Le système de saisie à développer doit : Vérifier la saisie Répondre positivement si la propriété est respectée Demander une autre saisie dans le cas contraire Ou arrêter la saisie. Ici le système à développer est un contrôleur de saisie. On doit développer un automate fini qui reconnait les séquences valides, vérifier cette reconnaissance et implémenter le parcours de cet automate. Un automate fini ou automate avec un nombre fini d'états (en anglais finite-state automaton ou finite state machine ou FSM) est un modèle mathématique de calcul, utilisé dans de nombreuses circonstances, allant de la conception de programmes informatiques et de circuits en logique séquentielle aux applications dans des protocoles de communication, en passant par le contrôle des processus, la linguistique et même la biologie. Un automate fini est une construction mathématique abstraite, susceptible d'être dans un nombre fini d'états, mais étant un moment donné dans un seul état à la fois ; l'état dans lequel il se trouve alors est appelé l'« état courant ». Le passage d'un état à un autre est activé par un événement ou une condition ; ce passage est appelé une « transition ». Un automate particulier est défini par l'ensemble de ses états et l'ensemble de ses transitions.

Pourquoi la vérification? Satisfaction des propriétés critiques Vérification??? Exemple 6: Le système informatique: système de contrôle d’un chauffage La propriété est liée à la température ambiante qui ne doit pas déborder d’un intervalle. L’environnement est la température. Le composant physique (commandé) est l’appareil Le contrôleur (qui est le logiciel que nous avons à développer) reçoit en entrée la valeur de la température et agit sur le composant physique si nécessaire pour chauffer ou refroidir. Le composant logique (le contrôleur) et le composant physique ( contrôlé) doivent se comporter de façon à ce que la propriété soit vérifiée (température dans un intervalle).

Pourquoi la vérification? Satisfaction des propriétés critiques Vérification??? Exemple 7: Un système de contrôle d’une barrière de passage à niveau Le composant physique est la barrière Le composant de contrôle qui est le système informatique à développer agit sur la barrière pour qu’elle soit baissée ou relevée. L’environnement est composé par les trains (avec leurs états « arrive » ou « part » ou « rien ») Le contrôleur reçoit une information sur l’environnement: Si un train arrive alors il doit commander pour baisser la barrière si elle est initialement relevée. Si tous les trains partent alors le système commande la levée de la barrière.

Pourquoi la vérification? Satisfaction des propriétés critiques Vérification??? Exemple 8: Accès à une section critique Etant donnée une section critique (SC), un algorithme d’exclusion mutuelle doit satisfaire : Exclusion mutuelle (EM)/ sureté : si un processus est en SC alors aucun autre processus ne peut y être. Progrès (P) / vivacité: si un groupe de processus demande à entrer en SC alors l’un d’eux doit obtenir l’accès – pas d’interblocage (deadlock) Equité (E)/ vivacité : tout processus demandant d’entrer en SC doit y entrer ( au bout d’un certain temps) – pas de famine

Pourquoi la vérification? Satisfaction des propriétés critiques Vérification??? Propriété : Tout processus demandant l’entrée en section critique finit par y entrer. Pour vérifier cette propriété on a besoin de connaître le graphe d’accessibilité (les états seuls ne suffisent pas). Exemple 8: Processus A (boucle infinie) DemA :=1 Attente (DemB = 0) Section Critique DemA := 0 DemA =0 DemB = 0 1 DemA =1 DemB = 0 DemA =0 DemB = 1 Processus B (boucle infinie) DemB :=1 Attente (DemA = 0) Section Critique DemB := 0 3 2 4 DemA =1 DemB = 1 L’état {DemA = 1 DemB = 1} n’admet aucun successeur (c’est un deadlock). Pas d’équité (E) et pas de Progrès (P)

Pourquoi la vérification? Satisfaction des propriétés critiques Vérification??? Exemple 8: En A =0 En B = 0 Processus A Attente (V = 0) En A:= 1 V:=1 Section Critique V := 0 En A :=0 En A =1 En B = 0 En A =0 En B = 1 Processus B Attente (V = 0) En B := 1 V:=1 Section Critique V := 0 En B := 0 Propriétés Vérifiées : EM, P mais pas E Un des processus peut prendre l’accès indéfiniment au détriment de l’autre.

Pourquoi la vérification? Le système satisfait-il les exigences? Vérification??? Sémantique Modèle d’automates ? |== Formule logique Ou bien Syntaxique Formules logiques ? |-- Formule logique Il faut qu’on arrive, après ce cours, à modéliser, formaliser et vérifier

Pourquoi la vérification? Obtenir des systèmes sûrs de fonctionnement répondant aux exigences de l’utilisateur dans toutes les exécutions possibles des propriétés exigées absence de blocage, traitement infini, division par zéro … Ce sont les propriétés sémantiques dynamiques. L’analyseur sémantique dans un compilateur est plutôt limité aux propriétés sémantiques statiques : compatibilité des types, portée d’un identificateur, Un sous programme ...  La qualité en termes de sureté de fonctionnement. Vérification???

Pourquoi la vérification? Le développement classique de tels systèmes nécessite des tests qui peuvent à la fin obliger le développeur à refaire le développement. Les tests ne garantissent en aucun cas la fiabilité du système. Crtaines situations peuvent ne pas être testées. Solution: L’utilisation des méthodes formelles Méthodes basées sur un fondement mathématique offrant la précision, l’absence d’ambiguité, … Partir des besoins spécifiés au départ: Développer un modèle formel pour ce système (décrivant l’aspect comportemental ou fonctionnel ou structurel) Exprimer formellement les exigences Effectuer la preuve. Vérification???

La moélisation 1 2 3 4 Soit le code suivant : 1: While true do if not b then begin 2: b:= true; 3: proc ; 4: b := false; end if End While La moélisation b=faux b:=vrai proc 1 2 3 4 b:=faux b=vrai

Protocole de commerce électronique La moélisation Protocole de commerce électronique But : manipuler de l’argent électronique Données : Un client, une banque et un marchand Scénario Le client : initie une action de paiement envoie au marchand son certificat électronique Le marchand Sur présentation du certificat, il demande à la banque l’émission d’un nouveau certificat monétaire livre la marchandise Le client: émet une demande d’annulation dans quel cas, La banque: après vérification du certificat retourne l’argent dans le compte client annule sa validité

Protocole de commerce électronique Modélisation ▸ Un client qui peut payer, attendre sa livraison et annuler ▸ Un marchand peut enregistrer le paiement, livrer / demander un nouveau certificat puis recevoir le transfert ▸ Une banque peut recevoir une demande d’annulation ou recevoir une demande de certificat puis réaliser le transfert La moélisation Amarchand Aclient Abanque Synchronisation par messages m! (message m émis) m? (message m reçu)

La moélisation Problème: La composition assure–t-elle l’absence de blocage? Il faut un modèle pour la propriété d’absence de blocage Mprop et un algorithme de vérification Il s’agit de prouver que: Amarchand  Aclient  Abanque |= Mprop Autrement dit que le modèle de la composition est un modèle pour la propriété.  Ainsi, si ce modèle est traduit en un code alors il vérifiera aussi la propriété. NB. UN modèle d’une formule logique est un ensemble d’interprétations où la formule est vraie

Systèmes automatisés sûrs de fonctionnement P Propriétés de sureté Commandes Système physique Système Informatique de commandes Informations sur l’état du système physique Propriétés de vivacité Ces systèmes sont complexes et exigent un niveau de sûreté et de fiabilité élevé

Systèmes automatisés sûrs de fonctionnement Besoin : réduire la complexité et assurer un bon fonctionnement, Utiliser des méthodes formelles pour la spécification et la vérification de systèmes SOLUTION Spécification Exigences de l’utilisateur : propriétés attendues

Systèmes automatisés sûrs de fonctionnement Exigences les exigences fonctionnelles et non fonctionnelles du système modélisé, Les exigences de construction syntaxique et sémantique imposées par le langage de modélisation: respect des règles de construction, de la syntaxe abstraite et de la syntaxe concrète, respect de la sémantique liée aux concepts et aux relations employés dans le langage de modélisation, respect de la sémantique opérationnelle quand elle existe

Systèmes automatisés sûrs de fonctionnement Vérification Vs. Validation « Construisons-nous correctement le modèle ? ». La Vérification de modèles permet de prouver la cohérence du modèle par rapport aux exigences exprimées. La vérification est "la confirmation de preuves que les exigences spécifiées ont été satisfaites" (ISO 8402). « Construisons-nous le bon modèle ? ». Il s’agit ici de s’assurer de la pertinence du modèle. La validation est la "confirmation que les exigences particulières pour un usage spécifique prévu sont satisfaites". Plusieurs validations peuvent être effectuées s’il y a différents usages prévus (ISO 8402).

Nécessité des méthodes formelles Pour réduire la complexité et assurer un bon fonctionnement, l’utilisation des méthodes formelles apparaît comme une solution principale Il s’agit d’introduire une phase de spécification formelle dans le cycle de développement d’un logiciel Le système est ainsi spécifié et vérifié avant qu’il soit implémenté Le document de référence devient le document formel élaboré par la spécification  Si la spécification satisfait les propriétés et l’implémentation traduit la spécification alors l’implémentation satisfait aussi les propriétés

Nécessité des méthodes formelles Avant dans les années 70, l’utilisation des méthodes formelles se réalisait après l’implémentation. Le programme est traduit en automate et la vérification se fait sur l’automate. Cependant, la découverte d’une erreur à ce stade nécessite une mise à jour de toutes les étapes qui précèdent.  Ce qui est, en général, très couteux. Avec la complexité du code, les développeurs ont pensé à introduire la vérification dans une phase très avancée du cycle de développement.  Les modifications deviennent moins couteuses Les logiques (propositionnelles et de prédicats) n’étaient pas suffisantes pour décrire un comportement.  On a pensé à introduire les logiques temporelles Avec l’évolution des bases de données, la théorie des ensembles et la théorie des fonctions ont été introduites dans les approches formelles et là c’était dans les années 90.

Nécessité des méthodes formelles Spécification des besoins Identification des composants (modules) utiles Spécification formelle Définition du rôle de chaque module Conception Choix des structures de données et d’algorithmes Implémentation Codage Tests Vérification du respect des spécifications

Nécessité des méthodes formelles Exigences (Propriétés attendues) Spécification des besoins Validation Vérification Spécification formelle Vérifier si le texte formel traduit bien la demande informelle faite par celui qui commande le logiciel  La validation ne peut pas être automatisée Conception Implémentation Tests

Spécification formelle, validation et vérification Le système satisfait-il les exigences? Méthodes formelles Spécification formelle Formules logiques Modèle Mathématique Formules logiques Théorie des Ensembles, Fonctions Logiques Vérification syntaxique _________________ Preuve de théorèmes  Automates _________________Automates temporisés Vérification sémantique _________________ Algorithmes de model checking 

Spécification formelle, validation et vérification comprendre ce que doit faire chaque composant et argumenter sur sa cohérence  s’assurer de l’adéquation des composants au cahier des charges Enoncer des propriétés sur le système avant même son développement Définir le quoi pas le comment : Nom Données en entrée Résultats en sortie Une post-condition: La définition des résultats en fonction des données d’entrée Une pré-condition: Conditions d’activation des opérations

Spécification formelle, validation et vérification Une spécification est une référence pour la suite du développement Permet au programmeur de prendre des décisions sur : Les langages, La complexité et par suite les composants et leur intégration, la généricité Une spécification permet à chaque étape du développement de vérifier que la réalisation du système respecte les exigences En conception : Vérifier si l’algorithme calcule ce qui a été spécifié  En intégration : Vérifier si le programme réalise le composant initialement spécifié

Spécification formelle, validation et vérification Méthodes formelles pour la spécification Formulation rigoureuse des exigences sous forme de propriétés attendues du système Modélisation du fonctionnement du système (spécification du système). La vérification consiste à s'assurer que l'ensemble des fonctionnements du système à développer satisfait toutes les exigences. MAIS 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 (transformation de modèles) Codage: puis on génère automatiquement du code exécutable (génération de code pour une plateforme spécifique) Preuve: On prouve à chaque étape le respect des spécifications initiales

Spécification formelle, validation et vérification Limites des méthodes formelles Les méthodes formelles ne suffisent pas pour garantir que le système développé satisfait l'utilisateur. Les propriétés formalisées ne couvrent pas nécessairement la totalité des besoins, Il n'est pas exclu d'avoir mal interprété les besoins à la fois dans les propriétés et dans le système. La vérification formelle doit être complétée par de la validation à partir de jeux de tests. Les voies pour compléter la vérification par des jeux de test sont nombreuses: complémentarité entre validation et vérification, hétérogénéité des langages de spécification pour augmenter le pouvoir d'expression et combiner l'efficacité des méthodes de vérification, spécification par raffinement pour introduire la complexité des modèles pas à pas et décomposer la vérification.

Comportement, environnement, propriétés Type propriété Définition exemple Sûreté (safety) Quelque chose de mauvais n’arrivera jamais Pas d’accès simultané de A et B à la section critique (SC) Vivacité (liveness) Quelque chose souhaité finira par avoir lieu Si A veut entrer à SC, alors inévitablement , il aura cet accès Fatalité Sous certaines conditions quelque chose de bien finira par avoir lieu au moins une fois à partir d’un certain état". En logique temporelle: F   G ou (F   G) Si A veut entrer à la section, alors inévitablement , il aura cet accès entrèeASC   accèsASC Toujours vérifiée (entrèeASC   accèsASC) Atteignabilité Une certaine situation peut être atteinte. Quelque chose n’est jamais atteignable: inatteignabilité  sûreté. Equité (fairness) -------------------------------------- Equité faible Equité forte Sous certaines conditions, quelque chose aura lieu un nombre infini de fois. ----------------------------------------------------------- Une transition est continuellement activable alors elle est infiniment souvent activée Une transition est infiniment souvent activable alors elle sera infiniment souvent activée. le fonctionnement d'un passage à niveau on l'on exprime le fait que la barrière se lèvera une infitnité de fois

Comportement, environnement, propriétés Exemple: Contrôleur de feux de circulation d ‘un carrefour Problèmes: spécifier le fonctionnement d’un contrôleur de feux tricolores d’un carrefour. Les feux peuvent être : Hors service (hs) : tous les feux sont oranger En service (es) : ils évoluent selon rouge ↝ vert ↝ orange ↝ rouge Lorsque le feu est au rouge sur une voie, les véhicules de cette voie ne peuvent s’engager dans le carrefour Propriétés souhaitées: Condition de sûreté (safety) : les véhicules ne peuvent s’engager dans les deux voies simultanément. Condition de vivacité (liveness) : les véhicules ne sont pas bloqués infiniment sur l’une des (ou les deux) voies.  ((feuA=rouge)(feuBrouge))((feuArouge)(feuB=rouge))

Comportement, environnement, propriétés Exemple: Contrôleur de feux de circulation d ‘un carrefour États et caractérisation: Définition de l’état des feux : ETAT = {es, hs} etat  ETAT Caractérisation de l’état hors service Etat = hs ⇔ feuA = orange  feuB = orange Caractérisation de l’état en service Etat = es ⇒ feuA = rouge  feuB = rouge Caractérisation de la disponibilité (état en service) Etat = es ⇒ feuA  rouge  feuB  rouge

Formalismes pour représenter des spécifications Méthodes semi-formelles Exemples: STATEMATE, SA-RT, UML Points +: modèles graphiques, intuitifs, visualiser, concevoir et de documenter des systèmes éditeurs visuels, génération du code, validation Point -: absence d’une sémantique précise, pas de vérification des propriétés Méthodes formelles Exemples: B, Z, CTL, TCTL Points +: sémantique précise et rigoureuse vérification et la validation Points -: difficiles à utiliser par les non familiarisés manque de support de communication manque de qualité de structuration Vs

Formalismes pour représenter des spécifications Une description du système et ses propriétés l’utilisation d’une méthode formelle un langage avec une syntaxe et une sémantique définie mathématiquement pour décrire un système (comportemental, fonctionnel ou structurel) Formalisme pour représenter une spécification formelle logique : propositionnelle, du 1er ordre, du 2eme ordre, modale Théorie des ensembles (B, Z, VDM) automates / théorie des langages

Formalismes pour représenter des spécifications les langages dérivés de la logique classique pour exprimer des systèmes transformationnels les logiques temporelles pour exprimer des propriétés dynamiques de sûreté et de vivacité des systèmes réactifs, les langages logico-ensemblistes comme Z, VDM et B pour décrire et vérifier des propriétés statiques sur les états des systèmes, les réseaux de Petri, les automates communicants, LOTOS pour modéliser des systèmes concurrents avec ou sans partage de variables, les automates temporisés pour modéliser des systèmes temps réels

Techniques de vérification Vérification syntaxique Une preuve formelle est une séquence de situations où chaque situation est obtenue à partir d’autres situations par l’application de règles d’inférence. très puissantes elles traitent des systèmes à nombre d'états infinis elles sont indécidables dans le cas général,  difficiles à automatiser. Vs Vérification sémantique Vérification de modèles ou model checking) permet de savoir si un automate donné vérifie une formule temporelle donnée entièrement automatiques limitées aux systèmes ayant un nombre fini d'états  posent des problèmes en temps de traitement et en espace mémoire liés à l'explosion combinatoire en nombre d'états.

Fin du premier chapitre… Questions & discussion A suivre…