L’outil Maude et les système de réécriture

Master ILCDépartement d’informatiqueUniversité Badji Mokhtar Annaba

ماستر هندسة البرامج المعقدةقسم الإعلام الآلي

جامعة باجي مختار عنابة

مــخبر هــندسـةالأنـظمـة الـمعقـدة

Laboratoire d’Ingénieriedes Systèmes Complexes

L’outil Maude et les systèmes de réécriture

Présenté par : DR. T. BENOUHIBA

Outils de vérification formelle2

Introduction

Plusieurs modèles de calcul universel La machine de Turing (système à états) Les systèmes de réécriture

Le lambda calcul pur et typé Les règles de Markov


Introduction

Un système de réécriture : Un système dans lequel on applique plusieurs substitutions

locales à une chaîne de caractères afin de la transformer

chaîne1 → chaîne2→ chaîne3→…→ chaîne n


Introduction

Les règles de Markov Un ensemble de règles de la forme :

chaîne1 → chaîne2 signifiant que chaîne1 doit toujours être remplacées par chaîne2

Il existe deux types de règles : Règles ordinaires (marquées par ; à la fin)

• Continuer les substitutions si possible Règles terminales (marquées par . à la fin)

• Arrêter les substitutions dans tous les cas

L’ordre des règles est significatif


Introduction

Exemple 1 :1. "1a" → "b1" ;2. "1b" → "a1" ;3. "1c" → "c1" ;4. "1" → "" .5. "" → "1" ; Examinons la transformation de "abc", "aacb" …

Exemple 2 :1. "1" → "0|" ;2. "|0" → "0||" ;3. "0" → "" ; Que font ces règles à 101, 11,… ?


Introduction

En fin de compte, on peut programmer en utilisant les règles de Markov

Il s’agit en fait d’une machine universelle

Idée : les utiliser pour modéliser et vérifier les systèmes Principe : considérer un changement d’état comme une réécriture Exemple :

On peut représenter l’affectation x:=a dans un couple (x,y) par : (x,y)→(a,y)


Introduction

Autres utilisations des systèmes de réécriture : Les grammaires des langages Les L-systèmes (systèmes de Lindenmayer)

On effectue toutes les substitutions possibles à chaque itération Exemple :

A→C[B]D B→A C→C D→C(E)A E→D

A partir de la chaîne A, on peut obtenir A, C[B]D, C[A]C(E)A, C[C[B]D]C(D)C[E]D, … Quelle est l’utilité ?


Introduction

Les L-systèmes : Pour chaque chaîne produite on considère que :

Les crochets sont des bifurcations à droite Les parenthèses sont des bifurcations à gauche On va dessiner…

A C

BD

C

AC

AE

C

CC

CDD

B

D B

A C[B]D C[A]C(E)A C[C[B]D]C(D)C[B]D


Autres applications des L-systèmes

Les L-systèmes : F→ F+F--F+F On commence à partir de : -F--F--F On produit alors :

-F--F—F -F+F--F+F--F+F--F+F--F+F--F+F -F+F--F+F+F+F--F+F--F+F--F+F+F+F--F+F--F+F--F+F+F+F--F+F--F+F--

F+F+F+F--F+F--F+F--F+F+F+F--F+F--F+F--F+F+F+F--F+F etc..

Quelle est l’utilité ?


Applications des L-systèmes

On va dessiner : F : signifie avancer (dessiner un segment) +/- : tourner à droite/gauche de 60°

Fractale de Koch


D’autres exemples de fractales générés par réécriture

Courbe du dragon



Des arbres (de tous petits)



Un joli motif



Un autre joli motif


Un peu de théorie

Soit A un alphabet quelconque

Un système de réécriture est le couple (A,R) tel que R est une relation binaire sur A*

u R v signifie que u est réécrit (ou réduit à) à v On se permet de réécrire u en v après plusieurs étapes (u R* v)

On peut définir sur R une relation d’équivalence tel u R’ v si u et v sont réécrits à la même forme

Les termes du système sont les classes d’équivalence de la relation R’* On notera R par → (et R* par →*)


Un peu de théorie

Exemple : A={a,b}, →={a4→,b2→, ba→a3b} Les éléments du système sont :

, a,a2, a3, b, ab,a2b,a3b

On peut établir l’équivalence entre deux mots en les réduisant à l’une des huit formes possibles ici Si égalité des réductions, les mots sont considérés comme

équivalents Qu’est cela signifie pour des programmes ?

Deux notions essentielles surgissent : Notion de normalisation Notion de confluence


Normalisation

Un élément a de A* (A* est muni de →) est une forme normale s’il n’existe aucun mot b de A* tel que a→*b On notera l’ensemble des formes normales par nf Pour l’exemple précédent, nf(A*)=?

Soit a une élément de A* On note par nfa={bnf | a→*b} C’est l’ensemble de toutes les formes normales d’un

élément Signification pour un programme ?


Normalisation

On dit qu’un SAR est normalisant ssi : nfa≠ pour tout élément a Signification pour un programme ?

Un SAR est fortement normalisant si : Il n’existe aucune séquence infinie de réécriture

a1→a2→a3→…

Un SAR fortement normalisant est normalisant


Confluence

Un SAR est dit confluent ou Church-Rosser quand : a,b,cA*, si

a→* b et a→* c alors dA*: b→* d et c→* d Toutes les réductions mènent à une seule forme (peu importe

l’ordre) Signification pour un programme ?

a b

c d

*

*

**


Confluence

La confluence indique que nfa contient au plus un élément Pourquoi?

La confluence n’est pas facile à vérifier : Solutions :

Confluence forte Confluence locale


Confluence

Confluence forte : a,b,cA, si

a→b et a→c alors dA: b→d et c→d La confluence forte implique la confluence

Confluence locale a,b,cA, si

a→b et a→c alors dA: b→*d et c→*d La confluence locale n’implique pas la confluence

Confluence locale + normalisation forte = confluence

a b

c d

a b

c d*

*


Maude

Maude : Langage réflexif Support pour :

La logique équationnelle/logique d’appartenance Proche de la sémantique algébrique

La logique de réécriture Permet de spécifier les changements parallèles d’un système

Finalité : Spécification, programmation et vérification des systèmes


Maude

Deux modes pour Maude : Core Maude :

Écrit en C++ Fonctionnalités basiques

Définition des modules… Vérification POO Réflexion etc…

Full Maude : Écrit en Maude lui-même Fonctionnalités avancées sur les modules Permet d’écrire des extensions à Maude


Core Maude

Introduction On considère des booléens avec la signature (attention

ceci n’est pas du code Maude) :

signature Boolean issort Boolconstants true, false : Booloperation not : Bool -> Booloperation or : Bool Bool -> Boolend


Core Maude

Introduction Avec les propriétés :

vars X, Y, Z : Boolnot(not(X)) = Xnot(true) = falsenot(false) = trueX or X = XX or Y = Y or XX or true = trueX or false = X(X or Y) or Z = X or (Y or Z)

Exemple de réduction : (not(true) or false) → not(true) → not(true) -> false


Core Maude

Problème : existence d’un modèle pour la signature ?

Problèmes à résoudre : Terminaison des réduction :

Un réécriture peut ne jamais se terminer Exemple : x and y=y and x !

Généralement résolu par le choix des attributs des opérations Un outil est disponible pour tester si un système de réécriture peut se

terminer ou non (MTT)

Confluence : Si plusieurs chemins de réduction sont possibles, peut-on obtenir la

même forme finale ? Un outil est également disponible pour tester si un système de

réécriture est confluent ou non (CRC)


Core Maude

Syntaxe d’un module fonctionnel : fmod nom_module is …endfm Import des modules Déclaration des sortes Déclaration des opérations Déclaration des variables Déclaration des équations


Core Maude

Un petit module fonctionnel pour des entiers :

fmod BASIC-NAT issort Nat .op 0 : -> Nat [ctor] .op s_ : Nat -> Nat [iter ctor] .op _+_ : Nat Nat -> Nat .vars N M : Nat .eq 0 + N = N .eq N + 0 = N .eq s(M) + N = s(M + N) .

endfm

Nous avons défini : Un module

Une sorte Nat (un type, un ensemble,…)

Une constante : 0

Deux opération s et add

Trois propriétés


Core Maude

Et un deuxième pour les booléens :fmod BOOLEAN is

sort Boolean .op true : -> Boolean [ctor] .op false : -> Boolean [ctor] .op not : Boolean -> Boolean .op _and_ : Boolean Boolean -> Boolean .op _or_ : Boolean Boolean -> Boolean .var A : Boolean .eq not true = false .eq not false = true .eq true and A = A .eq false and A = false .eq true or A = true .eq false or A = A .

endfm

Nom du module

Nom des sortes

Définition des opérations

Déclaration des variables

Équations


Core Maude

Hiérarchisation des modules : Protection : importer sans changer le comportement des modules

fmod NAT+OPS isprotecting BOOLEAN .protecting BASIC-NAT .ops _*_ _-_ : Nat Nat -> Nat .ops _<=_ _>_ : Nat Nat -> Bool .vars N M : Nat .eq 0 * N = 0 .eq s(M) * N = (M * N) + N .

eq 0 - N = 0 .eq M - 0 = M .eq s(M) - s(N) = M - N .eq 0 <= N = true .eq s(M) <= 0 = false .eq s(M) <= s(N) = M <= N .eq M > N = not(M <= N) .

endfm


Core Maude

Hiérarchisation des modules : Inclusion : importer avec modification du comportement

On peut également : Créer des théories :

Modules sans terminaison ou confluence… Renommer des modules Créer des modules paramétrés et les instancier

fmod NAT3 isincluding BASIC-NAT .var N : Nat .eq s(s(s(N))) = N .endfm


Core Maude

Déclaration des sortes : Mot clé : sort ou sorts ens1 ens2 ens3 . Autre possibilité : nom_sorte{nom_sorte}

Modules paramétrés

Notion de sous-types : Syntaxe : subsort sort1 < sort2 . Signification :

sort1 est un sous type de sort2 Toutes les propriétés de sort2 sont également des propriétés de sort1 Exemple :

sort Nat Nat3 .subsort Nat3 < Nat .

op 0 1 2 : -> Nat3 .


Core Maude

Notion de catégorie (kind) : Une catégorie est un ensemble de sortes connectées par une

relation <

Dans l’exemple précédent, Nat et Nat3 appartiennent à la même catégorie Une catégorie est notée par [Nat] (le plus grand élément)


Core Maude

Déclaration des opérateurs : Syntaxe :

op|ops nom_op signature : s1 s2… sn ->s [attributs]

Une constante est un opérateur sans paramètre : op 0 : -> Nat . Si c’est un constructeur, on peut utiliser l’attribut ctor Généralement, les opérateurs déclarés avec ctor ne doivent pas être réduits

(cohérence)

Les paramètres sont définis par _ : Utilisation préfixe, infixe et post-fixe Exemples :

add( _ , _ ) : Nat Nat -> Nat . _+_ : Nat Nat → Nat . _ _+ : Nat Nat → Nat .


Core Maude

Déclaration d’une liste d’entiers : Opérateurs sans nom

...sort List .subsort Nat < List .op nil : -> List .op __ : List List -> List [assoc id: nil]

L’opérateur est associatifnil est l’élément neutre(à droite et à gauche)


Core Maude

Les équations : Énoncer des propriétés des opérateurs (définit une sémantique) Utilisation du mot clé eq

Syntaxe : eq terme1 = terme2 . Signifie que le terme1 est réduit en terme2

Exemple : op length (_) : List → Nat . var L : List . var N : Nat . eq length(nil) = 0 . eq length (N L) = 1 + length(L) .


Core Maude

Attributs des opérateurs : assoc : l’opérateur est associatif comm : l’opérateur est commutatif id: terme : terme est élément neutre

left id : élément neutre à gauche (attention à comm) right id: élément neutre à droite (attention à comm)

idem : signifie que l’opérateur est idempotent Ne doit pas être combiné avec avec assoc !

iter : s’applique à un opérateur unaire défini de A→A qui peut s’appliquer de manière itératif Optimise les réductions

frozen : signifie que l’opérateur ne doit pas être réduit mais ses paramètres peuvent l’être

etc


Core Maude

Précédence des opérations : Pour les entiers, l’expression a + b * c peut être analysée de deux

manières → ambiguïté Solution : utilisation des précédences (priorité) : prec nb Exemple : prec 33 pour + et prec 31 pour * Précédence des constantes : 0

L’expression a + b + c put être analysée de deux manières (si + n’est pas associatif) → ambiguïté Solution : patrons de regroupement : gather E e &

E signifie que l’opérande doit avoir une précédence <= à la précédence de l’opérateur

e signifie que l’opérande doit avoir une précédence < à la précédence & signifie qu’il n’y a aucune restriction


Core Maude

Exemples sur les patrons de regroupement : gather (E e) : associativité à gauche gather(E E) : ambiguïté gather(e E) : associativité à droite gather(e e) : ??? …


Core Maude

Une première session Maude : Opérations sur les entiers : entier.maude Un module pour les listes de entiers : nlist.maude


Core Maude

Commande de réduction :red terme : pour réduire un terme

jusqu’à ce qu’il ne reste plus de possibilité

Renvoie la sorte la plus petite du terme La commande set trace on/off Exemple : les entiers


Core Maude

match [limit] terme1 <=? Terme2 Terme1 doit contenir des variables match montre comment Maude établit la liaison entre les sous-termes

et les variables Exemple : match A:Entier + B:Entier <=? s s 0 + s s s s 0 .

La correspondance est établit entre terme1 et terme2 entièrement

xmatch [limit] terme1 <=? Terme2 Terme1 doit contenir des variables match montre comment Maude établit la liaison entre les sous-termes

et les variables Exemple : xmatch s A:Entier <=? s 0 + s s s s 0 .

La correspondance est établit entre terme1 et une partie de terme2


Core Maude

Autres commandes : show module show sorts show components (pour les catégories)


Core Maude

Les équations conditionnelles Syntaxe : ceq terme1=terme2 if cdt1 /\ cdt2 /\ … /\

cdtn Cdti : une condition sur les termes :

Comparaison : ==, =/=, <, >, <=, >=, prédicats définis par l’utilisateur Affectation :

Syntaxe termeG:=termeD• Permet de rechercher les valeurs des variables qui vérifient

l’équation S’évalue à vrai si les variables peuvent être instanciées Sinon, c’est faux

Une variable doit avoir une valeur avant qu’elle ne soit utilisée


Core Maude

Exemple : op _div_ : Entier Entier -> Entier . ceq M div N = P if (N <= M) /\ P := ((M - N) div N) + s 0 . eq M div N = 0 [owise] .

Autres exemples : Voir REGS, RLIST.maude


Core Maude

Appartenance à une sorte Syntaxe : mb terme : sorte Indique que terme appartient à sorte Par exemple :

On veut avoir des entiers pairs et des entiers impairs (paire.maude)

Deuxième exemple : Les multiples de 5, de 10, … → dentier.maude


Core Maude

L’appartenance peut être conditionnelle Syntaxe : cmb terme1:sorte if cdts On veut créer une classe des mutiples de 5 dont le digit le

plus à gauche n’est pas 0 Contrainte sur le digit à gauche Fichier : dentier.maude


Core Maude

Retour sur la théorie Il faut s’assurer que le système de réécriture soit

normalisant ou mieux encore fortement normalisant Pourquoi ?

Il faut s’assurer que le système de réécriture est confluent (ou au pire localement confluent) Pourquoi ?

Troisième propriété : décroissance de type Soit t un terme qui se réduit en t’ (forme normale) Un problème survient si :

sorte(t’) n’est pas inclus dans sorte(t)? Pourquoi ?


Core Maude

Quatrième propriété : cohérence Vérifier que le système dispose des bonnes fonctions

Si ce n’est pas le cas, on risque de tomber sur des termes (cas) que l’on n’a pas prévu au départ Ils seront irréductibles → on ne peut pas faire le calcul

Pour le vérifier, il faut : Vérifier que toutes les formes normales sont seulement

composées des constructeurs


Core Maude

Module système : Spécifie une théorie de réécriture Composé des :

Sortes (et catégories) Équations (conditionnelles ou non) Appartenances (conditionnelles ou non) Règles (conditionnelles ou non)

Concrètement, un module système correspond à un système de transitions concurrent

Les règles représentent les transitions possibles


Core Maude

Les modules systèmes sont déclarés par le mot clé mod et se termine par endm

Une règle inconditionnelle a la syntaxe suivante : rl {[label] :} terme1 => terme2 [attributs] . Signifie que terme1 peut s’écrire en terme2

Si plusieurs instances d’une même règle ou de plusieurs règles sont déclenchables, alors elles seront exécutées en parallèle (ou plutôt de manière entrelacée)


Core Maude

Exemple :

fmod VENDING-MACHINE-SIGNATURE issorts Coin Item Marking .subsorts Coin Item < Marking .op __ : Marking Marking -> Marking [assoc comm id: null] .op null : -> Marking .op $ : -> Coin .op q : -> Coin .op a : -> Item .op c : -> Item .endfm

mod VENDING-MACHINE isincluding VENDING-MACHINE-SIGNATURE .var M : Marking .rl [add-q] : M => M q .rl [add-$] : M => M $ .rl [buy-c] : $ => c .rl [buy-a] : $ => a q .rl [change] : q q q q => $ .endm


Core Maude

Les règles conditionnelles : Syntaxe :

crl {[label] : } terme1 => terme2 if cdt1 /\ cdt2 /\ … /\ cdtn [attributs]

Les conditions sont les mêmes que les conditions des équations On rajoute un autre type de condition :

t1 => t2 : signifie si t1 peut être réécrit en t2


Core Maude

Les attributs : owise nonexec …


Core Maude

Exemple CSP :

sort Event Process .eq _->_ : Event Process -> Process .eq _||_ : Process Process -> Process .…var P P’ Q : Process .…crl [rgl1] : P || Q => P’ || Q if P => P’ .…


Core Maude

Les commandes de réécriture : La commande rewrite (rew) :

Syntaxe : rew {[borne]} in module_name : terme .

Permet de réécrire un terme avec une stratégie topdown Appelée également : leftmost, outermost

borne : spécifie le nombre maximal de règles à utiliser S’il est omis, on s’arrête lorsqu’il ne reste aucune règle à appliquer Peut mener à une boucle infinie…

IMPORTANT : aucune règle n’est appliquée si une équation est applicable Les réductions sont utilisées pour simplifier les états du systèmes


Core Maude

Les commandes de réécriture : La commande rewrite (rew) :

Syntaxe : frew {[borne{,nb}]} in module_name : terme .

Permet de réécrire un terme : Permet d’appliquer une règle sur un sous-terme puis le réduit C’est une approche de réécriture en profondeur avec une équité de

position borne : indique le nombre maximal de règles à appliquer nb : indique le nombre maximal d’application d’une règle sur un

sous-terme


Core Maude

Les commandes de réécriture : La commande de réécriture search (la plus importante) :

Syntaxe : search [n,m] in module_name terme1 <Recherche> terme2 such that

CONDITION Signification :

Cherche si le terme1 peut être réécrit en terme2 Si oui, il donne la séquence des règles à appliquer

<Recherche> peut être : =>1 : réécriture en une seule étape =>+ : réécriture en une étape ou plus =>* : n’importe quel nombre de réécritures =>! : signifie que l’on s’arrête lorsque aucune règle n’est applicable

n : nombre maximal de solutions m : profondeur maximale de recherche


Core Maude

Exemple : soit le module

mod SIMPLE-VENDING-MACHINE isincluding VENDING-MACHINE-SIGNATURE .rl [buy-c] : $ => c .rl [buy-a] : $ => a q .rl [change]: q q q q => $ .endm

search in SIMPLE-VENDING-MACHINE : $ q q q =>! a c M:Marking .

search in SIMPLE-VENDING-MACHINE : $ q q q =>! a c M:Marking such that M:Marking =/= null .


Core Maude


Core Maude

Les commandes de visualisation : show path numero-etat :

Donne le chemin entre l’état initial et l’état numero-etat

show path label numero-etat : Donne les étiquettes du chemin

show search graph . Montre tout le graphe de recherche

Exemple : verf.maude


Core Maude

Vérification de modèles par la recherche d’invariants : On peut utiliser Maude pour vérifier qu’une certaine propriété est

toujours vérifiée

Le problème formulé en LTL : G Invariant

Pour vérifier le système, on peut s’intéresser à la négation : F Invariant En d’autres termes, est-ce qu’on peut accéder à un état qui ne vérifie pas

l’invariant Le problème est transformé en un problème d’accessibilité

En maude, on peut écrire : search init =>* x:k such that I(x:k) =/= true S’il n’y a pas de solutions, il s’agit bien d’un invariant S’il existe une solution, le chemin trouvé constitue un contre-exemple


Core Maude

Exemple :

mod SIMPLE-CLOCK isprotecting INT .sort Clock .op clock : Int -> Clock [ctor] .var T : Int .rl clock(T) => clock((T + 1) rem 24) .endm

On veut vérifier que l’horloge ne dépasse pas 24 et n’est pas inférieure 0!

search in SIMPLE-CLOCK : clock(0) =>* Clock(T) such that T < 0 or T >= 24 .


Core Maude

Un autre exemple : des processus qui se partagent des ressources : Un processus a besoin de deux ressources pour effectuer leur travail L’acquisition des ressources se fait une par une Un processus libère toutes ses ressources en un même temps Une paire processus+une ressource peuvent se dupliquer


Core Maude

mod PR issorts State Resources Process .subsorts Process Resources < State .ops res null : -> Resources [ctor] .op p : Resources -> Process [ctor] .op __ : Resources Resources -> Resources [ctor assoc comm id: null] .op __ : State State -> State [ctor ditto] .

rl [acq1] : p(null) res => p(res) .rl [acq2] : p(res) res => p(res res) .rl [rel] : p(res res) => p(null) res res .rl [dupl] : p(null) res => p(null) res p(null) res .

endm


Core Maude

On veut cherche l’absence d’interblocage lorsqu’on commence une exécution avec un processus et deux ressources : search [2] in PR : p(null) res res =>! X:State .

Signifie que l’on peut atteindre un état sans aucune autre réécriture possible

Un autre exemple : exclu.maude, verf.maude


Core Maude

Vérification bornée de modèles (bounded model checking) : Considérons le problème des rédacteurs/lecteurs

mod RW issort Nat .op 0 : -> Nat [ctor] .op s : Nat -> Nat [iter ctor] .sort Config .op <_,_> : Nat Nat -> Config [ctor] .

vars R W : Nat .rl [debut-ecriture] : < 0, 0 > => < 0, s(0) > .rl [fin-ecriture] : < R, s(W) > => < R, W > .rl [debut-lecture] : < R, 0 > => < s(R), 0 > .rl [fin-lecture] : < s(R), W > => < R, W > .endm


Core Maude

Etat initial : <0 , 0>On va vérifier :

L’exclusion mutuelle : Un rédacteur et un lecteur ne peuvent pas accéder au tampon au

même temps search in RW : <0 , 0 > =>* < s(N:Nat) , s(M:Nat) >


Core Maude

Un problème : Le nombre des lecteurs n’est pas limité

→ un nombre infini d’états On peut résoudre partiellement le problème par :

search [1, 100000] in RW : < 0, 0 > =>* < s(N:Nat), s(M:Nat) > . On va jusqu’à une très grande profondeur Si on arrive à trouver une solution, la propriété n’est pas vérifiée Si on ne trouve aucune solution, qu’est ce que cela signifie ?


Core Maude

Plus d’abstraction : Lorsque le nombre des états est infini ou est très

important La vérification devient impossible (ou presque)

Solution : augmenter l’abstraction d’un cran en réduisant le nombre des

états Exemple :

Pour le problème des rédacteurs/lecteurs la présence d’un seul lecteur est équivalente à la présence d’un nombre quelconque de lecteurs Dans tous les cas, les rédacteurs sont bloqués


Core Maude

Soit M un module offrant un nombre infini d’états

Soit M’ une abstraction de M Il faut M’ préserve l’invariant de M M’, init |= [] inv M,init |= [] inv M’ doit garantir :

La normalisation, confluence, décroissance de type et cohérence

Pour cela, il faut redéfinir les modules prédéfinis Les outils qui vérifient les propriétés précédentes ne supportent

pas les modules prédéfinis


Core Maude

Exemple : mod RW-ABS isincluding RW .eq < s(s(N:Nat)), 0 > = < s(0), 0 > .endm

On peut vérifier maintenant :search in RW-ABS : < 0, 0 > =>* < s(N:Nat), s(M:Nat) > .


Core Maude

Vérification de modèle en LTL Maude possède un module qui permet de représenter

des formules en LTL (model-checker.maude)

Soit AP un ensemble de propriétés atomiques : True, False : sont des formules LTL N’importe quelle propriété atomique est une formule LTL Les connecteurs logiques usuels : ~, /\, \/, ->, <->,… Les opérateurs temporels :

O : l’opérateur next <> : l’opérateur F (il est possible dans le future) [] : l’opérateur G (toujours) U : l’opérateur Until


Core Maude

La vérification consiste à avoir une : Structure de Kripke : M Un état initial : init Une formule logique : P On veut démontrer M,init |= P

Toute exécution de M à partir de « init » vérifie P Maude permet de :

Écrire des formules LTL Comment définir une structure de Kripke ?

Une théorie de réécriture


Core Maude

Maude possède le module SATISFACTION qui représente un structure de Kripke générique : En particulier, on définit une sorte State représentant les différents

états du système (grâce à <)

Il définit également une opération : _|=_ State Prop -> Bool state|=P = true : indique que l’exécution du système à partir de l’état

state vérifie la propriété P

Pour vérifier un système Il faut établir une relation entre la sorte State et la sorte qui représente

un état dans le système à vérifier


Core Maude

Exemple : exclusion mutuelle (avec l’utilisation de jetons : $ et *)mod MUTEX is

sorts Name Mode Proc Token Conf .subsorts Token Proc < Conf .op none : -> Conf [ctor] .op __ : Conf Conf -> Conf [ctor assoc comm id: none] .ops a b : -> Name [ctor] .ops wait critical : -> Mode [ctor] .op [_,_] : Name Mode -> Proc [ctor] .ops * $ : -> Token [ctor] .rl [a-enter] : $ [a, wait] => [a, critical] .rl [b-enter] : * [b, wait] => [b, critical] .rl [a-exit] : [a, critical] => [a, wait] * .rl [b-exit] : [b, critical] => [b, wait] $ .

endm


Core Maude

Etablir une relatio entre State et la sorte des états :mod MUTEX-PREDS is

protecting MUTEX .including SATISFACTION .subsort Conf < State .op crit : Name -> Prop .op wait : Name -> Prop .var N : Name .var C : Conf .var P : Prop .eq ([N, critical] C |= crit(N)) = true .eq ([N, wait] C |= wait(N)) = true .eq (C |= P) = false [owise] .

endm

Définition de prédicats qui facilitent les notations


Core Maude

Définition du module qui permet de lancer la vérification : C’est un module qui doit importer :

Le module qui relie State à la sorte des états Le module MODEL-CHECKER Le module LTL-SIMPLIFIER

On peut y définir l’état initial pour ne pas avoir à l’écrire à chaque fois


Core Maude

Exemple :

mod MUTEX-CHECK isprotecting MUTEX-PREDS .including MODEL-CHECKER .including LTL-SIMPLIFIER .ops initial1 initial2 : -> Conf .eq initial1 = $ [a, wait] [b, wait] .eq initial2 = * [a, wait] [b, wait] .

endm

Vérification : red modelCheck(initial1, [] ~(crit(a) /\ crit(b))) . red modelCheck(initial2, [] ~(crit(a) /\ crit(b))) .


Core Maude

Si la propriété est vérifiée, alors Maude retourne vrai

Sinon, il retourne un contre-exemple : Il est donné sous la forme d’une paire de chemin

Le premier élément représente le chemin depuis l’état initial vers un des états des systèmes (par exemple l’état A)

Le deuxième élément représente une boucle sur l’état A (pourquoi)

Exemple : red modelCheck(initial1, [] wait(b)) .


Core Maude

Satisfaction d’une propriété Une propriété est dite satisfaisable si l’on peut trouver

au moins une structure de Kripke qui la satisfait True est satisfaisable par n’importe quel structure False n’est satisfaisable par n’importe quel structure

On utilise le module SAT-SOLVER Définit la sorte Formula (des formules logiques simples) Il faut établir une relation entre Formula et les propriétés

atomiques de la formule pour laquelle on cherche une structure de Kripke


Core Maude

Exemple :fmod SAT-SOLVER-TEST isextending SAT-SOLVER .extending LTL .ops a b c d e p q r : -> Formula .endfm

On veut chercher une structure qui vérifie la formule LTL : (a et (X b) et (X X ((not c) et [](c ou (X c))))) On utilise :

red satSolve(a /\ (O b) /\ (O O ((~ c) /\ [](c \/ (O c))))) .


Core Maude

Si Maude peut trouver une structure de Kripke qui satisfait la propriété, il l’affiche (comme l’affichage des contre-exemples)

Sinon, il renvoie False


Core Maude

Enfin, Maude peut tester si une formule LTL est une tautologie : red tautCheck((a => (O a)) <-> (a => ([] a))) . red tautCheck((a -> (O a)) <-> (a -> ([] a))) .

f => g = [] (f -> g) Renvoie True ou un contre-exemple

Comment Maude fait-il pour vérifier une tautologie ?

L’outil Maude et les système de réécriture

Documents

Transcript of L’outil Maude et les système de réécriture