SlideShare une entreprise Scribd logo
Génie Logiciel II- Spécification et
Vérification de Systèmes
Leila Jemni Ben Ayed
Ecole Nationale des Sciences de l’Informatique
L’objectif de ce cours est d’introduire la spécification et la
1
L’objectif de ce cours est d’introduire la spécification et la
vérification formelle dans la démarche de développement d’un
système informatique (Raffinement, Abstraction, modularité,
preuve, vérification, formel)
Références.
- David Harel, Michal Politi, Modeling reactive systems with statecharts the statemateapproach,
McGraw-Hill, 1998,
- Kevin Lano, The B language and method: a guide to practical formal development, Springer,
1996,
- Zohar Manna, Amir Pnueili, The Temporal Logic of Reactive and Concurrent Systems:
Specification, Springer, 1992.
- Philippe Schnoebelen, Vérification de logiciels Techniques et outils du model-checking,
Vuibert, 1999.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Plan
I. Spécification et vérification formelle de logiciels
II. La méthode B AMN (Abstract macine notation)
III. La méthode B événementiel
IV. Vérification de modèles (ou model checking)
2
IV. Vérification de modèles (ou model checking)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
I. Spécification et vérification
formelle de logiciels
Plan
I.1.Systèmes automatisés sûrs de fonctionnement
I.2. Nécessité des méthodes formelles dans le cycle de
3
I.2. Nécessité des méthodes formelles dans le cycle de
développement d’un logiciel
I.3.Spécification formelle, vérification et validation
I.4.Comportement, environnement, propriétés
I.5.Formalismes pour représenter des spécifications
I.6.Vérification (par preuve de théorèmes et par
vérification de modèles)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
P
Propriétés
de sûreté
Système
Physique
+
Environnement
Système
Informatique
de commandes
Commandes
I.1. Systèmes automatisés sûrs de
fonctionnement
4
Ces systèmes sont complexes et exigent un niveau de sûreté et
de fiabilité élevé
Propriétés
de vivacité
Environnement
de commandes
Informations sur l’état du
système physique
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Les système présente différentes vues
· Vue fonction : Que doit faire le système dans son
environnement ? Quels sont sa finalité, sa mission et ses
objectifs ?
· Vue structure : De quoi le système est-il fait? Avec quelles
ressources, quelles configurations et quelle organisation le
système fonctionne-t-il ? Comment est-il structuré dans son
I.1. Systèmes automatisés sûrs de
fonctionnement
5
système fonctionne-t-il ? Comment est-il structuré dans son
activité pour remplir sa mission ?
· Vue comportement : Quelle est la dynamique du système ?
Comment le système évolue-t-il ? Comment passe-t-il d’un type
de fonctionnement à un autre ? Quels sont les différents scénarios
possibles de son évolution ? Quelles sont les conditions et
configurations des ressources du système permettant de passer
d’un scénario au suivant ? Comment est-il piloté à la fois pour
atteindre ses objectifs de performance, et pour faire face à un
changement pour s’adapter, s’améliorer, faire face à des incidents,
etc. ?
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
La Vérification cherche d’abord à répondre à la question
« Construisons-nous correctement le modèle ? ». Le but est
de prouver la cohérence du modèle, de s’assurer de la bonne
utilisation des moyens de modélisation et de rendre compte de
I.1. Systèmes automatisés sûrs de
fonctionnement
6
utilisation des moyens de modélisation et de rendre compte de
la description des exigences.
Par définition, la vérification est "la confirmation de preuves que
les exigences spécifiées ont été satisfaites" (ISO 8402).
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
La Validation cherche à répondre à la question
« Construisons-nous le bon modèle ? ». Il s’agit ici de
s’assurer de la pertinence du modèle, voire si possible d’une
certaine forme de complétude au regard du système modélisé,
de ses situations et de ses scénarios d’évolution. La validation
se définit comme la "confirmation que les exigences
particulières pour un usage spécifique prévu sont satisfaites.
I.1. Systèmes automatisés sûrs de
fonctionnement
7
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). Ainsi, la validation permet de lier le
modèle à la réalité attendue ou perçue.
Enfin, il est parfois intéressant de qualifier voire de certifier un
modèle donné. Le but est alors de pouvoir réutiliser ce modèle
en interne comme un modèle de référence de type métier
partageable avec d’autres acteurs ou de prouver sa compliance
avec un standard du marché.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
· Des techniques non formelles : elles consistent à détecter
des erreurs ou ce qui semble l’être en examinant et
expertisant le modèle de manière manuelle au cours
d’expertises, de revues de modèles, de test, etc. Ce sont donc
plutôt des techniques de validation.
· Des techniques semi formelles : il s’agit de techniques
dont le niveau de résultat peut être considéré comme
I.1. Systèmes automatisés sûrs de
fonctionnement
8
dont le niveau de résultat peut être considéré comme
indépendant d’une expertise humaine mais sans pour autant
revêtir un caractère exhaustif et indiscutable. D’un point de vue
statique, il peut s’agir de vérifier la conformité du modèle à un
standard existant. D’un point de vue dynamique, les techniques
usuelles sont la simulation, l’émulation ou le test. Elles ont pour
inconvénient la non exhaustivité des cas envisagés et donc
l’impossibilité de garantir l’absence de fautes. Par exemple, il
est en général impossible de tester un système avec tous les
vecteurs d'entrées théoriquement valables sans risquer une
explosion combinatoire de ces vecteurs.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
De même, on ne peut simuler tous les chemins d'exécution
d’un modèle et seule une partie (critique) de ses
comportements possibles est examinée.
· Des techniques formelles : ce sont des techniques
basées sur l’emploi de méthodes formelles. Elles reposent
sur l’utilisation de langages et de concepts relevant du domaine
I.1. Systèmes automatisés sûrs de
fonctionnement
9
sur l’utilisation de langages et de concepts relevant du domaine
des mathématiques. Par définition, un langage formel est en
effet un langage doté d’une sémantique mathématique
adéquate basée sur des règles d’interprétation qui garantissent
l’absence d’ambiguïté dans les descriptions produites et des
règles de déduction qui permettent de raisonner sur les
spécifications afin de découvrir de potentielles incomplétudes,
inconsistances ou pour prouver des propriétés.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
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
I.1. Systèmes automatisés sûrs de
fonctionnement
10
Spécification
Exigences de l’utilisateur : propriétés attendues
et la vérification de systèmes
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
I.1. Systèmes automatisés sûrs de
fonctionnement
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
11
Automate logiques
temporelles
Automates temporisés logiques
temporisées
Formules |-- Preuve de théorèmes Formules
Logiques logiques
Réduire la complexité et assurer un bon
fonctionnement,
L’utilisation des méthodes formelles apparaît
comme une solution principale
Introduire une phase de spécification formelle
Le système est ainsi spécifié et vérifié avant
I.2. Nécessité des méthodes formelles
dans le Cycle de développement d’un
logiciel
12
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
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Validation
Spécification des besoins du
système
Spécification formelle
I.2. Nécessité des méthodes formelles
dans le Cycle de développement d’un
logiciel
Identification des composants
(modules) utiles
Définition du rôle de
chaque module
Exigences
(Propriétés attendues)
Vérification
13
Tests
Implémentation
Conception
Choix des structures de
données et d’algorithmes
Implémentation
Vérification du respect
des spécifications
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
I.3. Spécification formelle,
validation et vérification
Spécification permet de
comprendre ce que doit faire chaque
composant
14
composant
argumenter sur la cohérence du
composant
énoncer des propriétés sur le système
avant même son développement
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Les méthodes formelles pour la spécification:
consistent à intégrer une étape de vérification
formelle dans les démarches de conception de
logiciels.
reposent sur :
I.3. Spécification formelle,
validation et vérification
15
reposent sur :
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.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
I.3. Spécification formelle,
validation et vérification
Une méthode formelle
Se base sur des notations mathématiques
Permet au spécifieur de décrire rigoureusement, sans
ambiguïté ce que doit réaliser son programme
16
ambiguïté ce que doit réaliser son programme
se base sur une axiomatique qui induit la preuve
Elle permet 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)
A la phase de conception on s’intéresse aux problèmes
d’optimisation
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
La validation permet de
Vérifier si le texte formel traduit bien la
demande informelle faite par celui qui
commande le logiciel
I.3. Spécification formelle,
validation et vérification
17
commande le logiciel
La validation ne peut pas être
automatisée
La spécification permet de s’assurer
de l’adéquation des composants au
cahier des charges
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Une spécification est une référence
pour la suite du développement
Permet au programmeur de :
I.3. Spécification formelle,
validation et vérification
18
Permet au programmeur de :
Décider les langages, bibliothèques…
Décider la complexité
Décider la généricité
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Définir le quoi pas le comment
Nom
Données en entrée
I.3. Spécification formelle,
validation et vérification
19
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
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Une spécification permet à chaque étape du
développement de vérifier que la réalisation
du système respecte les exigences
En conception :
I.3. Spécification formelle,
validation et vérification
20
En conception :
Vérifier si l’algorithme calcule ce qui a été spécifie
En intégration :
Vérifier si le programme réalise le composant
initialement spécifie
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
I.3. Spécification formelle,
validation et vérification
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
21
passe de la spécification à du pseudo-code
Codage: puis on génère automatiquement
du code exécutable
Preuve: On prouve à chaque étape le
respect des spécifications initiales
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
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
I.3. Spécification formelle,
validation et vérification
22
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 le système.
⇒
⇒
⇒
⇒ La vérification formelle doit être
complétée par de la validation à partir de
jeux de tests.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Comment ?
Les voies pour sortir de ces problèmes sont très 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
I.3. Spécification formelle,
validation et vérification
23
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.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Types de propriétés
Sûreté (Safety) Invariants
Quelque chose de mauvais n’arrivera jamais
I.4. Comportement, environnement,
propriétés
24
Quelque chose de mauvais n’arrivera jamais
pas d’accès simultané de A et B à la section
critique
Vivacité (Liveness)
Quelque chose souhaité finira par avoir lieu
si A veut entrer à la section, alors inévitablement
il aura cet accès
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Fatalité
sous certaines conditions quelque chose de bien finira
par avoir lieu au moins une fois à partir d’un certain état".
Dans une logique temporelle
I.4. Comportement, environnement,
propriétés
25
elle s’exprime sous la forme de:
F →
→
→
→ ◊
◊
◊
◊ G



(F →
→
→
→ ◊
◊
◊
◊ G)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Atteignabilité
Ces propriétés énoncent qu’une certaine situation
peut être atteinte.
I.4. Comportement, environnement,
propriétés
26
peut être atteinte.
Nous pouvons exprimer aussi que quelque chose
n’est jamais atteignable et nous parlons alors
d’inatteignabilité.
Dans ce cas, on se situe dans la classe des
propriétés de sûreté.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Equité
énonce que, sous certaines conditions, quelque chose
aura lieu un nombre infini de fois.
Equité faible
I.4. Comportement, environnement,
propriétés
27
Equité faible
exprime que si une transition est continuellement
activable alors elle est infiniment souvent activée.
Equité forte
exprime que si une transition est infiniment souvent
activable alors elle sera infiniment souvent activée.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
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 :
28
Hors service (hs) : tous les feux sont au jaune
En service (es) : ils évoluent selon
rouge ↝
↝
↝
↝ vert ↝
↝
↝
↝ jaune ↝
↝
↝
↝ rouge
Lorsque le feu est au rouge sur une voie, les
véhicules de cette voie ne peuvent s’engager
dans le carrefour
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Contrôleur de feux
de circulation d’un carrefour
Propriétés souhaitées:
Condition de sûreté (safety) : les véhicules ne peuvent s’engager
dans les deux voies simultanément.
on n’a pas les deux feux différents de rouge
Condition de vivacité (liveness) : les véhicules ne sont pas
bloqués infiniment sur l’une des (ou les deux) voies.
29
bloqués infiniment sur l’une des (ou les deux) voies.
on n’a pas les deux feux rouge
Ces propriétés sont décrites par :
((feuA=rouge)∧(feuB≠rouge))∨((feuA≠rouge)∧(feuB=rouge))
Définition de l’état des feux :
ETAT = {es, hs}
etat ∈ ETAT
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Contrôleur de feux
de circulation d’un carrefour
Caractérisation de l’état hors service
Etat = hs ⇔ feuA = jaune ∧ feuB = jaune
Caractérisation de l’état en service
Etat = es ⇒ feuA = rouge ∨ feuB = rouge
30
Etat = es ⇒ feuA = rouge ∨ feuB = rouge
Caractérisation de la disponibilité (état en service)
Etat = es ⇒ feuA ≠ rouge ∨ feuB ≠ rouge
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
+ modèles graphiques, intuitifs,
+ sémantique précise et
rigoureuse
Méthodes semi formelles
STATEMATE, SA-RT, UML
Méthodes formelles
B, Z, CTL, FNLOG
I.5. Formalismes pour représenter
des spécifications
31
+ modèles graphiques, intuitifs,
visualiser, concevoir et de
documenter des systèmes
+ éditeurs visuels, génération du code,
validation
- absence d’une sémantique précise,
pas de vérification des propriétés
- difficiles à utiliser par les
non familiarisés
- manque de support de
communication
- manque de qualité de
structuration
rigoureuse
+ vérification et la validation
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
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)
I.5. Formalismes pour représenter
des spécifications
32
(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
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
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
I.5. Formalismes pour représenter
des spécifications
33
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 Pétri, 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,
etc.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
I.6. 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
34
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.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
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
I.6. Techniques de vérification
35
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.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II. la méthode B (Jean Raymond
Abrial)
Plan
II.1. Présentation
II.2. Notion de machine abstraite
II.3. Les clauses d’une machine abstraite
36
II.4. Les obligations de preuve
II.5. Définition et calcul des substitutions généralisées
II.6. Les substitutions généralisées
II.7. Le processus de raffinement
II.8. Les obligations de preuve du raffinement
II.9. La modularité
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.1. Présentation
Les logiciels conçus avec la méthode B
fonctionnent conformément à leurs spécifications
Les propriétés sont exprimées par des invariants et
vérifiées par preuves formelles.
Le raffinement consiste à reformuler les données
et opérations d'une machine abstraite (Composant
37
et opérations d'une machine abstraite (Composant
initial) à l'aide de données et opérations plus
proches de l'implémentation (Composant raffiné)
tout en conservant les propriétés de la machine
abstraite.
Suppression des pré-conditions
Suppression de l’indéterminisme
Introduction de la séquence et des boucle
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
M2 raffine M1
Par tout où on utilise M1, M2 doit rendre le même service
L'interface externe doit être conservée
Chaque raffinement donne lieu à une preuve de la
validité de la reformulation de la machine abstraite.
II.1. Présentation
38
Chaque raffinement donne lieu à une preuve de la
validité de la reformulation de la machine abstraite.
La dernière phase de raffinement permet d'atteindre
un niveau de pseudo-code que l'outil associé,
l'atelier B, peut alors traduire automatiquement
dans différents langages (C, Ada, C++).
Le test du logiciel devient inutile, puisque le
programme produit est formellement prouvé correct
à la spécification initiale.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Modèle abstrait
Raffinement 1
Preuve du
raffinement
II.1. Présentation
Raffinement
Preuve PA
Preuve PR1
PA: propriété
abstraite
PR: propriété de
Raffinement n-1
Implémentation 2ème … ième raffinement
Raffinement 2
Raffinement n
Preuve PR2
Preuve PRn-1
Preuve PRn
PR: propriété de
raffinement
39
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
1. On définit les données internes de la machine et leurs
propriétés invariantes ;
2. On définit les opérations d’accès à la machine : pré-
condition et transformation ;
3. L’atelier vérifie la syntaxe et le typage ;
II.1. Présentation
40
4. L’atelier calcule les plus faibles pré-conditions et
génère les preuves à faire ;
5. L’atelier tente de les prouver automatiquement ;
6. Si certaines preuves n’ont pas été démontrées, on
détermine si :
1. l’opération est incorrecte et on corrige
2. le prouveur n’est pas assez « fort » et on aide le prouveur à
réaliser la démonstration
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.2. Notion de machine abstraite
En B
On spécifie
On prouve
On développe
On code
Une (ou plusieurs) machine abstraite
41
Une (ou plusieurs) machine abstraite
Cette notion est proche
Type abstrait, Module, Classe, Composant
Un composant logiciel peut être vu comme une fonction
Munie d’une mémoire
Encapsule des données
Dans la méthode B, un composant logiciel est appelé
machine abstraite qui contient:
Des données
Des opérations
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.2. Notion de machine abstraite
Structure d’une machine abstraite
PARIE ENTETE
Nom de la machine
Paramètres de la machine
Contraintes sur les paramètres
42
PARTIE STATIQUE
Déclaration d'ensembles
Déclaration de constantes
Propriétés des constantes
Déclaration des variables (état)
Invariant (caractérisation de l'état)
PARTIE DYNAMIQUE
Initialisation des variables
Opérations
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3. Les clauses d’une MA
MACHINE
Nom de la machine abstraite (idem nom de la classe)
SETS
Déclaration des ensembles abstraits et énumérés
CONSTANTS
Définition des constantes
PROPERTIES
Propriétés sur les constantes
43
Propriétés sur les constantes
VARIABLES
Déclaration des variables (idem attributs d’une classe)
INVARIANT
Typage et propriété des variables
INITIALISATION
Définition de la valeur initiale des variables (idem constructeur)
OPERATIONS
Déclaration des opérations (idem méthodes)
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.1. L’en-tête
Un nom + optionnellement des
paramètres pour la généricité
44
MACHINE MACHINE MACHINE MACHINE
calculatrice réservation pile(ELEMENT) variable (TYPE)
END END END END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.2. Les données
La définition des données s’appuie sur un langage
d’expressions
les symboles désignant les données de base de la machine
(ensembles abstraits, variables, constantes…)
les expressions booléennes
45
les expressions booléennes
les expressions arithmétiques
les ensembles, relations, fonctions,
les suites…
Ces données sont caractérisées par un invariant
Une formule de la logique des prédicats exprimée au moyen
de prédicats ensemblistes (appartenance, inclusion…) et
d’opérateurs relationnels.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.2. Les données
Les données d'une "machine abstraite" sont décrites au moyen des clauses
suivantes:
la clause MACHINE : elle introduit le nom qui identifie la machine.
la clause SETS : elle représente les ensembles introduits par la
machine. Ce sont soit des ensembles abstraits, soit des ensembles
46
machine. Ce sont soit des ensembles abstraits, soit des ensembles
énumérés définis par la liste de leurs éléments. Les ensembles
abstraits sont utilisés pour désigner des objets dont on ne veut pas définir la
structure au niveau de la spécification.
La clause CONSTANTS: déclare une liste de constantes.
La clause PROPERTIES: définit un prédicat qui type les constantes et
spécifie des conditions sur les constantes et les ensembles de la machine
abstraite.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.2. Les données
la clause VARIABLES : elle introduit la liste des variables de la machine.
Elles représentent l´état de la machine. Les variables sont les seules objets
qui peuvent être modifiés directement dans l'initialisation et les opérations de
la machine. Cette clause doit être accompagnée des clauses INVARIANT et
INITIALISATION. Elle peut être absente si la machine n'a pas de variables.
47
la clause INVARIANT : elle regroupe un ensemble de prédicats. Ces
prédicats définissent les propriétés mathématiques des variables de la
machine, et permettent de typer les variables et de définir certaines
contraintes que doit vérifier l'état de la machine à tout moment. Cette clause
est obligatoire si la clauses VARIABLE est présente.
Les invariants de typage ( var ∈ ENSEMBLE )
Les propriétés sur les variables de la machine ou propriétés de
sûreté (¬(var1=TRUE ∧ var2=TRUE))
Les propriétés ensemblistes ( f∈ SET1 × SET2→ N)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.2. Les données
• Des constantes munies de propriétés
• Des variables munies d’ un invariant
MACHINE En-tête
CONSTANTS
Liste des constantes
48
Liste des constantes
PROPERTIES
Propriétés des constantes
VARIABLES
Liste des variables
INVARIANT
Invariant des variables
…
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.2. Les données
Une machine sans variable
MACHINE Unité_arithmétique
CONSTANTS
min_ent, max_ent, ENTIER
49
min_ent, max_ent, ENTIER
PROPERTIES
min_ent = -231
max_ent = 231 - 1
ENTIER = min_ent .. max_ent
…
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.2. Les données
Une machine avec variables
• Il est fondamental qu’une machine avec variable soit munie d’un
invariant : il permet d’ exprimer les exigences de
fonctionnement de la machine.
50
MACHINE Chaudière
SETS
ETATS = {arm, dsm}
VARIABLES
T, Alarme
INVARIANT
T ∈
∈
∈
∈ NAT ∧
∧
∧
∧ Alarme ∈
∈
∈
∈ ETATS ∧
∧
∧
∧
(T > 130) ⇒
⇒
⇒
⇒ (Alarme = arm)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.3. La partie dynamique
la clause INITIALISATION : elle se compose des substitutions qui définissent les
valeurs initiales de chaque variable propre à la machine. Toute variable propre à la
machine doit être initialisée. Cette initialisation doit satisfaire l'invariant de la machine.
Cette clause est obligatoire si la clause VARIABLE est présente.
la clause DEFINITIONS : elle contient une liste d'abréviations pour un
prédicat, une expression ou une substitution. Les définitions peuvent être
51
prédicat, une expression ou une substitution. Les définitions peuvent être
utilisées dans la suite de la machine et sont locales à la machine où elles
sont définies.
La clause OPERATIONS définit une liste d’opérations. Ces opérations peuvent être
paramétrées en entrée (w) et en sortie (u) par une liste de scalaires. Les paramètres, en
entrée, éventuels d’une opération sont typés explicitement dans la pré-condition Q de
l’opération. En revanche, les paramètres en sortie éventuels d’une opération sont typés
implicitement en fonction de type des expressions définissant la valeur de ces
paramètres dans la substitution V qui définit le comportement de l’opération vis à vis de
l’état de la machine. Il est important de noter que les opérations d’une machine ne
peuvent pas être référencées dans la machine où elles sont définies.
u← O(w) = pre Q then V end
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : réservation
MACHINE
reservation
VARIABLES
nbPlacesLibres, capacite
52
nbPlacesLibres, capacite
INVARIANT
nbPlacesLibres ∈ NAT ∧
capacite∈ NAT ∧
nbPlacesLibres ≤ capacite
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.4. Les opérations
Une en-tête
liste des paramètres de sortie <-- NOM (liste des paramètres d’entrée)
Une pré-condition
Typage des paramètres d’entrée
Conditions de fonctionnement de l’opération (domaine
53
Conditions de fonctionnement de l’opération (domaine
de définition)
Une transformation
Définition de l’opération comme une transformation des
données internes et une affectation de valeurs aux
paramètres de sortie
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.4. Les opérations
MACHINE Unité_arithmétique
…
OPERATIONS
ecrire_nombre (a) ... ;
54
a ‹ — lire_nombre ... ;
c ‹ — plus (a, b) ... ;
c ‹ — moins (a, b) ... ;
c ‹ — mult (a, b) ... ;
c, d ‹ — div_mod (a, b) ... ;
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.4. Les opérations
Opérations avec precondition
• Une précondition sert d’hypothèse pour prouver l’ opération
• Il faut prouver que la précondition est satisfaite pour utiliser l’ opération
MACHINE Unité_arithmétique
…
OPERATIONS
55
OPERATIONS
…
r ‹ — plus (a, b) =
PRE
a ∈ ENTIER ∧
b ∈ ENTIER ∧
a + b ∈ ENTIER
THEN
r := a + b
END ;
...
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.4. Les opérations
r, o ‹ — add (a, b) =
PRE
a ∈ ENTIER ∧
b ∈ ENTIER
THEN
IF a + b ∈ ENTIER
THEN
56
THEN
r := a + b ||
o := false
ELSE
o := true
END
END
...
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.4. Les opérations
MACHINE Chaudière
SETS
ETATS = {arm, dsm}
VARIABLES
T, Alarme
INVARIANT
T ∈ NAT ∧
Alarme ∈ ETATS ∧
⇒
57
Alarme ∈ ETATS ∧
(T > 130) ⇒ (Alarme = arm)
OPERATIONS
changerT (v) ==
PRE
v ∈ NAT ∧ v ≤ 130
THEN
T := v
END
…
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : reservation
MACHINE
reservation
…
OPERATIONS
58
OPERATIONS
reserver(nbPlaces)=
PRE
nbPlaces ∈ NAT1 ∧
nbPlaces ≤ nbPlacesLibres
THEN
Transformation
END
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.3.5. Les transformations
La définition des opérations s’appuie sur
le langage des substitution généralisées
La transformation de base est la substitution
simple devient égal, notée :=
59
simple devient égal, notée :=
Les autres transformations permettent de
modéliser le résultat de tous les
changements d’états réalisables par
algorithmique
Les boucles en particulier sont souvent
modélisées par des substitutions indéterministes
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : reservation
reserver(nbPlaces)=
PRE
nbPlaces ∈ NAT1 ∧
nbPlaces ≤ nbPlacesLibres
60
nbPlaces ≤ nbPlacesLibres
THEN
nbPlacesLibres := nbPlacesLibres-nbPlaces
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.4. Les obligations de preuve
(Preuve de cohérence)
La dernière étape de la spécification consiste à
prouver la cohérence de chaque machine
abstraite
C’est l’obligation de preuve
On prouve que l’initialisation vérifie l’invariant
61
On prouve que l’initialisation vérifie l’invariant
On prouve pour chaque opération que
lorsque la machine est dans un état correct
→
→
→
→ les propriétés invariantes I sont supposées vérifiées
lorsque l’opération est appelée avec la
→
→
→
→ la pré-condition Q d’appel est supposée vérifiée
alors sa transformation V amène la machine dans un état
correct →
→
→
→ un état qui satisfait l’invariant I
(Les points fort de B sont la génération automatique des
obligations de preuve et le raffinement)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
MACHINE
M
VARIABLES Obligation de preuve pour l’initialisation
V Init ⇒
⇒
⇒
⇒ I
INVARIANT Obligation de preuve pour une opération o
I
II.4. Les obligations de preuve
(Preuve de cohérence)
62
I
OPERATIONS I ∧
∧
∧
∧ Q ⇒
⇒
⇒
⇒ I après V
u ← O(W) =
PRE
Q
THEN
V
END
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Substitution
[x:=E]P représente la formule P dans laquelle
toutes les occurences libres de x sont
remplacées par E
Si V est x:=E alors [V]I décrit l’état de l’invariant
II.4. Les obligations de preuve
(Preuve de cohérence)
63
Si V est x:=E alors [V]I décrit l’état de l’invariant
après l’exécution de V
Si x est une des variables utilisées dans I alors
la substitution traduit bien l’effet de V
Obligation de preuve pour une opération de
précondition Q et d’action V est alors
[Init] I
I ∧
∧
∧
∧ Q ⇒
⇒
⇒
⇒ [V]I
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : réservation
MACHINE I ∧
∧
∧
∧ Q ⇒
⇒
⇒
⇒ [V]I
reservation
VARIABLES
nbPlacesLibres, capacite
INVARIANT
nbPlacesLibres ∈ NAT ∧
capacite∈ NAT ∧
I
64
capacite∈ NAT ∧
nbPlacesLibres ≤ capacite
OPERATIONS
reserver(nbPlaces)=
PRE
nbPlaces ∈ NAT1 ∧
nbPlaces ≤ nbPlacesLibres
THEN
nbPlacesLibres := nbPlacesLibres-nbPlaces
END
END ```
I
Q
V
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
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 :
65
Hors service (hs) : tous les feux sont au jaune
En service (es) : ils évoluent selon
rouge ↝
↝
↝
↝ vert ↝
↝
↝
↝ jaune ↝
↝
↝
↝ rouge
Lorsque le feu est au rouge sur une voie, les
véhicules de cette voie ne peuvent s’engager
dans le carrefour
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Contrôleur de feux
de circulation d’un carrefour
Propriétés souhaitées:
Condition de sécurité (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.
Ces propriétés sont décrites par :
66
Ces propriétés sont décrites par :
((feuA=rouge)∧(feuB≠rouge))∨((feuA≠rouge)∧(feuB=rouge))
Définition des couleurs des feux :
COULEUR = {rouge , jaune , vert}
feuA ∈ COULEUR ,
feuB ∈ COULEUR
Définition de l’état des feux :
ETAT = {es, hs}
etat ∈ ETAT
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Contrôleur de feux
de circulation d’un carrefour
Caractérisation de l’état hors service
Etat = hs ⇔ feuA = jaune ∧ feuB = jaune
Caractérisation de l’état en service
Etat = es ⇒ feuA = rouge ∨ feuB = rouge
Caractérisation de la disponibilité (état en service)
⇒
67
⇒
Caractérisation de la disponibilité (état en service)
Etat = es ⇒ feuA ≠ rouge ∨ feuB ≠ rouge
L’ évolution des feux est décrite par une fonction
constante: Suiv ∈ Couleur → Couleur
Les opérations sur les feux de circulation sont:
Mise en service
Mise hors service
Changer feu
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Contrôleur de feux
de circulation d’un carrefour
MACHINE
Carrefour
SETS
Couleur = {rouge, jaune, vert}
CONSTANT
Suiv
PROPERTIEES
Suiv ∈
∈
∈
∈ Couleur X Couleur ∧
∧
∧
∧
∧
∧
∧
∧
68
Suiv(rouge) = vert ∧
∧
∧
∧
Suiv(vert) = jaune ∧
∧
∧
∧
Suiv(jaune) = rouge
VARIABLES
feuA, feuB
DEFNITIONS
hs == feuA = jaune ∧
∧
∧
∧ feuB = jaune
service(aa, bb) = (aa = rouge ∧
∧
∧
∧ bb ≠
≠
≠
≠ rouge) ∨
∨
∨
∨ (aa ≠
≠
≠
≠ rouge ∧
∧
∧
∧ bb = rouge)
es == service(feuA, feuB)
INVARIANT
feuA, feuB ∈
∈
∈
∈ Coulur X Couleur ∧
∧
∧
∧ (hs ∨
∨
∨
∨ es)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Contrôleur de feux
de circulation d’un carrefour
INITIALISATION
feuA, feuB := jaune, jaune
OPERATIONS
Mise-en-service = PRE hs
THEN ANY fa, fb WHERE
fa, fb ∈
∈
∈
∈ Couleur X Couleur ∧
∧
∧
∧ Service(fa, fb)
THEN
feuA := fa
feuB := fb
69
feuB := fb
END
END
Mise-hors-service = PRE es
THEN
feuA, feuB := jaune, jaune
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Controleur de feux
de circulation d’un carrefour
Changer-feu = PRE es
THEN
ANY fa, fb WHERE
((fa = feuA ∧
∧
∧
∧ fb = suiv(feuB)) ∨
∨
∨
∨
(fa = suiv(feuA) ∧
∧
∧
∧ fb = feuB) ∨
∨
∨
∨
(fa = suiv(feuA) ∧
∧
∧
∧ fb = suiv(feuB))) ∧
∧
∧
∧
service(fa, fb)
THEN
feuA, feuB := fa, fb
70
feuA, feuB := fa, fb
END
END
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Réservation de places
sur un vol limité à maxi places
MACHINE
RESERVATION1
CONSTANT
Maxi
PROPERTIES
OPERATIONS
Réserver
PRE Nb ≠ 0
THEN
Nb := Nb –1
71
PROPERTIES
Maxi ∈ NAT
VARIABLES
Nb
INVARIANT
Nb ∈ 0..Maxi /*nbre de places*/
INITIALISATION
Nb := Maxi
Nb := Nb –1
END ;
Libérer
PRE Nb ≠ Maxi
THEN
Nb := Nb + 1
END ;
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Réservation de places
sur un vol limité à maxi places
OPERATIONS
Réserver
PRE Nb ≠ 0
THEN
Nb := Nb –1
72
END ;
Libérer
PRE Nb ≠ Maxi
THEN
Nb := Nb + 1
END ;
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Réservation de places
sur un vol limité à maxi places
Ajout de la gestion des réservations
MACHINE
RESERVATION2(Maxi)
CONSTRAINTS
Maxi ∈ NAT
SETS
73
SETS
RES = {succès, échec}
VARIABLES
Nb
INVARIANT
Nb ∈ 0..Maxi /*nbre de places*/
INITIALISATION
Nb := Maxi
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Réservation de places
sur un vol limité à maxi places
OPERATIONS
R1 ←
←
←
← Réserver ≅
≅
≅
≅
If Nb ≠
≠
≠
≠ 0
THEN
R1, Nb := succès, Nb -1
ELSE
R1 := Echec
74
R1 := Echec
END ;
R2 ←
←
←
← Libérer ≅
≅
≅
≅
If Nb ≠
≠
≠
≠ Maxi
THEN
R2, Nb := succès, Nb + 1
Else
R2 := Echec
END ;
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Réservation de places
sur un vol limité à maxi places
Ajout de la gestion des places
MACHINE
RESERVATION3(Maxi)
CONSTRAINTS
Maxi ∈ NAT
75
Maxi ∈ NAT
DEFINITION
Sièges == 1..Maxi
VARIABLES
Occupés
INVARIANT
Occupés ⊆ Sièges
INITIALISATION
Occupés := ∅
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Réservation de places sur un
vol limité à maxi places
OPERATIONS
Place ←
←
←
← Réserver ≅
≅
≅
≅
PRE
Occupés ≠
≠
≠
≠ Sièges
THEN
ANY pp WHERE
pp ∈
∈
∈
∈ Sièges – Occupés
THEN
76
THEN
Place, Occupés := pp, Occupés ∪
∪
∪
∪ {pp}
END
END ;
Libérer (place) ≅
≅
≅
≅
PRE place ∈
∈
∈
∈ Occupés
THEN
Occupés := Occupés  {place}
END ;
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple: Distributeur de boissons
On souhaite spécifier le fonctionnement d’une machine qui délivre des boissons.
Le fonctionnement est décrit comme suit :
La machine peut être en arrêt ou en marche,
Il y a un bouton pour mettre en marche et arrêter la machine
Les actions suivantes n’ont d’effet que si la machine est en marche
- L’usager peut sélectionner une certaine boisson. Il y en a 3 : café, thé ou
chocolat.
77
chocolat.
- Après la sélection, l’appareil affiche la somme demandée.
- L’usager peut alors payer avec les différentes pièces de monnaie.
- L’appareil affiche la somme restante.
- Dès qu’une somme suffisante est versée, l’appareil délivre la boisson à l’usager.
- L’appareil rend éventuellement la monnaie.
- On ne peut commander une nouvelle boisson que si le Goblet a été retiré de son
emplacement.
- A tout moment après la sélection de la boisson et avant que le distributeur ne
délivre la boisson, l’usager peut annuler la commande. L’appareil doit alors
rendre l’argent déjà versé s’il y a lieu
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5. Les substitutions généralisées
Substitutions multiples
Choix borné
78
Substitution gardée
Substitution vide
Choix non borné.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5. Les substitutions généralisées
79
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5.1. Substitutions multiples
Syntaxes
x := E | | y := F
x, y := E, F
80
sémantique
[x, y := E, F] I [z := F][x := E][y := z]I
[x := E | | y := F] I z étant une variable
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5.1. Substitutions multiples
Exemple
[x, y := y, x] (x < y)
[z := x][x := y][y := z] (x < y)
[z := x][x := y] (x < z)
81
[z := x][x := y] (x < z)
[z := x] (y < z)
(y < x)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5.2. Substitution choix borné
Syntaxe
[S [] T]
[CHOICE S OR T END]
82
[CHOICE S OR T END]
Sémantique
[S [] T]I [S]I ∧
∧
∧
∧ [T]I
[CHOICE S OR T END]I
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5.2.Substitution choix borné
Exemple
d ‹ — empiler(w) =
PRE w ∈
∈
∈
∈ VALEUR
THEN
83
CHOICE
d := ok | |
sequence := sequence ‹ — w
OR
d := ko
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple: Select (Garde et
Choix Borné)
Exprime un choix de substitution sous
condition
SELECT P1 THEN S1 P1 ⇒
⇒
⇒
⇒ S1 []
⇒
⇒
⇒
⇒
84
SELECT P1 THEN S1 P1 ⇒
⇒
⇒
⇒ S1 []
[WHEN P2 THEN S2 P2 ⇒
⇒
⇒
⇒ S2 []
… ≈
≈
≈
≈ …
WHEN Pn THEN Sn] Pn ⇒
⇒
⇒
⇒ Sn []
[ELSE SE] ¬
¬
¬
¬P1∧¬
∧¬
∧¬
∧¬P2∧
∧
∧
∧…∧¬
∧¬
∧¬
∧¬Pn ⇒
⇒
⇒
⇒ SE
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Construction d’un SELON
E une expression
Li des listes de constantes toutes 2 à 2
distinctes et de même type que E
⇒
⇒
⇒
⇒
85
distinctes et de même type que E
CASE E OF
EITHER L1 THEN S1 E∈
∈
∈
∈{L1} ⇒
⇒
⇒
⇒ S1 []
[OR L2 THEN S2 E∈
∈
∈
∈{L2} ⇒
⇒
⇒
⇒ S2 []
… ≈
≈
≈
≈ …
OR Ln THEN Sn] E∈
∈
∈
∈{Ln} ⇒
⇒
⇒
⇒ Sn []
[ELSE SE] E∉
∉
∉
∉{L1,L2…Ln} ⇒
⇒
⇒
⇒ SE
END (en l absence de ELSE
END SKIP)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Construction d’un SELON
CASE x/10 OF
EITHER 0 THEN
x:=0
OR 2,4,8 THEN
x:=2
OR 3,9 THEN
86
OR 3,9 THEN
x:=1
ELSE
x:=-1
END
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5.3. Substitutions gardée
Syntaxe
IF P THEN S END [P ⇒
⇒
⇒
⇒ S]
⇒
⇒
⇒
⇒ ⇒
⇒
⇒
⇒
87
⇒
⇒
⇒
⇒
Sémantique
[P ⇒
⇒
⇒
⇒ S]I P ⇒
⇒
⇒
⇒ [S]I
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5.3. Substitutions gardée
Exemple
IF v > 130 THEN
T := v | | Alarm := arm
else
88
else
T := v
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5.3. Substitution gardée
Ne pas confondre avec la pré-condition
Précondition Définition
[P | S ] I P ∧
∧
∧
∧ [S]I
PRE P THEN S END
89
Si-alors-sinon
Conditionnelle Définition
[IF P THEN S ELSE T END ]I (P ⇒
⇒
⇒
⇒ [S]I) ∧
∧
∧
∧ (¬
¬
¬
¬P ⇒
⇒
⇒
⇒ [T]I)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Forme générale du IF
IF P1 THEN S1 P1 ⇒
⇒
⇒
⇒ S1 []
[ELSIF P2 THEN S2 ¬
¬
¬
¬P1∧
∧
∧
∧P2 ⇒
⇒
⇒
⇒ S2 []
… ≈
≈
≈
≈ …
⇒
⇒
⇒
⇒
⇒
⇒
⇒
⇒
90
⇒
⇒
⇒
⇒
… ≈
≈
≈
≈ …
ELSIF Pn THEN Sn] ¬
¬
¬
¬P1∧¬
∧¬
∧¬
∧¬P2∧
∧
∧
∧…¬
¬
¬
¬Pn-1∧
∧
∧
∧Pn ⇒
⇒
⇒
⇒ Sn []
[ELSE SE] ¬
¬
¬
¬P1∧¬
∧¬
∧¬
∧¬P2∧
∧
∧
∧…¬
¬
¬
¬Pn-1∧¬
∧¬
∧¬
∧¬Pn ⇒
⇒
⇒
⇒ SE
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5.4. Substitution vide
Skip : spécifie que l’état de la machine n’est pas modifié
Substitution vide Définition
[skip]I I
91
Si-alors
Conditionnelle Définition
[IF P THEN S END]I [(P ⇒
⇒
⇒
⇒ S) ∧
∧
∧
∧ (¬
¬
¬
¬P ⇒
⇒
⇒
⇒ skip)]I
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5.5. Substitution Choix non
borné
laisse le choix entre plusieurs valeurs satisfaisant
une propriété spécifiée
On utilise une variable intermédiaire contrainte par une
formule P et on exprime la substitution avec cette variable
Syntaxe
@z.(P ⇒
⇒
⇒
⇒ S)
92
@z.(P ⇒
⇒
⇒
⇒ S)
ANY z WHERE P THEN S END
Sémantique
[@z.(P ⇒
⇒
⇒
⇒ S)]I ≡
≡
≡
≡ ∀
∀
∀
∀z.[P ⇒
⇒
⇒
⇒ S]I
≡
≡
≡
≡ ∀
∀
∀
∀z.(P ⇒
⇒
⇒
⇒[S]I)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.5.5. Substitution Choix non
borné
Exemple
b ‹ — nouveau_né(s) =
PRE
PERSONNES - personnes ≠
≠
≠
≠ Φ ∧
∧
∧
∧ s ∈
∈
∈
∈ GENRE
THEN
93
ANY m WHERE
m ∈
∈
∈
∈ PERSONNES - personnes
THEN
personnes := personnes ⋃
⋃
⋃
⋃ { m } | |
genre(m) := s | | etat(m) := vivant | |
b := m
END
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Dérivées du choix non borné
Substitution « devient élément de »
x:∈
∈
∈
∈E
Exemple : nbPlaceLibre:∈Natural
94
Substitution « devient tel que »
x:(P)
Exemple : x:(x<100 ∧ x>x$0)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple de calcul de
substitution
I ∧ Q ⇒ [V]I devient
1. T ∈ NAT ∧ Alarme ∈ ETATS ∧
((T > 130) ⇒ (Alarme = arm))
∧ v ∈ NAT ∧ v ≤ 130
⇒
[T := v]
(T ∈ NAT ∧
Alarme ∈ ETATS ∧
MACHINE Chaudiere
SETS
ETATS = {arm, dsm}
VARIABLES
T, Alarme
INVARIANT
95
Alarme ∈ ETATS ∧
((T > 130) ⇒ (Alarme = arm)))
Après application de la
substitution, on obtient:
2. T ∈ NAT ∧
Alarme ∈ ETATS ∧
((T > 130) ⇒ (Alarme = arm))
∧ v ∈ NAT ∧ v ≤ 130
⇒
(v ∈ NAT ∧
Alarme ∈ ETATS ∧
((v > 130) ⇒ (Alarme = arm))).
INVARIANT
T ∈ NAT ∧
Alarme ∈ ETATS ∧
(T > 130) ⇒ (Alarme = arm)
OPERATIONS
changerT (v) ==
PRE
v ∈ NAT ∧ v ≤ 130
THEN
T := v
END
…
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple de calcul de
substitution
I ∧ Q ⇒ [V]I devient
1. T ∈ NAT ∧ Alarme ∈ ETATS ∧
((T > 130) ⇒ (Alarme = arm))
∧ v ∈ NAT ∧ alarme = dsm
⇒
(v ≤ 130 ⇒ [T := v]
(T ∈ NAT ∧
Alarme ∈ ETATS ∧
MACHINE Chaudiere
SETS
ETATS = {arm, dsm}
VARIABLES
T, Alarme
INVARIANT
96
Alarme ∈ ETATS ∧
((T > 130) ⇒ (Alarme = arm)))
∧(v > 130 ⇒
[T := v] [alarme := arm]
(T ∈ NAT ∧
Alarme ∈ ETATS ∧
((T > 130) ⇒ (Alarme = arm)))
∧
[T :=V][alarme := arm]
(T ∈ NAT ∧
Alarme ∈ ETATS ∧
((T > 130) ⇒ (Alarme = arm)))
INVARIANT
T ∈ NAT ∧
Alarme ∈ ETATS ∧
(T > 130) ⇒ (Alarme = arm)
OPERATIONS
changerT (v) ==
PRE
v ∈ NAT ∧ alarme = dsm
THEN
if (v ≤ 130) then T := v
else T:= V || alarme := arm
END
…
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6. Notation de modélisation
des données
Un langage pour décrire
INVARIANT, PRE-CONDITION,
EXPRESSION
97
EXPRESSION
Concepts et notations utilisés
Logique
Ensembles
Relations binaires et fonctions
Arithmétique
Suites
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.1. Logique : connecteurs
ET ∧ (ASCII : &)
OU ∨ (ASCII : or)
NON ¬ (ASCII : not)
98
NON ¬ (ASCII : not)
SI-ALORS ⇒
⇒
⇒
⇒ (ASCII : =>)
EQUIV. ⇔ (ASCII : <=>)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.1. Logique : quantificateurs
Universel
∀
∀
∀
∀ listeDeVariables . (P ⇒
⇒
⇒
⇒ Q) (ASCII : !)
∀ x,y . (x∈ NAT ∧ y∈ NAT ∧
x=quantite(y) ⇒
⇒
⇒
⇒ x≥0)
Existentiel
99
Existentiel
∃
∃
∃
∃ listeDeVariables . (P) (ASCII : #)
∃ x . (x∈ NAT∧ x=0)
Predicat =
=
≠ (/= en ASCII).
Couple
(a,b) (en B symbole maplet |-> : a|->b)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.2. Ensemble : désignation
Définit par Extension
E={1,3,5,7,9}
Définit par Compréhension
100
Définit par Compréhension
E={x | x ∈ Z ∧ x>0 ∧ x<10 ∧ x mod 2 =1}
L’ensemble vide
{}
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.2. Ensemble : les prédéfinis
N les entiers naturels (NATURAL en ASCII)
N* les entiers naturels non nuls (NATURAL1 en ASCII)
Z les entiers relatifs (INTEGER en ASCII)
I..J les intervalles d’entier, l’ensemble des valeurs comprises entre
101
I..J les intervalles d’entier, l’ensemble des valeurs comprises entre
I et J (bornes incluses)
INT les entiers relatifs implantables : MININT..MAXINT
NAT les entiers naturels implantables : 0..MAXINT
NAT1 les entiers naturels non nuls implantables : 1..MAXINT
BOOL les booléens = {FALSE,TRUE}
bool(P) retourne le booléen résultat d’une formule FOL
STRING l’ensemble des chaînes de caractères.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.2. Ensemble : les prédicats
x ∈ E (: en ASCII)
E1 ⊆ E2 (<: en ASCII, ⊂ notée <<:)
E1 x E2 (* en ASCII)
Produit cartésien non commutatif
102
Produit cartésien non commutatif
a|->b ≠ b|->a
P(E) (POW en ASCII)
Négation des prédicats par le symbole /
∉ devient /: en ASCII
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.2. Ensemble : les prédicats
x ∈ E (: en ASCII)
E1 ⊆ E2 (<: en ASCII, ⊂ notée <<:)
E1 x E2 (* en ASCII)
Produit cartésien non commutatif
103
Produit cartésien non commutatif
a|->b ≠ b|->a
P(E) (POW en ASCII)
Négation des prédicats par le symbole /
∉ devient /: en ASCII
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.2. Ensembles : les opérateurs
l’union E1 ∪ E2 (/ en ASCII)
l’ensemble des éléments appartenant à E1 ou E2
l’intersection E1 ∩ E2 (/ en ASCII)
l’ensemble des éléments appartenant aux deux
104
ensembles E1 et E2
la différence E1 - E2
l’ensemble des éléments appartenant à E1 mais pas à E2
choice(E)
un élément indéterminé de l’ensemble E
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.3. Relations binaires:
vocabulaire
r est un sous-ensemble du produit
cartésien D x A de deux ensembles
D : ensemble de départ
105
D : ensemble de départ
A : ensemble d’arrivée
Soit un couple d|->a d’une relation r
a est une image de d par r
d est un antécédent de a par r
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.3. Relations binaires:
vocabulaire
r est un sous-ensemble du produit
cartésien D x A de deux ensembles
D : ensemble de départ
106
D : ensemble de départ
A : ensemble d’arrivée
Soit un couple d|->a d’une relation r
a est une image de d par r
d est un antécédent de a par r
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.3. Relations binaires:
déclaration et Opérations
r ⊆ D x A ou r ∈ P(D x A) ou
r ∈
∈
∈
∈ D↔A
r est une relation de D dans A
D↔A désigne l’ensemble de toutes les relations de D vers A
D↔A = P(D x A)
noté <-> en ASCII
107
noté <-> en ASCII
Le domaine : dom(r)
l’ensemble des éléments de D qui ont une image par r
{d | d∈D ∧ ∃a.(a∈A ∧ (d,a)∈r)}
Le co-domaine (« range ») : ran(r)
l’ensemble des éléments de A qui ont un antécédent par r
{a | a∈A ∧ ∃d.(d∈D ∧ (d,a)∈r)}
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.3. Relations binaires:
déclaration et Operations
Soit r ∈ D↔A et q ∈ A↔C
l’inverse : r-1 (r~ en ASCII)
la relation de A↔D définie par
{(a,d) | (a,d)∈AxD ∧ (d,a) ∈ r}
la composition : r;q
108
la composition : r;q
la relation de D↔C définie par
{(d,c) | (d,c)∈DxC ∧ ∃ a.(a ∈ A ∧ (d,a) ∈ r ∧ (a,c) ∈ q)}
l’ensemble d’arrivée de r doit être identique à celui de
départ de q
la relation identité sur un ensemble : id(D)
la relation de D↔D définie par
{(d,a) | (d,a)∈DxD ∧ d=a}
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.3. Relations binaires:
déclaration et Operations
Soit r ∈ D↔A et E⊆D et B⊆A
la restriction de domaine : E r (<| en ASCII)
la relation incluse dans r définie par
{(d,a) | (d,a)∈r ∧ d ∈ E} ;
la co-restriction : r B (|> en ASCII)
109
la co-restriction : r B (|> en ASCII)
la relation incluse dans r définie par
{(d,a) | (d,a)∈r ∧ a ∈ B} ;
l’anti-restriction : E r (<<| en ASCII)
la relation incluse dans r définie par
{(d,a) | (d,a)∈r ∧ d∉E}
l’anti-co-restriction : r B (|>> en ASCII)
la relation incluse dans r définie par
{(d,a) | (d,a)∈r ∧ a∉B}
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.3. Relations binaires:
déclaration et Operations
Soit r∈D↔A et p∈D↔A
L’image relationnelle : r[E]
l’ensemble des images des éléments de E par r
{a | a∈A ∧ ∃d.(d∈E ∧ (d,a)∈r)}
110
{a | a∈A ∧ ∃d.(d∈E ∧ (d,a)∈r)}
La surcharge : r<+p
l’écrasement de la relation par la relation p
{(d,a) | (d,a)∈DxA ∧ ((d,a)∈p ∨
(d∉dom(p) ∧ (d,a)∈r))}
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.4. Fonctions: 4 caractéristiques
la fonction totale (-->)
tout élément de l’ensemble de départ a une et une seule image
La fonction partielle (+->)
tout élément de l’ensemble de départ a au plus une image
111
l’injection (>-)
tout élément de l’ensemble d’arrivée a au plus un antécédent
la surjection (->>)
tout élément de l’ensemble d’arrivée a au moins un antécédent
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.4. Fonctions : nouveaux
opérateurs
l’image fonctionnelle d’un élément : f(x)
f doit être une fonction
x doit appartenir à son domaine
fonctions abstraites (lambda expressions) :
112
fonctions abstraites (lambda expressions) :
λ
λ
λ
λx.(x∈
∈
∈
∈D | e)
D est le domaine de définition de la fonction
e une expression paramétrée par x définissant
l’image pour tout x de D
(λ noté % en ASCII)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.5. Arithmétique des entiers
Les comparateurs
<, >, ≤, ≥ (<= et >= en ASCII)
Les opérateurs binaires
113
Les opérateurs binaires
+, -, *, / (la division entière)
mod (le modulo)
xy (x**y en ASCII)
Les opérateurs unaires
succ, pred
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.6. Arithmétique des ensembles
L’opérateur card(E) : Le nombre d’éléments d’un ensemble
Les opérateurs max(E) et min(E)
Prennent un ensemble d’entiers non vide en paramètre
Retourne l’entier le plus grand (resp. le plus petit) de
l’ensemble
114
Les opérateurs ∑ et ∏ (SIGMA et PI en ASCII)
Calculent la somme (le produit) d’expressions arithmétiques
∑(x,y…).(P | E)
P est une formule de la logique des prédicats et E une
expression arithmétique (P et E dépendant des variables
x,y…)
Somme pour toutes valeurs de variables x,y… satisfaisant
P des expressions E correspondants aux valeurs des
variables
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Opérateurs sur les ensembles
115
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Opérateurs sur les relations
116
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Opérateurs sur les relations
117
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Opérateurs sur les relations
118
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Application à la
modélisation
Soit un ensemble personne ⊆ PERSONNE :
R1 : toute personne est soit un homme, soit une femme
R2 : une personne ne peut être à la fois un homme et une femme
R3 : seules les femmes peuvent avoir un mari qui est un homme
119
R4 : les femmes ont au plus un mari
R5 : les hommes ne peuvent être mariés qu’à au plus une femme
R6 : les mères d’une personne sont des femmes mariées
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Application à la
modélisation
120
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Application à la
modélisation d’un ascenseur
On souhaite spécifier le fonctionnement simplifié d’un ascenseur.
une porte à chaque étage
l’appel intérieur et l’appel extérieur ne sont pas distingués
il n’y a pas de panne
une constante donne le nombre d’étages : max_etage (> 0)
Les opérations sont :
121
Les opérations sont :
ouvrir, fermer une porte,
appeler l’ascenseur,
déplacement de l’ascenseur
l’ascenseur reste dans la limite des étages
si une porte est ouverte l’ascenseur est arrêté à l’étage correspondant
chaque appel est traité en un temps raisonnable
si l’ascenseur est arrêté à un étage, l’appel à cet étage est considéré comme traité
. . .
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Application à la
modélisation d’un ascenseur
122
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Distributeur de
carnets de timbres
123
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Distributeur de
carnets de timbres
124
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Distributeur de
carnets de timbres
125
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Application à la
modélisation
Problème :
On veut spécier une opération qui alloue un mot dans une mémoire
et retourne l'adresse de l'emplacement alloué, s'il y a de la place en
mémoire.
ADRESSES ensemble abstrait d'adresses
126
ADRESSES ensemble abstrait d'adresses
memoire : les adresses de la mémoire à allouer
libres : l'ensemble des adresses libres
null : une adresse particulière
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Application à la
modélisation
Solution 1
l’utilisateur n’a pas à tester la précondition. Si l’adresse de retour
est null, cela signifie à l’utilisateur que la mémoire est pleine et que
l’allocation n’a pas été possible :
127
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Application à la
modélisation
Solution 2
Moins d’indéterminisme
128
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Application à la
modélisation
Description des états des utilisateurs d’ordinateurs
Un utilisateur ne peut être en même temps connecte et non
connecte a un ordinateur.
Cependant un utilisateur est connecte ou non connecte.
129
Seules les connectes ont des numéros de compte.
Les connectes n’ont qu’un seul numéro de compte.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Formalisation
Soit les ensembles abstraits UTILISATEUR et NUM
Connecte ⊆ UTILISATEUR
NonConnecte = UTILISATEUR – Connecte
130
NonConnecte = UTILISATEUR – Connecte
aPournumcompte ∈ Connecte --> NUM
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Le contrôle d'accès
aux bâtiments
P1. Le modèle comprend des personnes et des bâtiments
P2. Chaque personne est autorisée à pénétrer dans certains
bâtiments (et pas dans d'autres). Les bâtiments non
consignés dans cette autorisation sont implicitement interdits.
Il s'agit d'une affectation permanente.
P3. A un instant donné, une personne se trouve dans un
131
P3. A un instant donné, une personne se trouve dans un
bâtiment au plus.
D1. Le système gère le passage des personnes d'un bâtiment
à l'autre.
P4. A un instant donné, une personne se trouve dans un
bâtiment au moins.
P5. Toute personne se trouvant dans un bâtiment est bien
autorisée à y être.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Le contrôle d'accès
aux bâtiments
(les personnes et les bâtiments) sont représentés par des
ensembles abstraits,
les autorisations aut d’accès des personnes aux bâtiments
ainsi que les communications com entre les bâtiments sont
représentées par des relations constantes,
132
représentées par des relations constantes,
c’est à dire par des ensembles de couples, dont les types
sont contraints dans la clause INVARIANT.
La situation dynamique sit des personnes dans les bâtiments
est représentée par une fonction totale.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple: Le contrôle d'accès
aux bâtiments
Outre l’information sur les types,
l’invariant affirme qu’à chaque état,
les personnes ne peuvent être que dans les bâtiments où
elles sont autorisées d’entrer
133
com est irreflexive (aucun bâtiment ne communique avec
lui-même).
Le modèle présente une seule opération notée pass qui
représente l’entrée d’une personne
p dans un bâtiment b à condition que p soit autorisée d’entrer
dans b et que b communique avec le bâtiment où se trouve p.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Le contrôle d'accès
aux bâtiments (specification initiale,
abstraite)
134
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.7. Ensembles, fonctions,
relations
MACHINE ASCENSEUR
SETS
ASC ; DIR = {mo, de}
CONSTANT
rdc, haut
PROPERTIES
bas ∈ INT ∧ haut ∈ INT ∧ bas < haut
DEFINITIONS
ETG == bas .. haut ; inactif == ASC - actif ;
135
ETG == bas .. haut ; inactif == ASC - actif ;
VARIABLES
actif, etage, direction, entrees, sorties
INVARIANT
actif ⊆ ASC ∧
etage ∈ ASC —› ETG ∧ dir ∈ ASC —› DIR ∧
entrees ∈ ETG ↔ DIR ∧ sortie ∈ ASC ↔ETG
…
INITIALISATION
actif, entrees, sorties := Φ, Φ, Φ | |
etage, dir := ASC x {bas}, ASC x {mo}
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.8. Tableau
MACHINE TABLEAU (INDEX, VALEUR)
VARIABLES
tab
INVARIANT
tab ∈ INDEX —› VALEUR
i ‹ — chercher (v) =
PRE v ∈ VALEUR ∧
tab -1 [{v}] ≠ Φ
THEN i :∈ tab -1 [{v}]
136
tab ∈ INDEX —› VALEUR
OPERATIONS
changer (v, i) =
PRE
v ∈ VALEUR ∧ i ∈ INDEX
THEN
tab (i) := v
END ;
v ‹ — valeur (i) = … ;
THEN i :∈ tab -1 [{v}]
END ;
b, i ‹ — rechercher (v) =
PRE v ∈ VALEUR
THEN IF tab -1 [{v}] ≠ Φ THEN
b := true || i :∈ tab -1 [{v}]
ELSE b := false || i :∈ INDEX
END
END ;
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.8. Tableau
b ‹ — est_present (v) =
PRE
v ∈ VALEUR
THEN
b := bool (tab -1 [{v}] ≠ Φ)
b, i ‹ — rechercher (v) =
PRE
v ∈ VALEUR
THEN
IF tab -1 [{v}] ≠ Φ
137
b := bool (tab -1 [{v}] ≠ Φ)
END ;
i ‹ — chercher (v) =
PRE
v ∈ VALEUR ∧ tab -1 [{v}] ≠ Φ
THEN
i :∈ tab -1 [{v}]
END ;
IF tab -1 [{v}] ≠ Φ
THEN
b := true
i :∈ tab -1 [{v}]
ELSE
b := false
i :∈ INDEX
END
END ;
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.6.9. Les suites finies (Séquences)
Les sequences
Sequence finie d’elements de E : Toutes les
sequences possibles d’elements de E
Seq(E) : ∪
∪
∪
∪ (n ∈
∈
∈
∈ IN / 1, …, n → E)
138
Seq(E) : ∪
∪
∪
∪n(n ∈
∈
∈
∈ IN / 1, …, n → E)
Seq1(E) = Seq(E) – Φ
[ ] : sequence vide d’ elements de E
[3, 7, 5] : represente la sequence des 3
entiers 3, 7, 5
[ ] = 1, …, 0 → E
[ 3, 7, 5] = [1 ↦ 3, 2 ↦ 7, 3 ↦ 5]
↦ 3, 2 ↦ 7, 3 ↦ 5]
↦ 3, 2 ↦ 7, 3 ↦ 5]
↦ 3, 2 ↦ 7, 3 ↦ 5]
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Opérations sur les sequences
Ajout d’un élément à gauche a → S /
a ∈E et S ∈ Seq(E)
⇒
⇒
⇒
⇒
;
II.6.9. Les suites finies (Séquences)
139
a ∈E et S ∈ Seq(E)
a → [ ] = {1 ↦ a}
↦ a}
↦ a}
↦ a}
S ≠
≠
≠
≠ Φ ⇒
⇒
⇒
⇒ a → S = {1 ↦ a}
↦ a}
↦ a}
↦ a} ∪
∪
∪
∪ {Succ
{Succ
{Succ
{Succ ; S}
[3, 7, 5] = (3 → (7 → (5 → [ ])
;
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Opérations sur les séquences
size : longueur d’une séquence
size ([ ]) = 0 ;
II.6.9. Les suites finies (Séquences)
140
size ([ ]) = 0
Size(a → S) = 1 + size(S)
Concaténation ^
[ ] ^ t = t
a → S ^ t = a
^ t = a
^ t = a
^ t = a → (S ^
^
^
^ t)
;
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Operations sur les séquences
Ajout à droite d’un element : ←
[ ] ← b = b → [ ]
(a → S) ← b = a → (S ← b)
;
II.6.9. Les suites finies (Séquences)
141
rev : inverser la séquence
rev([ ]) = [ ]
rev(a → S) = rev(S) ← a
Size(a → S) = 1 + size(S)
Conc : Concaténation généralisée
Conc ([ ]) = [ ]
Conc (S → u) = S ^
= S ^
= S ^
= S ^ conc (u)
;
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Selection des sous parties d’une séquence donnée
Restriction à partir du bas notée S↑n
↑n
↑n
↑n :
on garde les n premiers éléments de S
Restriction à partir du haut notée S↓n
↓n
↓n
↓n :
:
:
:
;
II.6.9. Les suites finies (Séquences)
142
on supprime les n premiers éléments de S
first(S) = S(1)
last(S) = S(size(S))
tous les éléments sauf le premier:
tail(S) = S↓1
↓1
↓1
↓1
tous les éléments sauf le dernier:
front(S) = S↑(size(S)
↑(size(S)
↑(size(S)
↑(size(S) –
–
–
– 1)
1)
1)
1)
;
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple: Suites finies
MACHINE SUITE (VALEUR, taille_max)
VARIABLES
sui
INVARIANT
sui ∈ seq (VALEUR)
garder_les_premiers (i) =
PRE
i ∈ 0 .. size (sui)
143
sui ∈ seq (VALEUR)
size (sui) ≤ taille_max
OPERATIONS
ajouter_a_la_fin (v) =
PRE
v ∈ VALEUR
size (sui) < taille_max
THEN
sui := sui ← v
END
i ∈ 0 .. size (sui)
THEN
sui := sui . i
END
v ‹ — changer (i, v) @ … ;
enlever_au_debut @ … ;
enlever_a_la_fin @ … ;
l ‹ — longueur @ … ;
b ‹ — est_present (v) @ … ;
i ‹ — chercher (v) @ … ;
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.7. Processus de raffinement
Objectif : Passer de la spécification d’un module à son
implémentation
M1 M2
X y
I J
op1 = op1 =
• Peut-on remplacer M1 par M2 ?
144
• Partout où on utilise M1, M2 doit rendre les mêmes services
• L’ interface externe doit être conservée
En pratique
S substitution utilisant les opérations de M1
T identique à S utilisant les opérations de M2
Un prédicat I, de M1
si S établit I, T doit également établir I pour tout I,
[S]I ⇒
⇒
⇒
⇒ [T]I
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.7. Processus de raffinement
Toute opération spécifiée dans la machine abstraite doit être
raffinée avec la même signature dans l’implantation (ou le
raffinement)
MACHINE IMPLEMENTATION (REFINEMENT)
M iM
145
M iM
IMPLEMENTS (REFINES)
… M
…
OPERATIONS OPERATIONS
y1,..yk opi(x1,..xn)= y1,..yk opi(x1,..xn)=
… …
END END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Une substitution T raffine une substitution S (notée S⊆T) ssi
Les pré conditions sont de plus en plus faibles :
EtatsPre(S) ⊆
⊆
⊆
⊆ EtatsPre(T)
Le déterminisme est de plus en plus grand :
PrePost(T) ⊆
⊆
⊆
⊆ PrePost(S)
où PrePost(X) représente l’ensemble des couples
d’états Pre et Post possibles d’une substitution X
II.7. Processus de raffinement
146
Dans une implémentation, PrePost(X) doit être une
fonction
T raffine S ?
S = x>5 | (x:=0 [] x:=x-1)
T = x>0 | x:=x-1
T remplit les mêmes services que S en tout point d’exécution
prévu par S
EtatsPre(S)={6,7,8…} ⊆
⊆
⊆
⊆ EtatsPre(T)={1,2,3…}
PrePost(T)={(x,x’)∈ZxZ|x’=x-1} ⊆
⊆
⊆
⊆
PrePost(S)=Zx{0}∪{(x,x’)∈ZxZ|x’=x-1}
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
MACHINE EX 1
VARIABLES
y
INVARIANT
y ∈ F(NAT1)
INITIALISATION
y := Φ
OPERATIONS
II.7. Processus de raffinement
(Exemple)
REFINEMENT EX 2
REFINES EX 1
VARIABLES
z
INVARIANT
z = max (y ∪
∪
∪
∪ {0})
INITIALISATION
z := 0
147
OPERATIONS
entrer (n) =
PRE n ∈ NAT1
THEN
y := y ∪ {n}
END ;
m ‹ — maxi =
PRE y ≠ Φ
THEN
m := max (y)
END ;
END
z := 0
OPERATIONS
entrer (n) =
PRE n ∈ NAT1
THEN
z := max ({z, n})
END ;
m ‹ — maxi =
PRE z ≠ 0
THEN
m := z
END ;
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
À chaque raffinement, on précise, on
fait des choix:
réduction de l’indéterminisme
II.7. Processus de raffinement
148
réduction de l’indéterminisme
affaiblissement des préconditions
changement de variables
explicitation des algorithmes
Le dernier raffinement est une implémentation
pouvant utiliser des composants logiciels existants
(ou développés indépendamment).
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.7.1. Réduction de l’indéterminisme
Soit
S = (x := 0) [] (x := x - 1)
T = x := x - 1
⇔
149
T = x := x - 1
On a
[S]I ⇔ [x := 0]I ∧ [x := x - 1]I
[T]I ⇔ [x := x - 1]I
Donc
[S]I ⇒ [T]I.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.7.2. Affaiblissement des pré
conditions
Soit
S = PRE x > 5 THEN x := x - 1
T = PRE x > 0 THEN x := x - 1
⇔
150
T = PRE x > 0 THEN x := x - 1
On a
[S]I ⇔ x > 5 ∧ [x := x - 1]I
[T]I ⇔ x > 0 ∧ [x := x - 1]I
Donc
[S]I ⇒ [T]I
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.7.3. Changement de Variables
VARIABLES
y
VARIABLES
sui
INVARIANT
sui ∈ seq (VALEUR)
151
INVARIANT
y ∈ F(NAT1)
VARIABLES
z
INVARIANT
z = max (y ∪ {0})
sui ∈ seq (VALEUR)
size (sui) ≤ taille_max
VARIABLES
tab, vrb
INVARIANT
vrb ∈(0 .. taille_max) ∧
tab ∈ 1 .. taille_max —› VA-LEUR
∧ sui = (1 .. vrb) <| tab
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.7.4. Expliciter des algorithmes
d ‹ — empiler(w) =
PRE w ∈ VALEUR
THEN
d ‹ — empiler(w) =
PRE w ∈ VALEUR
THEN
152
THEN
CHOICE
d := ok | |
sui := sui ← w
OR
d := ko
END ;
THEN
IF vrb < taille_max THEN
d := ok | |
vrb := vrb + 1 | |
tab (vrb + 1) := w
ELSE
d := ko
END ;
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple
MACHINE EX 1
VARIABLES
y
INVARIANT
y ∈ F(NAT1)
INITIALISATION
y := Φ
OPERATIONS
REFINEMENT EX 2
REFINES EX 1
VARIABLES
z
INVARIANT
z = max (y ∪ {0})
INITIALISATION
z := 0
OPERATIONS
entrer (n) =
153
OPERATIONS
entrer (n) =
PRE n ∈ NAT1 (P)
THEN
y := y ∪
∪
∪
∪ {n}
(S)
END ;
m ‹ — maxi
PRE y ≠ Φ
THEN
m := max (y)
END ;
END
entrer (n) =
PRE n ∈ NAT1 (Q)
THEN
z := max ({z, n}) (T)
END ;
m ‹ — maxi =
PRE z ≠ 0
THEN
m := z
END ;
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.7.5. L’invariant de collage
Il assure la liaison entre les variables
abstraites et les variables (plus)
concrètes
154
concrètes
Il définit la transformation qui permet
d’associer à tout état ER de la
machine raffinée un état EA de la
machine abstraite
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.8. Les obligations de preuve
du raffinement
MACHINE Ma
…
INVARIANT
MACHINE Mr
…
INVARIANT
J
155
INVARIANT
I
INITIALISATION
B
OPERATIONS
P|S
J
INITIALISATION
C
OPERATIONS
Q|T
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.8.1. Les obligations de preuve
du raffinement (Initialisation)
L’initialisation de Mr doit établir qu’il est impossible
que l’initialisation de Ma établisse la négation du
changement de variable
[C] ¬
¬
¬
¬ [B] ¬
¬
¬
¬ J
156
[C] ¬
¬
¬
¬ [B] ¬
¬
¬
¬ J
1. [z := 0] ¬ [ y := Φ] ¬ (z = max (y ∪ {0}))
2. [z := 0] (z = max (Φ ∪ {0}))
3. 0 = 0
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.8.2. Obligations de preuve de
raffinement d’une opération
Si : les valeurs des variables des deux composants (abstrait et
raffiné) avant l’opération respectent les invariants I et J
Et si : on est dans les conditions P d’exécution de l’opération
abstraite
Alors :
157
Alors :
On doit être dans les conditions Q d’exécution de l’opération
raffinée
Quelque soit les nouvelles valeurs prises par les variables parmi
celles définies par la substitution T de la machine raffinée, elles
doivent correspondre par la transformation J à l’une des valeurs
définies par la substitution S de la machine abstraite
I ∧
∧
∧
∧J∧
∧
∧
∧P => Q∧
∧
∧
∧[T]¬
¬
¬
¬[S]¬
¬
¬
¬J
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.8.3. Obligations de preuve de
raffinement d’une opération
Invariant de la spécification
Invariant du raffinement
Pré-condition de la spécification
⇒
⇒
⇒
⇒
158
⇒
⇒
⇒
⇒
Pré-condition du raffinement
[Action du raffinement]
[Action de la spécification]
Changement de variable du raffinement
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Obligation de preuve de
raffinement de entrer(n)
1. y ∈
∈
∈
∈ F(NAT1) ∧
∧
∧
∧ z = max (y ∪
∪
∪
∪ {0}) ∧
∧
∧
∧ n ∈
∈
∈
∈ NAT1
⇒
⇒
⇒
⇒
n ∈
∈
∈
∈ NAT1 ∧
∧
∧
∧ [z := max ({z, n})] ¬
¬
¬
¬ [y := y ∪
∪
∪
∪ {n}]
¬
¬
¬
¬ (z = max (y ∪
∪
∪
∪ {0}))
⇒
⇒
⇒
⇒
159
2. y ∈
∈
∈
∈ F(NAT1) ∧
∧
∧
∧ z = max (y ∪
∪
∪
∪ {0}) ∧
∧
∧
∧ n ∈
∈
∈
∈ NAT1
⇒
⇒
⇒
⇒
n ∈
∈
∈
∈ NAT1 ∧
∧
∧
∧ [z := max ({z, n})] (z = max (y ∪
∪
∪
∪ {n} ∪
∪
∪
∪ {0}))
3. y ∈
∈
∈
∈ F(NAT1) ∧
∧
∧
∧ z = max (y ∪
∪
∪
∪ {0}) ∧
∧
∧
∧ n ∈
∈
∈
∈ NAT1
⇒
⇒
⇒
⇒
n ∈
∈
∈
∈ NAT1 ∧
∧
∧
∧ (max ({z, n}) = max (y ∪
∪
∪
∪ {n} ∪
∪
∪
∪ {0})).
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Obligation de preuve de
raffinement de m←maxi
I ∧
∧
∧
∧ J ∧
∧
∧
∧ P
Q ∧
∧
∧
∧ [[m := m']T] ¬
¬
¬
¬ [S] ¬
¬
¬
¬ (J ∧
∧
∧
∧ m = m')
1. y ∈
∈
∈
∈ F(NAT1) ∧
∧
∧
∧ z = max (y ∪
∪
∪
∪ {0}) ∧
∧
∧
∧ y ≠
≠
≠
≠ Φ
⇒
⇒
⇒
⇒
160
⇒
⇒
⇒
⇒
z ≠
≠
≠
≠ 0 ∧
∧
∧
∧ [m' := z] ¬
¬
¬
¬ [m := max (y)] ¬
¬
¬
¬ (z = max (y ∪
∪
∪
∪ {0}) ∧
∧
∧
∧ m =m')
2. y ∈
∈
∈
∈ F(NAT1) ∧
∧
∧
∧ z = max (y ∪
∪
∪
∪ {0}) ∧
∧
∧
∧ y ≠
≠
≠
≠ Φ
⇒
⇒
⇒
⇒
z ≠
≠
≠
≠ 0 ∧
∧
∧
∧ [m' := z] (z = max (y ∪
∪
∪
∪ {0}) ∧
∧
∧
∧ max (y) = m')
3. y ∈
∈
∈
∈ F(NAT1) ∧
∧
∧
∧ z = max (y ∪
∪
∪
∪ {0}) ∧
∧
∧
∧ y ≠
≠
≠
≠ Φ
⇒
⇒
⇒
⇒
z ≠
≠
≠
≠ 0 ∧
∧
∧
∧ (z = max (y ∪
∪
∪
∪ {0}) ∧
∧
∧
∧ max (y) = z)
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Implémentation
Pas de variables en propre (on importe des
machines)
Les opérations sont précises et exécutables
séquence, locale, conditionnelle, cas, tant que, appel,
161
séquence, locale, conditionnelle, cas, tant que, appel,
affectations limitées
Les variables sont importées
Les valeurs données aux constantes sont
implémentables.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Exemple : Implémentation
Exemple
MACHINE Mem (init)
CONSTRAINT init ∈
∈
∈
∈ NAT
VARIABLE v ∈
∈
∈
∈ NAT
INITIALISATION v := init
IMPLEMENTATION EX 3
REFINES EX 2
IMPORT Mem (0)
INVARIANT
z = v
162
INITIALISATION v := init
OPERATIONS
aff (n) = PRE n ∈
∈
∈
∈ NAT
THEN v := n END ;
r ‹ — lire =
BEGIN r := v END ;
END
z = v
OPERATIONS
entrer (n) = Var i ∈
∈
∈
∈ IN
i ‹ — lire ; IF n ≥
≥
≥
≥ i
THEN aff (n) END
END
m ‹ — maxi =
BEGIN m ‹ — lire END
END
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.9. La modularité dans les
spécifications B
Dans la conception de logiciels de taille importante, la
décomposition en plusieurs machines s'impose afin de
faciliter la modularité.
SEES,
USES,
163
USES,
INCLUDES,
EXTENDS,
IMPORTS,
REFINES.
Ces mécanismes autorisent un développement
progressif de la spécification et la séparation des
preuves pour chaque machine.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.9. La modularité dans les
spécifications B
Deux nouvelles clauses peuvent apparaître dans une implantation :
-la clause IMPORTS qui crée des instances concrètes de machines
abstraites dans un projet. Les opérations de ces machines importées sont
164
abstraites dans un projet. Les opérations de ces machines importées sont
appelées dans les opérations de l’implantation.
-la clause VALUES qui permet de donner une valeur aux ensembles
abstraits et aux constantes concrètes de l’implantation.
- La clause EXTENDS, correspond à la clause IMPORTS dans une
implantation alors qu’elle correspond à la clause INCLUDES dans une
machine abstraite ou un raffinement.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.9. La modularité dans les
spécifications B
Les clauses INCLUDES et IMPORTS servent à partager les
fonctionnalités (les opérations) et les données définies dans un autre
module B
.
Ce sont des clauses de liaison dont l'usage est proche de celui fait des
165
Ce sont des clauses de liaison dont l'usage est proche de celui fait des
constructions de modularité usuelles des langages de programmation.
Leur objectif est de permettre la décomposition d'un problème en se
servant des fonctionnalités développées pour des sous problèmes.
•les variables concrètes sont visibles;
•les variables abstraites ne sont visibles que dans les invariants et
•les opérations sont visibles.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
II.9. La modularité dans les
spécifications B
Les liens SEES et USES sont des liens transversaux dans l'arborescence des
dépendances d'un projet B. Ils ne sont utilisés que pour consulter les informations
des autres composants. Les liens SEES et USES étant des <<courts-circuits>>
dans l'arborescence des dépendances, il est nécessaire que les composants
soient attachés à cette arborescence par l'utilisation soit du INCLUDES soit du
IMPORTS.
166
IMPORTS.
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
Arrêt
En Marche
Sélection
Monnaie
Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes -
2014
167
Sélection
Distribution
Trop Perçu

Contenu connexe

Tendances

Uml 2 pratique de la modélisation
Uml 2  pratique de la modélisationUml 2  pratique de la modélisation
Uml 2 pratique de la modélisation
Nassim Amine
 
logique combinatoire
logique combinatoire logique combinatoire
logique combinatoire
morin moli
 
Chapitre v algorithmes gloutons
Chapitre v algorithmes gloutonsChapitre v algorithmes gloutons
Chapitre v algorithmes gloutonsSana Aroussi
 
Cours systèmes temps réel partie 1 Prof. Khalifa MANSOURI
Cours  systèmes temps réel partie 1 Prof. Khalifa MANSOURICours  systèmes temps réel partie 1 Prof. Khalifa MANSOURI
Cours systèmes temps réel partie 1 Prof. Khalifa MANSOURI
Mansouri Khalifa
 
Uml: Diagrammes de classes -- Concepts avances --- 27
Uml: Diagrammes de classes -- Concepts avances --- 27Uml: Diagrammes de classes -- Concepts avances --- 27
Uml: Diagrammes de classes -- Concepts avances --- 27
megaplanet20
 
Chapitre 01 - Notions de base
Chapitre 01 - Notions de baseChapitre 01 - Notions de base
Chapitre 01 - Notions de base
L’Université Hassan 1er Settat
 
Algorithme & structures de données Chap I
Algorithme & structures de données Chap IAlgorithme & structures de données Chap I
Algorithme & structures de données Chap I
Ines Ouaz
 
Problème De Sac à Dos
Problème De Sac à Dos Problème De Sac à Dos
Problème De Sac à Dos
chagra bassem
 
Exercices vhdl
Exercices vhdlExercices vhdl
Exercices vhdlyassinesmz
 
Exposé langage-b
Exposé langage-bExposé langage-b
Exposé langage-b
Donia Hammami
 
Chp5 - Les outils CASE
Chp5 - Les outils CASEChp5 - Les outils CASE
Chp5 - Les outils CASE
Lilia Sfaxi
 
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
Soufiane KALLIDA
 
TP C++ : Correction
TP C++ : CorrectionTP C++ : Correction
Chap5 diagramme d'etats-transitions
Chap5 diagramme d'etats-transitionsChap5 diagramme d'etats-transitions
Chap5 diagramme d'etats-transitions
Amir Souissi
 
Systeme embarque td1
Systeme embarque td1Systeme embarque td1
Systeme embarque td1
SinGuy
 
Cours de programmation en c
Cours de programmation en cCours de programmation en c
Cours de programmation en c
benouini rachid
 
Cours.langage c
Cours.langage cCours.langage c
Cours.langage c
Yasmine Long
 
Diagramme de classe
Diagramme de classeDiagramme de classe
Diagramme de classeIlhem Daoudi
 
Complexité_ENSI_2011.ppt
Complexité_ENSI_2011.pptComplexité_ENSI_2011.ppt
Complexité_ENSI_2011.ppt
MbarkiIsraa
 

Tendances (20)

Uml 2 pratique de la modélisation
Uml 2  pratique de la modélisationUml 2  pratique de la modélisation
Uml 2 pratique de la modélisation
 
logique combinatoire
logique combinatoire logique combinatoire
logique combinatoire
 
Chapitre v algorithmes gloutons
Chapitre v algorithmes gloutonsChapitre v algorithmes gloutons
Chapitre v algorithmes gloutons
 
Cours systèmes temps réel partie 1 Prof. Khalifa MANSOURI
Cours  systèmes temps réel partie 1 Prof. Khalifa MANSOURICours  systèmes temps réel partie 1 Prof. Khalifa MANSOURI
Cours systèmes temps réel partie 1 Prof. Khalifa MANSOURI
 
Uml: Diagrammes de classes -- Concepts avances --- 27
Uml: Diagrammes de classes -- Concepts avances --- 27Uml: Diagrammes de classes -- Concepts avances --- 27
Uml: Diagrammes de classes -- Concepts avances --- 27
 
Chapitre 01 - Notions de base
Chapitre 01 - Notions de baseChapitre 01 - Notions de base
Chapitre 01 - Notions de base
 
Algorithme & structures de données Chap I
Algorithme & structures de données Chap IAlgorithme & structures de données Chap I
Algorithme & structures de données Chap I
 
Problème De Sac à Dos
Problème De Sac à Dos Problème De Sac à Dos
Problème De Sac à Dos
 
Exercices vhdl
Exercices vhdlExercices vhdl
Exercices vhdl
 
Exposé langage-b
Exposé langage-bExposé langage-b
Exposé langage-b
 
Chp5 - Les outils CASE
Chp5 - Les outils CASEChp5 - Les outils CASE
Chp5 - Les outils CASE
 
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
 
TP C++ : Correction
TP C++ : CorrectionTP C++ : Correction
TP C++ : Correction
 
Chap5 diagramme d'etats-transitions
Chap5 diagramme d'etats-transitionsChap5 diagramme d'etats-transitions
Chap5 diagramme d'etats-transitions
 
Systeme embarque td1
Systeme embarque td1Systeme embarque td1
Systeme embarque td1
 
UML Diagrammes Statiques
UML Diagrammes StatiquesUML Diagrammes Statiques
UML Diagrammes Statiques
 
Cours de programmation en c
Cours de programmation en cCours de programmation en c
Cours de programmation en c
 
Cours.langage c
Cours.langage cCours.langage c
Cours.langage c
 
Diagramme de classe
Diagramme de classeDiagramme de classe
Diagramme de classe
 
Complexité_ENSI_2011.ppt
Complexité_ENSI_2011.pptComplexité_ENSI_2011.ppt
Complexité_ENSI_2011.ppt
 

Similaire à (GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf

Ihm introduction
Ihm introductionIhm introduction
Ihm introduction
sloumaallagui1
 
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logicielsAccélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
kalistick
 
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptxProcessus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
informatiquehageryah
 
Wygday2010 - Supervision applicative avec System Center Operations Manager
Wygday2010 - Supervision applicative avec System Center Operations ManagerWygday2010 - Supervision applicative avec System Center Operations Manager
Wygday2010 - Supervision applicative avec System Center Operations Manager
Wygwam
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
Erradi Mohamed
 
qualité logicielle (8).pdf
qualité logicielle (8).pdfqualité logicielle (8).pdf
qualité logicielle (8).pdf
NoamHaythem
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
LatifaBen6
 
1327415.ppt
1327415.ppt1327415.ppt
1327415.ppt
ernestmuhasa
 
Test unitaires
Test unitairesTest unitaires
Test unitaires
Mohamed Akrouh
 
Guide tests fonctionnels
Guide tests fonctionnelsGuide tests fonctionnels
Guide tests fonctionnels
cvcby
 
Application lifecycle management
Application lifecycle managementApplication lifecycle management
Application lifecycle management
Klee Group
 
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline SimonMémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
Emeline Simon
 
Gl slides-cours-1
Gl slides-cours-1Gl slides-cours-1
Gl slides-cours-1Sami Neili
 
Quality assurancecourseoutline rymtlijanibahrini
Quality assurancecourseoutline rymtlijanibahriniQuality assurancecourseoutline rymtlijanibahrini
Quality assurancecourseoutline rymtlijanibahrini
SESAME
 
20120124 05 - Le Model-based Testing aujourd'hui (Inria)
20120124 05 - Le Model-based Testing aujourd'hui (Inria)20120124 05 - Le Model-based Testing aujourd'hui (Inria)
20120124 05 - Le Model-based Testing aujourd'hui (Inria)
LeClubQualiteLogicielle
 
Exposé qualité et test
Exposé qualité et test Exposé qualité et test
Exposé qualité et test Imen Turki
 
les metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitéles metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualité
soregh
 
Avis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsAvis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests Logiciels
CloudNetCare
 
formation istqb.pdf
formation istqb.pdfformation istqb.pdf
formation istqb.pdf
mido04
 

Similaire à (GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf (20)

Ihm introduction
Ihm introductionIhm introduction
Ihm introduction
 
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logicielsAccélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
 
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptxProcessus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
 
Lecon 1.1
Lecon 1.1Lecon 1.1
Lecon 1.1
 
Wygday2010 - Supervision applicative avec System Center Operations Manager
Wygday2010 - Supervision applicative avec System Center Operations ManagerWygday2010 - Supervision applicative avec System Center Operations Manager
Wygday2010 - Supervision applicative avec System Center Operations Manager
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
qualité logicielle (8).pdf
qualité logicielle (8).pdfqualité logicielle (8).pdf
qualité logicielle (8).pdf
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
 
1327415.ppt
1327415.ppt1327415.ppt
1327415.ppt
 
Test unitaires
Test unitairesTest unitaires
Test unitaires
 
Guide tests fonctionnels
Guide tests fonctionnelsGuide tests fonctionnels
Guide tests fonctionnels
 
Application lifecycle management
Application lifecycle managementApplication lifecycle management
Application lifecycle management
 
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline SimonMémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
 
Gl slides-cours-1
Gl slides-cours-1Gl slides-cours-1
Gl slides-cours-1
 
Quality assurancecourseoutline rymtlijanibahrini
Quality assurancecourseoutline rymtlijanibahriniQuality assurancecourseoutline rymtlijanibahrini
Quality assurancecourseoutline rymtlijanibahrini
 
20120124 05 - Le Model-based Testing aujourd'hui (Inria)
20120124 05 - Le Model-based Testing aujourd'hui (Inria)20120124 05 - Le Model-based Testing aujourd'hui (Inria)
20120124 05 - Le Model-based Testing aujourd'hui (Inria)
 
Exposé qualité et test
Exposé qualité et test Exposé qualité et test
Exposé qualité et test
 
les metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitéles metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualité
 
Avis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsAvis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests Logiciels
 
formation istqb.pdf
formation istqb.pdfformation istqb.pdf
formation istqb.pdf
 

Plus de MbarkiIsraa

NP-complet.ppt
NP-complet.pptNP-complet.ppt
NP-complet.ppt
MbarkiIsraa
 
Format.pptx
Format.pptxFormat.pptx
Format.pptx
MbarkiIsraa
 
correctionTD2JAVA.pdf
correctionTD2JAVA.pdfcorrectionTD2JAVA.pdf
correctionTD2JAVA.pdf
MbarkiIsraa
 
correctionTD-1-vhdl2947.pptx
correctionTD-1-vhdl2947.pptxcorrectionTD-1-vhdl2947.pptx
correctionTD-1-vhdl2947.pptx
MbarkiIsraa
 
PCD YasBas.pptx
PCD YasBas.pptxPCD YasBas.pptx
PCD YasBas.pptx
MbarkiIsraa
 
PLNE.pptx
PLNE.pptxPLNE.pptx
PLNE.pptx
MbarkiIsraa
 
support_cours.pdf
support_cours.pdfsupport_cours.pdf
support_cours.pdf
MbarkiIsraa
 
c h02EspaceProbTr.pdf
c h02EspaceProbTr.pdfc h02EspaceProbTr.pdf
c h02EspaceProbTr.pdf
MbarkiIsraa
 
Ordonnanc-Proc_Threads (1).pdf
Ordonnanc-Proc_Threads (1).pdfOrdonnanc-Proc_Threads (1).pdf
Ordonnanc-Proc_Threads (1).pdf
MbarkiIsraa
 
prog_reg.pptx
prog_reg.pptxprog_reg.pptx
prog_reg.pptx
MbarkiIsraa
 
correctionTD-2-vhdl2949.pptx
correctionTD-2-vhdl2949.pptxcorrectionTD-2-vhdl2949.pptx
correctionTD-2-vhdl2949.pptx
MbarkiIsraa
 
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdf
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdfChapitre 3 _Conception et analyse d’algorithme-DPR.pdf
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdf
MbarkiIsraa
 
Chapitre 2 -Complexité des problèmes avec correction.pdf
Chapitre 2 -Complexité des problèmes avec correction.pdfChapitre 2 -Complexité des problèmes avec correction.pdf
Chapitre 2 -Complexité des problèmes avec correction.pdf
MbarkiIsraa
 
DiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdf
DiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdfDiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdf
DiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdf
MbarkiIsraa
 
Correction-TD1.pdf
Correction-TD1.pdfCorrection-TD1.pdf
Correction-TD1.pdf
MbarkiIsraa
 
UML.Objet.4pp.pdf
UML.Objet.4pp.pdfUML.Objet.4pp.pdf
UML.Objet.4pp.pdf
MbarkiIsraa
 

Plus de MbarkiIsraa (16)

NP-complet.ppt
NP-complet.pptNP-complet.ppt
NP-complet.ppt
 
Format.pptx
Format.pptxFormat.pptx
Format.pptx
 
correctionTD2JAVA.pdf
correctionTD2JAVA.pdfcorrectionTD2JAVA.pdf
correctionTD2JAVA.pdf
 
correctionTD-1-vhdl2947.pptx
correctionTD-1-vhdl2947.pptxcorrectionTD-1-vhdl2947.pptx
correctionTD-1-vhdl2947.pptx
 
PCD YasBas.pptx
PCD YasBas.pptxPCD YasBas.pptx
PCD YasBas.pptx
 
PLNE.pptx
PLNE.pptxPLNE.pptx
PLNE.pptx
 
support_cours.pdf
support_cours.pdfsupport_cours.pdf
support_cours.pdf
 
c h02EspaceProbTr.pdf
c h02EspaceProbTr.pdfc h02EspaceProbTr.pdf
c h02EspaceProbTr.pdf
 
Ordonnanc-Proc_Threads (1).pdf
Ordonnanc-Proc_Threads (1).pdfOrdonnanc-Proc_Threads (1).pdf
Ordonnanc-Proc_Threads (1).pdf
 
prog_reg.pptx
prog_reg.pptxprog_reg.pptx
prog_reg.pptx
 
correctionTD-2-vhdl2949.pptx
correctionTD-2-vhdl2949.pptxcorrectionTD-2-vhdl2949.pptx
correctionTD-2-vhdl2949.pptx
 
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdf
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdfChapitre 3 _Conception et analyse d’algorithme-DPR.pdf
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdf
 
Chapitre 2 -Complexité des problèmes avec correction.pdf
Chapitre 2 -Complexité des problèmes avec correction.pdfChapitre 2 -Complexité des problèmes avec correction.pdf
Chapitre 2 -Complexité des problèmes avec correction.pdf
 
DiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdf
DiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdfDiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdf
DiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdf
 
Correction-TD1.pdf
Correction-TD1.pdfCorrection-TD1.pdf
Correction-TD1.pdf
 
UML.Objet.4pp.pdf
UML.Objet.4pp.pdfUML.Objet.4pp.pdf
UML.Objet.4pp.pdf
 

(GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf

  • 1. Génie Logiciel II- Spécification et Vérification de Systèmes Leila Jemni Ben Ayed Ecole Nationale des Sciences de l’Informatique L’objectif de ce cours est d’introduire la spécification et la 1 L’objectif de ce cours est d’introduire la spécification et la vérification formelle dans la démarche de développement d’un système informatique (Raffinement, Abstraction, modularité, preuve, vérification, formel) Références. - David Harel, Michal Politi, Modeling reactive systems with statecharts the statemateapproach, McGraw-Hill, 1998, - Kevin Lano, The B language and method: a guide to practical formal development, Springer, 1996, - Zohar Manna, Amir Pnueili, The Temporal Logic of Reactive and Concurrent Systems: Specification, Springer, 1992. - Philippe Schnoebelen, Vérification de logiciels Techniques et outils du model-checking, Vuibert, 1999. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 2. Plan I. Spécification et vérification formelle de logiciels II. La méthode B AMN (Abstract macine notation) III. La méthode B événementiel IV. Vérification de modèles (ou model checking) 2 IV. Vérification de modèles (ou model checking) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 3. I. Spécification et vérification formelle de logiciels Plan I.1.Systèmes automatisés sûrs de fonctionnement I.2. Nécessité des méthodes formelles dans le cycle de 3 I.2. Nécessité des méthodes formelles dans le cycle de développement d’un logiciel I.3.Spécification formelle, vérification et validation I.4.Comportement, environnement, propriétés I.5.Formalismes pour représenter des spécifications I.6.Vérification (par preuve de théorèmes et par vérification de modèles) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 4. P Propriétés de sûreté Système Physique + Environnement Système Informatique de commandes Commandes I.1. Systèmes automatisés sûrs de fonctionnement 4 Ces systèmes sont complexes et exigent un niveau de sûreté et de fiabilité élevé Propriétés de vivacité Environnement de commandes Informations sur l’état du système physique Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 5. Les système présente différentes vues · Vue fonction : Que doit faire le système dans son environnement ? Quels sont sa finalité, sa mission et ses objectifs ? · Vue structure : De quoi le système est-il fait? Avec quelles ressources, quelles configurations et quelle organisation le système fonctionne-t-il ? Comment est-il structuré dans son I.1. Systèmes automatisés sûrs de fonctionnement 5 système fonctionne-t-il ? Comment est-il structuré dans son activité pour remplir sa mission ? · Vue comportement : Quelle est la dynamique du système ? Comment le système évolue-t-il ? Comment passe-t-il d’un type de fonctionnement à un autre ? Quels sont les différents scénarios possibles de son évolution ? Quelles sont les conditions et configurations des ressources du système permettant de passer d’un scénario au suivant ? Comment est-il piloté à la fois pour atteindre ses objectifs de performance, et pour faire face à un changement pour s’adapter, s’améliorer, faire face à des incidents, etc. ? Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 6. La Vérification cherche d’abord à répondre à la question « Construisons-nous correctement le modèle ? ». Le but est de prouver la cohérence du modèle, de s’assurer de la bonne utilisation des moyens de modélisation et de rendre compte de I.1. Systèmes automatisés sûrs de fonctionnement 6 utilisation des moyens de modélisation et de rendre compte de la description des exigences. Par définition, la vérification est "la confirmation de preuves que les exigences spécifiées ont été satisfaites" (ISO 8402). Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 7. La Validation cherche à répondre à la question « Construisons-nous le bon modèle ? ». Il s’agit ici de s’assurer de la pertinence du modèle, voire si possible d’une certaine forme de complétude au regard du système modélisé, de ses situations et de ses scénarios d’évolution. La validation se définit comme la "confirmation que les exigences particulières pour un usage spécifique prévu sont satisfaites. I.1. Systèmes automatisés sûrs de fonctionnement 7 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). Ainsi, la validation permet de lier le modèle à la réalité attendue ou perçue. Enfin, il est parfois intéressant de qualifier voire de certifier un modèle donné. Le but est alors de pouvoir réutiliser ce modèle en interne comme un modèle de référence de type métier partageable avec d’autres acteurs ou de prouver sa compliance avec un standard du marché. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 8. · Des techniques non formelles : elles consistent à détecter des erreurs ou ce qui semble l’être en examinant et expertisant le modèle de manière manuelle au cours d’expertises, de revues de modèles, de test, etc. Ce sont donc plutôt des techniques de validation. · Des techniques semi formelles : il s’agit de techniques dont le niveau de résultat peut être considéré comme I.1. Systèmes automatisés sûrs de fonctionnement 8 dont le niveau de résultat peut être considéré comme indépendant d’une expertise humaine mais sans pour autant revêtir un caractère exhaustif et indiscutable. D’un point de vue statique, il peut s’agir de vérifier la conformité du modèle à un standard existant. D’un point de vue dynamique, les techniques usuelles sont la simulation, l’émulation ou le test. Elles ont pour inconvénient la non exhaustivité des cas envisagés et donc l’impossibilité de garantir l’absence de fautes. Par exemple, il est en général impossible de tester un système avec tous les vecteurs d'entrées théoriquement valables sans risquer une explosion combinatoire de ces vecteurs. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 9. De même, on ne peut simuler tous les chemins d'exécution d’un modèle et seule une partie (critique) de ses comportements possibles est examinée. · Des techniques formelles : ce sont des techniques basées sur l’emploi de méthodes formelles. Elles reposent sur l’utilisation de langages et de concepts relevant du domaine I.1. Systèmes automatisés sûrs de fonctionnement 9 sur l’utilisation de langages et de concepts relevant du domaine des mathématiques. Par définition, un langage formel est en effet un langage doté d’une sémantique mathématique adéquate basée sur des règles d’interprétation qui garantissent l’absence d’ambiguïté dans les descriptions produites et des règles de déduction qui permettent de raisonner sur les spécifications afin de découvrir de potentielles incomplétudes, inconsistances ou pour prouver des propriétés. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 10. 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 I.1. Systèmes automatisés sûrs de fonctionnement 10 Spécification Exigences de l’utilisateur : propriétés attendues et la vérification de systèmes Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 11. I.1. Systèmes automatisés sûrs de fonctionnement Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014 11 Automate logiques temporelles Automates temporisés logiques temporisées Formules |-- Preuve de théorèmes Formules Logiques logiques
  • 12. Réduire la complexité et assurer un bon fonctionnement, L’utilisation des méthodes formelles apparaît comme une solution principale Introduire une phase de spécification formelle Le système est ainsi spécifié et vérifié avant I.2. Nécessité des méthodes formelles dans le Cycle de développement d’un logiciel 12 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 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 13. Validation Spécification des besoins du système Spécification formelle I.2. Nécessité des méthodes formelles dans le Cycle de développement d’un logiciel Identification des composants (modules) utiles Définition du rôle de chaque module Exigences (Propriétés attendues) Vérification 13 Tests Implémentation Conception Choix des structures de données et d’algorithmes Implémentation Vérification du respect des spécifications Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 14. I.3. Spécification formelle, validation et vérification Spécification permet de comprendre ce que doit faire chaque composant 14 composant argumenter sur la cohérence du composant énoncer des propriétés sur le système avant même son développement Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 15. Les méthodes formelles pour la spécification: consistent à intégrer une étape de vérification formelle dans les démarches de conception de logiciels. reposent sur : I.3. Spécification formelle, validation et vérification 15 reposent sur : 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. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 16. I.3. Spécification formelle, validation et vérification Une méthode formelle Se base sur des notations mathématiques Permet au spécifieur de décrire rigoureusement, sans ambiguïté ce que doit réaliser son programme 16 ambiguïté ce que doit réaliser son programme se base sur une axiomatique qui induit la preuve Elle permet 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) A la phase de conception on s’intéresse aux problèmes d’optimisation Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 17. La validation permet de Vérifier si le texte formel traduit bien la demande informelle faite par celui qui commande le logiciel I.3. Spécification formelle, validation et vérification 17 commande le logiciel La validation ne peut pas être automatisée La spécification permet de s’assurer de l’adéquation des composants au cahier des charges Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 18. Une spécification est une référence pour la suite du développement Permet au programmeur de : I.3. Spécification formelle, validation et vérification 18 Permet au programmeur de : Décider les langages, bibliothèques… Décider la complexité Décider la généricité Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 19. Définir le quoi pas le comment Nom Données en entrée I.3. Spécification formelle, validation et vérification 19 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 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 20. Une spécification permet à chaque étape du développement de vérifier que la réalisation du système respecte les exigences En conception : I.3. Spécification formelle, validation et vérification 20 En conception : Vérifier si l’algorithme calcule ce qui a été spécifie En intégration : Vérifier si le programme réalise le composant initialement spécifie Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 21. I.3. Spécification formelle, validation et vérification 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 21 passe de la spécification à du pseudo-code Codage: puis on génère automatiquement du code exécutable Preuve: On prouve à chaque étape le respect des spécifications initiales Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 22. 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 I.3. Spécification formelle, validation et vérification 22 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 le système. ⇒ ⇒ ⇒ ⇒ La vérification formelle doit être complétée par de la validation à partir de jeux de tests. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 23. Comment ? Les voies pour sortir de ces problèmes sont très 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 I.3. Spécification formelle, validation et vérification 23 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. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 24. Types de propriétés Sûreté (Safety) Invariants Quelque chose de mauvais n’arrivera jamais I.4. Comportement, environnement, propriétés 24 Quelque chose de mauvais n’arrivera jamais pas d’accès simultané de A et B à la section critique Vivacité (Liveness) Quelque chose souhaité finira par avoir lieu si A veut entrer à la section, alors inévitablement il aura cet accès Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 25. Fatalité sous certaines conditions quelque chose de bien finira par avoir lieu au moins une fois à partir d’un certain état". Dans une logique temporelle I.4. Comportement, environnement, propriétés 25 elle s’exprime sous la forme de: F → → → → ◊ ◊ ◊ ◊ G    (F → → → → ◊ ◊ ◊ ◊ G) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 26. Atteignabilité Ces propriétés énoncent qu’une certaine situation peut être atteinte. I.4. Comportement, environnement, propriétés 26 peut être atteinte. Nous pouvons exprimer aussi que quelque chose n’est jamais atteignable et nous parlons alors d’inatteignabilité. Dans ce cas, on se situe dans la classe des propriétés de sûreté. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 27. Equité énonce que, sous certaines conditions, quelque chose aura lieu un nombre infini de fois. Equité faible I.4. Comportement, environnement, propriétés 27 Equité faible exprime que si une transition est continuellement activable alors elle est infiniment souvent activée. Equité forte exprime que si une transition est infiniment souvent activable alors elle sera infiniment souvent activée. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 28. 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 : 28 Hors service (hs) : tous les feux sont au jaune En service (es) : ils évoluent selon rouge ↝ ↝ ↝ ↝ vert ↝ ↝ ↝ ↝ jaune ↝ ↝ ↝ ↝ rouge Lorsque le feu est au rouge sur une voie, les véhicules de cette voie ne peuvent s’engager dans le carrefour Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 29. Exemple : Contrôleur de feux de circulation d’un carrefour Propriétés souhaitées: Condition de sûreté (safety) : les véhicules ne peuvent s’engager dans les deux voies simultanément. on n’a pas les deux feux différents de rouge Condition de vivacité (liveness) : les véhicules ne sont pas bloqués infiniment sur l’une des (ou les deux) voies. 29 bloqués infiniment sur l’une des (ou les deux) voies. on n’a pas les deux feux rouge Ces propriétés sont décrites par : ((feuA=rouge)∧(feuB≠rouge))∨((feuA≠rouge)∧(feuB=rouge)) Définition de l’état des feux : ETAT = {es, hs} etat ∈ ETAT Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 30. Exemple : Contrôleur de feux de circulation d’un carrefour Caractérisation de l’état hors service Etat = hs ⇔ feuA = jaune ∧ feuB = jaune Caractérisation de l’état en service Etat = es ⇒ feuA = rouge ∨ feuB = rouge 30 Etat = es ⇒ feuA = rouge ∨ feuB = rouge Caractérisation de la disponibilité (état en service) Etat = es ⇒ feuA ≠ rouge ∨ feuB ≠ rouge Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 31. + modèles graphiques, intuitifs, + sémantique précise et rigoureuse Méthodes semi formelles STATEMATE, SA-RT, UML Méthodes formelles B, Z, CTL, FNLOG I.5. Formalismes pour représenter des spécifications 31 + modèles graphiques, intuitifs, visualiser, concevoir et de documenter des systèmes + éditeurs visuels, génération du code, validation - absence d’une sémantique précise, pas de vérification des propriétés - difficiles à utiliser par les non familiarisés - manque de support de communication - manque de qualité de structuration rigoureuse + vérification et la validation Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 32. 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) I.5. Formalismes pour représenter des spécifications 32 (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 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 33. 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 I.5. Formalismes pour représenter des spécifications 33 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 Pétri, 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, etc. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 34. I.6. 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 34 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. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 35. 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 I.6. Techniques de vérification 35 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. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 36. II. la méthode B (Jean Raymond Abrial) Plan II.1. Présentation II.2. Notion de machine abstraite II.3. Les clauses d’une machine abstraite 36 II.4. Les obligations de preuve II.5. Définition et calcul des substitutions généralisées II.6. Les substitutions généralisées II.7. Le processus de raffinement II.8. Les obligations de preuve du raffinement II.9. La modularité Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 37. II.1. Présentation Les logiciels conçus avec la méthode B fonctionnent conformément à leurs spécifications Les propriétés sont exprimées par des invariants et vérifiées par preuves formelles. Le raffinement consiste à reformuler les données et opérations d'une machine abstraite (Composant 37 et opérations d'une machine abstraite (Composant initial) à l'aide de données et opérations plus proches de l'implémentation (Composant raffiné) tout en conservant les propriétés de la machine abstraite. Suppression des pré-conditions Suppression de l’indéterminisme Introduction de la séquence et des boucle Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 38. M2 raffine M1 Par tout où on utilise M1, M2 doit rendre le même service L'interface externe doit être conservée Chaque raffinement donne lieu à une preuve de la validité de la reformulation de la machine abstraite. II.1. Présentation 38 Chaque raffinement donne lieu à une preuve de la validité de la reformulation de la machine abstraite. La dernière phase de raffinement permet d'atteindre un niveau de pseudo-code que l'outil associé, l'atelier B, peut alors traduire automatiquement dans différents langages (C, Ada, C++). Le test du logiciel devient inutile, puisque le programme produit est formellement prouvé correct à la spécification initiale. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 39. Modèle abstrait Raffinement 1 Preuve du raffinement II.1. Présentation Raffinement Preuve PA Preuve PR1 PA: propriété abstraite PR: propriété de Raffinement n-1 Implémentation 2ème … ième raffinement Raffinement 2 Raffinement n Preuve PR2 Preuve PRn-1 Preuve PRn PR: propriété de raffinement 39 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 40. 1. On définit les données internes de la machine et leurs propriétés invariantes ; 2. On définit les opérations d’accès à la machine : pré- condition et transformation ; 3. L’atelier vérifie la syntaxe et le typage ; II.1. Présentation 40 4. L’atelier calcule les plus faibles pré-conditions et génère les preuves à faire ; 5. L’atelier tente de les prouver automatiquement ; 6. Si certaines preuves n’ont pas été démontrées, on détermine si : 1. l’opération est incorrecte et on corrige 2. le prouveur n’est pas assez « fort » et on aide le prouveur à réaliser la démonstration Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 41. II.2. Notion de machine abstraite En B On spécifie On prouve On développe On code Une (ou plusieurs) machine abstraite 41 Une (ou plusieurs) machine abstraite Cette notion est proche Type abstrait, Module, Classe, Composant Un composant logiciel peut être vu comme une fonction Munie d’une mémoire Encapsule des données Dans la méthode B, un composant logiciel est appelé machine abstraite qui contient: Des données Des opérations Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 42. II.2. Notion de machine abstraite Structure d’une machine abstraite PARIE ENTETE Nom de la machine Paramètres de la machine Contraintes sur les paramètres 42 PARTIE STATIQUE Déclaration d'ensembles Déclaration de constantes Propriétés des constantes Déclaration des variables (état) Invariant (caractérisation de l'état) PARTIE DYNAMIQUE Initialisation des variables Opérations END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 43. II.3. Les clauses d’une MA MACHINE Nom de la machine abstraite (idem nom de la classe) SETS Déclaration des ensembles abstraits et énumérés CONSTANTS Définition des constantes PROPERTIES Propriétés sur les constantes 43 Propriétés sur les constantes VARIABLES Déclaration des variables (idem attributs d’une classe) INVARIANT Typage et propriété des variables INITIALISATION Définition de la valeur initiale des variables (idem constructeur) OPERATIONS Déclaration des opérations (idem méthodes) END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 44. II.3.1. L’en-tête Un nom + optionnellement des paramètres pour la généricité 44 MACHINE MACHINE MACHINE MACHINE calculatrice réservation pile(ELEMENT) variable (TYPE) END END END END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 45. II.3.2. Les données La définition des données s’appuie sur un langage d’expressions les symboles désignant les données de base de la machine (ensembles abstraits, variables, constantes…) les expressions booléennes 45 les expressions booléennes les expressions arithmétiques les ensembles, relations, fonctions, les suites… Ces données sont caractérisées par un invariant Une formule de la logique des prédicats exprimée au moyen de prédicats ensemblistes (appartenance, inclusion…) et d’opérateurs relationnels. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 46. II.3.2. Les données Les données d'une "machine abstraite" sont décrites au moyen des clauses suivantes: la clause MACHINE : elle introduit le nom qui identifie la machine. la clause SETS : elle représente les ensembles introduits par la machine. Ce sont soit des ensembles abstraits, soit des ensembles 46 machine. Ce sont soit des ensembles abstraits, soit des ensembles énumérés définis par la liste de leurs éléments. Les ensembles abstraits sont utilisés pour désigner des objets dont on ne veut pas définir la structure au niveau de la spécification. La clause CONSTANTS: déclare une liste de constantes. La clause PROPERTIES: définit un prédicat qui type les constantes et spécifie des conditions sur les constantes et les ensembles de la machine abstraite. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 47. II.3.2. Les données la clause VARIABLES : elle introduit la liste des variables de la machine. Elles représentent l´état de la machine. Les variables sont les seules objets qui peuvent être modifiés directement dans l'initialisation et les opérations de la machine. Cette clause doit être accompagnée des clauses INVARIANT et INITIALISATION. Elle peut être absente si la machine n'a pas de variables. 47 la clause INVARIANT : elle regroupe un ensemble de prédicats. Ces prédicats définissent les propriétés mathématiques des variables de la machine, et permettent de typer les variables et de définir certaines contraintes que doit vérifier l'état de la machine à tout moment. Cette clause est obligatoire si la clauses VARIABLE est présente. Les invariants de typage ( var ∈ ENSEMBLE ) Les propriétés sur les variables de la machine ou propriétés de sûreté (¬(var1=TRUE ∧ var2=TRUE)) Les propriétés ensemblistes ( f∈ SET1 × SET2→ N) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 48. II.3.2. Les données • Des constantes munies de propriétés • Des variables munies d’ un invariant MACHINE En-tête CONSTANTS Liste des constantes 48 Liste des constantes PROPERTIES Propriétés des constantes VARIABLES Liste des variables INVARIANT Invariant des variables … END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 49. II.3.2. Les données Une machine sans variable MACHINE Unité_arithmétique CONSTANTS min_ent, max_ent, ENTIER 49 min_ent, max_ent, ENTIER PROPERTIES min_ent = -231 max_ent = 231 - 1 ENTIER = min_ent .. max_ent … END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 50. II.3.2. Les données Une machine avec variables • Il est fondamental qu’une machine avec variable soit munie d’un invariant : il permet d’ exprimer les exigences de fonctionnement de la machine. 50 MACHINE Chaudière SETS ETATS = {arm, dsm} VARIABLES T, Alarme INVARIANT T ∈ ∈ ∈ ∈ NAT ∧ ∧ ∧ ∧ Alarme ∈ ∈ ∈ ∈ ETATS ∧ ∧ ∧ ∧ (T > 130) ⇒ ⇒ ⇒ ⇒ (Alarme = arm) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 51. II.3.3. La partie dynamique la clause INITIALISATION : elle se compose des substitutions qui définissent les valeurs initiales de chaque variable propre à la machine. Toute variable propre à la machine doit être initialisée. Cette initialisation doit satisfaire l'invariant de la machine. Cette clause est obligatoire si la clause VARIABLE est présente. la clause DEFINITIONS : elle contient une liste d'abréviations pour un prédicat, une expression ou une substitution. Les définitions peuvent être 51 prédicat, une expression ou une substitution. Les définitions peuvent être utilisées dans la suite de la machine et sont locales à la machine où elles sont définies. La clause OPERATIONS définit une liste d’opérations. Ces opérations peuvent être paramétrées en entrée (w) et en sortie (u) par une liste de scalaires. Les paramètres, en entrée, éventuels d’une opération sont typés explicitement dans la pré-condition Q de l’opération. En revanche, les paramètres en sortie éventuels d’une opération sont typés implicitement en fonction de type des expressions définissant la valeur de ces paramètres dans la substitution V qui définit le comportement de l’opération vis à vis de l’état de la machine. Il est important de noter que les opérations d’une machine ne peuvent pas être référencées dans la machine où elles sont définies. u← O(w) = pre Q then V end Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 52. Exemple : réservation MACHINE reservation VARIABLES nbPlacesLibres, capacite 52 nbPlacesLibres, capacite INVARIANT nbPlacesLibres ∈ NAT ∧ capacite∈ NAT ∧ nbPlacesLibres ≤ capacite END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 53. II.3.4. Les opérations Une en-tête liste des paramètres de sortie <-- NOM (liste des paramètres d’entrée) Une pré-condition Typage des paramètres d’entrée Conditions de fonctionnement de l’opération (domaine 53 Conditions de fonctionnement de l’opération (domaine de définition) Une transformation Définition de l’opération comme une transformation des données internes et une affectation de valeurs aux paramètres de sortie Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 54. II.3.4. Les opérations MACHINE Unité_arithmétique … OPERATIONS ecrire_nombre (a) ... ; 54 a ‹ — lire_nombre ... ; c ‹ — plus (a, b) ... ; c ‹ — moins (a, b) ... ; c ‹ — mult (a, b) ... ; c, d ‹ — div_mod (a, b) ... ; END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 55. II.3.4. Les opérations Opérations avec precondition • Une précondition sert d’hypothèse pour prouver l’ opération • Il faut prouver que la précondition est satisfaite pour utiliser l’ opération MACHINE Unité_arithmétique … OPERATIONS 55 OPERATIONS … r ‹ — plus (a, b) = PRE a ∈ ENTIER ∧ b ∈ ENTIER ∧ a + b ∈ ENTIER THEN r := a + b END ; ... Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 56. II.3.4. Les opérations r, o ‹ — add (a, b) = PRE a ∈ ENTIER ∧ b ∈ ENTIER THEN IF a + b ∈ ENTIER THEN 56 THEN r := a + b || o := false ELSE o := true END END ... END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 57. II.3.4. Les opérations MACHINE Chaudière SETS ETATS = {arm, dsm} VARIABLES T, Alarme INVARIANT T ∈ NAT ∧ Alarme ∈ ETATS ∧ ⇒ 57 Alarme ∈ ETATS ∧ (T > 130) ⇒ (Alarme = arm) OPERATIONS changerT (v) == PRE v ∈ NAT ∧ v ≤ 130 THEN T := v END … Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 58. Exemple : reservation MACHINE reservation … OPERATIONS 58 OPERATIONS reserver(nbPlaces)= PRE nbPlaces ∈ NAT1 ∧ nbPlaces ≤ nbPlacesLibres THEN Transformation END END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 59. II.3.5. Les transformations La définition des opérations s’appuie sur le langage des substitution généralisées La transformation de base est la substitution simple devient égal, notée := 59 simple devient égal, notée := Les autres transformations permettent de modéliser le résultat de tous les changements d’états réalisables par algorithmique Les boucles en particulier sont souvent modélisées par des substitutions indéterministes Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 60. Exemple : reservation reserver(nbPlaces)= PRE nbPlaces ∈ NAT1 ∧ nbPlaces ≤ nbPlacesLibres 60 nbPlaces ≤ nbPlacesLibres THEN nbPlacesLibres := nbPlacesLibres-nbPlaces END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 61. II.4. Les obligations de preuve (Preuve de cohérence) La dernière étape de la spécification consiste à prouver la cohérence de chaque machine abstraite C’est l’obligation de preuve On prouve que l’initialisation vérifie l’invariant 61 On prouve que l’initialisation vérifie l’invariant On prouve pour chaque opération que lorsque la machine est dans un état correct → → → → les propriétés invariantes I sont supposées vérifiées lorsque l’opération est appelée avec la → → → → la pré-condition Q d’appel est supposée vérifiée alors sa transformation V amène la machine dans un état correct → → → → un état qui satisfait l’invariant I (Les points fort de B sont la génération automatique des obligations de preuve et le raffinement) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 62. MACHINE M VARIABLES Obligation de preuve pour l’initialisation V Init ⇒ ⇒ ⇒ ⇒ I INVARIANT Obligation de preuve pour une opération o I II.4. Les obligations de preuve (Preuve de cohérence) 62 I OPERATIONS I ∧ ∧ ∧ ∧ Q ⇒ ⇒ ⇒ ⇒ I après V u ← O(W) = PRE Q THEN V END END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 63. Substitution [x:=E]P représente la formule P dans laquelle toutes les occurences libres de x sont remplacées par E Si V est x:=E alors [V]I décrit l’état de l’invariant II.4. Les obligations de preuve (Preuve de cohérence) 63 Si V est x:=E alors [V]I décrit l’état de l’invariant après l’exécution de V Si x est une des variables utilisées dans I alors la substitution traduit bien l’effet de V Obligation de preuve pour une opération de précondition Q et d’action V est alors [Init] I I ∧ ∧ ∧ ∧ Q ⇒ ⇒ ⇒ ⇒ [V]I Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 64. Exemple : réservation MACHINE I ∧ ∧ ∧ ∧ Q ⇒ ⇒ ⇒ ⇒ [V]I reservation VARIABLES nbPlacesLibres, capacite INVARIANT nbPlacesLibres ∈ NAT ∧ capacite∈ NAT ∧ I 64 capacite∈ NAT ∧ nbPlacesLibres ≤ capacite OPERATIONS reserver(nbPlaces)= PRE nbPlaces ∈ NAT1 ∧ nbPlaces ≤ nbPlacesLibres THEN nbPlacesLibres := nbPlacesLibres-nbPlaces END END ``` I Q V Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 65. 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 : 65 Hors service (hs) : tous les feux sont au jaune En service (es) : ils évoluent selon rouge ↝ ↝ ↝ ↝ vert ↝ ↝ ↝ ↝ jaune ↝ ↝ ↝ ↝ rouge Lorsque le feu est au rouge sur une voie, les véhicules de cette voie ne peuvent s’engager dans le carrefour Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 66. Exemple : Contrôleur de feux de circulation d’un carrefour Propriétés souhaitées: Condition de sécurité (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. Ces propriétés sont décrites par : 66 Ces propriétés sont décrites par : ((feuA=rouge)∧(feuB≠rouge))∨((feuA≠rouge)∧(feuB=rouge)) Définition des couleurs des feux : COULEUR = {rouge , jaune , vert} feuA ∈ COULEUR , feuB ∈ COULEUR Définition de l’état des feux : ETAT = {es, hs} etat ∈ ETAT Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 67. Exemple : Contrôleur de feux de circulation d’un carrefour Caractérisation de l’état hors service Etat = hs ⇔ feuA = jaune ∧ feuB = jaune Caractérisation de l’état en service Etat = es ⇒ feuA = rouge ∨ feuB = rouge Caractérisation de la disponibilité (état en service) ⇒ 67 ⇒ Caractérisation de la disponibilité (état en service) Etat = es ⇒ feuA ≠ rouge ∨ feuB ≠ rouge L’ évolution des feux est décrite par une fonction constante: Suiv ∈ Couleur → Couleur Les opérations sur les feux de circulation sont: Mise en service Mise hors service Changer feu Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 68. Exemple : Contrôleur de feux de circulation d’un carrefour MACHINE Carrefour SETS Couleur = {rouge, jaune, vert} CONSTANT Suiv PROPERTIEES Suiv ∈ ∈ ∈ ∈ Couleur X Couleur ∧ ∧ ∧ ∧ ∧ ∧ ∧ ∧ 68 Suiv(rouge) = vert ∧ ∧ ∧ ∧ Suiv(vert) = jaune ∧ ∧ ∧ ∧ Suiv(jaune) = rouge VARIABLES feuA, feuB DEFNITIONS hs == feuA = jaune ∧ ∧ ∧ ∧ feuB = jaune service(aa, bb) = (aa = rouge ∧ ∧ ∧ ∧ bb ≠ ≠ ≠ ≠ rouge) ∨ ∨ ∨ ∨ (aa ≠ ≠ ≠ ≠ rouge ∧ ∧ ∧ ∧ bb = rouge) es == service(feuA, feuB) INVARIANT feuA, feuB ∈ ∈ ∈ ∈ Coulur X Couleur ∧ ∧ ∧ ∧ (hs ∨ ∨ ∨ ∨ es) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 69. Exemple : Contrôleur de feux de circulation d’un carrefour INITIALISATION feuA, feuB := jaune, jaune OPERATIONS Mise-en-service = PRE hs THEN ANY fa, fb WHERE fa, fb ∈ ∈ ∈ ∈ Couleur X Couleur ∧ ∧ ∧ ∧ Service(fa, fb) THEN feuA := fa feuB := fb 69 feuB := fb END END Mise-hors-service = PRE es THEN feuA, feuB := jaune, jaune END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 70. Exemple : Controleur de feux de circulation d’un carrefour Changer-feu = PRE es THEN ANY fa, fb WHERE ((fa = feuA ∧ ∧ ∧ ∧ fb = suiv(feuB)) ∨ ∨ ∨ ∨ (fa = suiv(feuA) ∧ ∧ ∧ ∧ fb = feuB) ∨ ∨ ∨ ∨ (fa = suiv(feuA) ∧ ∧ ∧ ∧ fb = suiv(feuB))) ∧ ∧ ∧ ∧ service(fa, fb) THEN feuA, feuB := fa, fb 70 feuA, feuB := fa, fb END END END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 71. Exemple : Réservation de places sur un vol limité à maxi places MACHINE RESERVATION1 CONSTANT Maxi PROPERTIES OPERATIONS Réserver PRE Nb ≠ 0 THEN Nb := Nb –1 71 PROPERTIES Maxi ∈ NAT VARIABLES Nb INVARIANT Nb ∈ 0..Maxi /*nbre de places*/ INITIALISATION Nb := Maxi Nb := Nb –1 END ; Libérer PRE Nb ≠ Maxi THEN Nb := Nb + 1 END ; END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 72. Exemple : Réservation de places sur un vol limité à maxi places OPERATIONS Réserver PRE Nb ≠ 0 THEN Nb := Nb –1 72 END ; Libérer PRE Nb ≠ Maxi THEN Nb := Nb + 1 END ; END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 73. Exemple : Réservation de places sur un vol limité à maxi places Ajout de la gestion des réservations MACHINE RESERVATION2(Maxi) CONSTRAINTS Maxi ∈ NAT SETS 73 SETS RES = {succès, échec} VARIABLES Nb INVARIANT Nb ∈ 0..Maxi /*nbre de places*/ INITIALISATION Nb := Maxi Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 74. Exemple : Réservation de places sur un vol limité à maxi places OPERATIONS R1 ← ← ← ← Réserver ≅ ≅ ≅ ≅ If Nb ≠ ≠ ≠ ≠ 0 THEN R1, Nb := succès, Nb -1 ELSE R1 := Echec 74 R1 := Echec END ; R2 ← ← ← ← Libérer ≅ ≅ ≅ ≅ If Nb ≠ ≠ ≠ ≠ Maxi THEN R2, Nb := succès, Nb + 1 Else R2 := Echec END ; END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 75. Exemple : Réservation de places sur un vol limité à maxi places Ajout de la gestion des places MACHINE RESERVATION3(Maxi) CONSTRAINTS Maxi ∈ NAT 75 Maxi ∈ NAT DEFINITION Sièges == 1..Maxi VARIABLES Occupés INVARIANT Occupés ⊆ Sièges INITIALISATION Occupés := ∅ Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 76. Exemple : Réservation de places sur un vol limité à maxi places OPERATIONS Place ← ← ← ← Réserver ≅ ≅ ≅ ≅ PRE Occupés ≠ ≠ ≠ ≠ Sièges THEN ANY pp WHERE pp ∈ ∈ ∈ ∈ Sièges – Occupés THEN 76 THEN Place, Occupés := pp, Occupés ∪ ∪ ∪ ∪ {pp} END END ; Libérer (place) ≅ ≅ ≅ ≅ PRE place ∈ ∈ ∈ ∈ Occupés THEN Occupés := Occupés {place} END ; END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 77. Exemple: Distributeur de boissons On souhaite spécifier le fonctionnement d’une machine qui délivre des boissons. Le fonctionnement est décrit comme suit : La machine peut être en arrêt ou en marche, Il y a un bouton pour mettre en marche et arrêter la machine Les actions suivantes n’ont d’effet que si la machine est en marche - L’usager peut sélectionner une certaine boisson. Il y en a 3 : café, thé ou chocolat. 77 chocolat. - Après la sélection, l’appareil affiche la somme demandée. - L’usager peut alors payer avec les différentes pièces de monnaie. - L’appareil affiche la somme restante. - Dès qu’une somme suffisante est versée, l’appareil délivre la boisson à l’usager. - L’appareil rend éventuellement la monnaie. - On ne peut commander une nouvelle boisson que si le Goblet a été retiré de son emplacement. - A tout moment après la sélection de la boisson et avant que le distributeur ne délivre la boisson, l’usager peut annuler la commande. L’appareil doit alors rendre l’argent déjà versé s’il y a lieu Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 78. II.5. Les substitutions généralisées Substitutions multiples Choix borné 78 Substitution gardée Substitution vide Choix non borné. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 79. II.5. Les substitutions généralisées 79 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 80. II.5.1. Substitutions multiples Syntaxes x := E | | y := F x, y := E, F 80 sémantique [x, y := E, F] I [z := F][x := E][y := z]I [x := E | | y := F] I z étant une variable Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 81. II.5.1. Substitutions multiples Exemple [x, y := y, x] (x < y) [z := x][x := y][y := z] (x < y) [z := x][x := y] (x < z) 81 [z := x][x := y] (x < z) [z := x] (y < z) (y < x) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 82. II.5.2. Substitution choix borné Syntaxe [S [] T] [CHOICE S OR T END] 82 [CHOICE S OR T END] Sémantique [S [] T]I [S]I ∧ ∧ ∧ ∧ [T]I [CHOICE S OR T END]I Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 83. II.5.2.Substitution choix borné Exemple d ‹ — empiler(w) = PRE w ∈ ∈ ∈ ∈ VALEUR THEN 83 CHOICE d := ok | | sequence := sequence ‹ — w OR d := ko END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 84. Exemple: Select (Garde et Choix Borné) Exprime un choix de substitution sous condition SELECT P1 THEN S1 P1 ⇒ ⇒ ⇒ ⇒ S1 [] ⇒ ⇒ ⇒ ⇒ 84 SELECT P1 THEN S1 P1 ⇒ ⇒ ⇒ ⇒ S1 [] [WHEN P2 THEN S2 P2 ⇒ ⇒ ⇒ ⇒ S2 [] … ≈ ≈ ≈ ≈ … WHEN Pn THEN Sn] Pn ⇒ ⇒ ⇒ ⇒ Sn [] [ELSE SE] ¬ ¬ ¬ ¬P1∧¬ ∧¬ ∧¬ ∧¬P2∧ ∧ ∧ ∧…∧¬ ∧¬ ∧¬ ∧¬Pn ⇒ ⇒ ⇒ ⇒ SE END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 85. Construction d’un SELON E une expression Li des listes de constantes toutes 2 à 2 distinctes et de même type que E ⇒ ⇒ ⇒ ⇒ 85 distinctes et de même type que E CASE E OF EITHER L1 THEN S1 E∈ ∈ ∈ ∈{L1} ⇒ ⇒ ⇒ ⇒ S1 [] [OR L2 THEN S2 E∈ ∈ ∈ ∈{L2} ⇒ ⇒ ⇒ ⇒ S2 [] … ≈ ≈ ≈ ≈ … OR Ln THEN Sn] E∈ ∈ ∈ ∈{Ln} ⇒ ⇒ ⇒ ⇒ Sn [] [ELSE SE] E∉ ∉ ∉ ∉{L1,L2…Ln} ⇒ ⇒ ⇒ ⇒ SE END (en l absence de ELSE END SKIP) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 86. Construction d’un SELON CASE x/10 OF EITHER 0 THEN x:=0 OR 2,4,8 THEN x:=2 OR 3,9 THEN 86 OR 3,9 THEN x:=1 ELSE x:=-1 END END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 87. II.5.3. Substitutions gardée Syntaxe IF P THEN S END [P ⇒ ⇒ ⇒ ⇒ S] ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ 87 ⇒ ⇒ ⇒ ⇒ Sémantique [P ⇒ ⇒ ⇒ ⇒ S]I P ⇒ ⇒ ⇒ ⇒ [S]I Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 88. II.5.3. Substitutions gardée Exemple IF v > 130 THEN T := v | | Alarm := arm else 88 else T := v END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 89. II.5.3. Substitution gardée Ne pas confondre avec la pré-condition Précondition Définition [P | S ] I P ∧ ∧ ∧ ∧ [S]I PRE P THEN S END 89 Si-alors-sinon Conditionnelle Définition [IF P THEN S ELSE T END ]I (P ⇒ ⇒ ⇒ ⇒ [S]I) ∧ ∧ ∧ ∧ (¬ ¬ ¬ ¬P ⇒ ⇒ ⇒ ⇒ [T]I) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 90. Forme générale du IF IF P1 THEN S1 P1 ⇒ ⇒ ⇒ ⇒ S1 [] [ELSIF P2 THEN S2 ¬ ¬ ¬ ¬P1∧ ∧ ∧ ∧P2 ⇒ ⇒ ⇒ ⇒ S2 [] … ≈ ≈ ≈ ≈ … ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ 90 ⇒ ⇒ ⇒ ⇒ … ≈ ≈ ≈ ≈ … ELSIF Pn THEN Sn] ¬ ¬ ¬ ¬P1∧¬ ∧¬ ∧¬ ∧¬P2∧ ∧ ∧ ∧…¬ ¬ ¬ ¬Pn-1∧ ∧ ∧ ∧Pn ⇒ ⇒ ⇒ ⇒ Sn [] [ELSE SE] ¬ ¬ ¬ ¬P1∧¬ ∧¬ ∧¬ ∧¬P2∧ ∧ ∧ ∧…¬ ¬ ¬ ¬Pn-1∧¬ ∧¬ ∧¬ ∧¬Pn ⇒ ⇒ ⇒ ⇒ SE END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 91. II.5.4. Substitution vide Skip : spécifie que l’état de la machine n’est pas modifié Substitution vide Définition [skip]I I 91 Si-alors Conditionnelle Définition [IF P THEN S END]I [(P ⇒ ⇒ ⇒ ⇒ S) ∧ ∧ ∧ ∧ (¬ ¬ ¬ ¬P ⇒ ⇒ ⇒ ⇒ skip)]I Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 92. II.5.5. Substitution Choix non borné laisse le choix entre plusieurs valeurs satisfaisant une propriété spécifiée On utilise une variable intermédiaire contrainte par une formule P et on exprime la substitution avec cette variable Syntaxe @z.(P ⇒ ⇒ ⇒ ⇒ S) 92 @z.(P ⇒ ⇒ ⇒ ⇒ S) ANY z WHERE P THEN S END Sémantique [@z.(P ⇒ ⇒ ⇒ ⇒ S)]I ≡ ≡ ≡ ≡ ∀ ∀ ∀ ∀z.[P ⇒ ⇒ ⇒ ⇒ S]I ≡ ≡ ≡ ≡ ∀ ∀ ∀ ∀z.(P ⇒ ⇒ ⇒ ⇒[S]I) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 93. II.5.5. Substitution Choix non borné Exemple b ‹ — nouveau_né(s) = PRE PERSONNES - personnes ≠ ≠ ≠ ≠ Φ ∧ ∧ ∧ ∧ s ∈ ∈ ∈ ∈ GENRE THEN 93 ANY m WHERE m ∈ ∈ ∈ ∈ PERSONNES - personnes THEN personnes := personnes ⋃ ⋃ ⋃ ⋃ { m } | | genre(m) := s | | etat(m) := vivant | | b := m END END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 94. Dérivées du choix non borné Substitution « devient élément de » x:∈ ∈ ∈ ∈E Exemple : nbPlaceLibre:∈Natural 94 Substitution « devient tel que » x:(P) Exemple : x:(x<100 ∧ x>x$0) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 95. Exemple de calcul de substitution I ∧ Q ⇒ [V]I devient 1. T ∈ NAT ∧ Alarme ∈ ETATS ∧ ((T > 130) ⇒ (Alarme = arm)) ∧ v ∈ NAT ∧ v ≤ 130 ⇒ [T := v] (T ∈ NAT ∧ Alarme ∈ ETATS ∧ MACHINE Chaudiere SETS ETATS = {arm, dsm} VARIABLES T, Alarme INVARIANT 95 Alarme ∈ ETATS ∧ ((T > 130) ⇒ (Alarme = arm))) Après application de la substitution, on obtient: 2. T ∈ NAT ∧ Alarme ∈ ETATS ∧ ((T > 130) ⇒ (Alarme = arm)) ∧ v ∈ NAT ∧ v ≤ 130 ⇒ (v ∈ NAT ∧ Alarme ∈ ETATS ∧ ((v > 130) ⇒ (Alarme = arm))). INVARIANT T ∈ NAT ∧ Alarme ∈ ETATS ∧ (T > 130) ⇒ (Alarme = arm) OPERATIONS changerT (v) == PRE v ∈ NAT ∧ v ≤ 130 THEN T := v END … Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 96. Exemple de calcul de substitution I ∧ Q ⇒ [V]I devient 1. T ∈ NAT ∧ Alarme ∈ ETATS ∧ ((T > 130) ⇒ (Alarme = arm)) ∧ v ∈ NAT ∧ alarme = dsm ⇒ (v ≤ 130 ⇒ [T := v] (T ∈ NAT ∧ Alarme ∈ ETATS ∧ MACHINE Chaudiere SETS ETATS = {arm, dsm} VARIABLES T, Alarme INVARIANT 96 Alarme ∈ ETATS ∧ ((T > 130) ⇒ (Alarme = arm))) ∧(v > 130 ⇒ [T := v] [alarme := arm] (T ∈ NAT ∧ Alarme ∈ ETATS ∧ ((T > 130) ⇒ (Alarme = arm))) ∧ [T :=V][alarme := arm] (T ∈ NAT ∧ Alarme ∈ ETATS ∧ ((T > 130) ⇒ (Alarme = arm))) INVARIANT T ∈ NAT ∧ Alarme ∈ ETATS ∧ (T > 130) ⇒ (Alarme = arm) OPERATIONS changerT (v) == PRE v ∈ NAT ∧ alarme = dsm THEN if (v ≤ 130) then T := v else T:= V || alarme := arm END … Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 97. II.6. Notation de modélisation des données Un langage pour décrire INVARIANT, PRE-CONDITION, EXPRESSION 97 EXPRESSION Concepts et notations utilisés Logique Ensembles Relations binaires et fonctions Arithmétique Suites Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 98. II.6.1. Logique : connecteurs ET ∧ (ASCII : &) OU ∨ (ASCII : or) NON ¬ (ASCII : not) 98 NON ¬ (ASCII : not) SI-ALORS ⇒ ⇒ ⇒ ⇒ (ASCII : =>) EQUIV. ⇔ (ASCII : <=>) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 99. II.6.1. Logique : quantificateurs Universel ∀ ∀ ∀ ∀ listeDeVariables . (P ⇒ ⇒ ⇒ ⇒ Q) (ASCII : !) ∀ x,y . (x∈ NAT ∧ y∈ NAT ∧ x=quantite(y) ⇒ ⇒ ⇒ ⇒ x≥0) Existentiel 99 Existentiel ∃ ∃ ∃ ∃ listeDeVariables . (P) (ASCII : #) ∃ x . (x∈ NAT∧ x=0) Predicat = = ≠ (/= en ASCII). Couple (a,b) (en B symbole maplet |-> : a|->b) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 100. II.6.2. Ensemble : désignation Définit par Extension E={1,3,5,7,9} Définit par Compréhension 100 Définit par Compréhension E={x | x ∈ Z ∧ x>0 ∧ x<10 ∧ x mod 2 =1} L’ensemble vide {} Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 101. II.6.2. Ensemble : les prédéfinis N les entiers naturels (NATURAL en ASCII) N* les entiers naturels non nuls (NATURAL1 en ASCII) Z les entiers relatifs (INTEGER en ASCII) I..J les intervalles d’entier, l’ensemble des valeurs comprises entre 101 I..J les intervalles d’entier, l’ensemble des valeurs comprises entre I et J (bornes incluses) INT les entiers relatifs implantables : MININT..MAXINT NAT les entiers naturels implantables : 0..MAXINT NAT1 les entiers naturels non nuls implantables : 1..MAXINT BOOL les booléens = {FALSE,TRUE} bool(P) retourne le booléen résultat d’une formule FOL STRING l’ensemble des chaînes de caractères. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 102. II.6.2. Ensemble : les prédicats x ∈ E (: en ASCII) E1 ⊆ E2 (<: en ASCII, ⊂ notée <<:) E1 x E2 (* en ASCII) Produit cartésien non commutatif 102 Produit cartésien non commutatif a|->b ≠ b|->a P(E) (POW en ASCII) Négation des prédicats par le symbole / ∉ devient /: en ASCII Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 103. II.6.2. Ensemble : les prédicats x ∈ E (: en ASCII) E1 ⊆ E2 (<: en ASCII, ⊂ notée <<:) E1 x E2 (* en ASCII) Produit cartésien non commutatif 103 Produit cartésien non commutatif a|->b ≠ b|->a P(E) (POW en ASCII) Négation des prédicats par le symbole / ∉ devient /: en ASCII Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 104. II.6.2. Ensembles : les opérateurs l’union E1 ∪ E2 (/ en ASCII) l’ensemble des éléments appartenant à E1 ou E2 l’intersection E1 ∩ E2 (/ en ASCII) l’ensemble des éléments appartenant aux deux 104 ensembles E1 et E2 la différence E1 - E2 l’ensemble des éléments appartenant à E1 mais pas à E2 choice(E) un élément indéterminé de l’ensemble E Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 105. II.6.3. Relations binaires: vocabulaire r est un sous-ensemble du produit cartésien D x A de deux ensembles D : ensemble de départ 105 D : ensemble de départ A : ensemble d’arrivée Soit un couple d|->a d’une relation r a est une image de d par r d est un antécédent de a par r Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 106. II.6.3. Relations binaires: vocabulaire r est un sous-ensemble du produit cartésien D x A de deux ensembles D : ensemble de départ 106 D : ensemble de départ A : ensemble d’arrivée Soit un couple d|->a d’une relation r a est une image de d par r d est un antécédent de a par r Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 107. II.6.3. Relations binaires: déclaration et Opérations r ⊆ D x A ou r ∈ P(D x A) ou r ∈ ∈ ∈ ∈ D↔A r est une relation de D dans A D↔A désigne l’ensemble de toutes les relations de D vers A D↔A = P(D x A) noté <-> en ASCII 107 noté <-> en ASCII Le domaine : dom(r) l’ensemble des éléments de D qui ont une image par r {d | d∈D ∧ ∃a.(a∈A ∧ (d,a)∈r)} Le co-domaine (« range ») : ran(r) l’ensemble des éléments de A qui ont un antécédent par r {a | a∈A ∧ ∃d.(d∈D ∧ (d,a)∈r)} Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 108. II.6.3. Relations binaires: déclaration et Operations Soit r ∈ D↔A et q ∈ A↔C l’inverse : r-1 (r~ en ASCII) la relation de A↔D définie par {(a,d) | (a,d)∈AxD ∧ (d,a) ∈ r} la composition : r;q 108 la composition : r;q la relation de D↔C définie par {(d,c) | (d,c)∈DxC ∧ ∃ a.(a ∈ A ∧ (d,a) ∈ r ∧ (a,c) ∈ q)} l’ensemble d’arrivée de r doit être identique à celui de départ de q la relation identité sur un ensemble : id(D) la relation de D↔D définie par {(d,a) | (d,a)∈DxD ∧ d=a} Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 109. II.6.3. Relations binaires: déclaration et Operations Soit r ∈ D↔A et E⊆D et B⊆A la restriction de domaine : E r (<| en ASCII) la relation incluse dans r définie par {(d,a) | (d,a)∈r ∧ d ∈ E} ; la co-restriction : r B (|> en ASCII) 109 la co-restriction : r B (|> en ASCII) la relation incluse dans r définie par {(d,a) | (d,a)∈r ∧ a ∈ B} ; l’anti-restriction : E r (<<| en ASCII) la relation incluse dans r définie par {(d,a) | (d,a)∈r ∧ d∉E} l’anti-co-restriction : r B (|>> en ASCII) la relation incluse dans r définie par {(d,a) | (d,a)∈r ∧ a∉B} Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 110. II.6.3. Relations binaires: déclaration et Operations Soit r∈D↔A et p∈D↔A L’image relationnelle : r[E] l’ensemble des images des éléments de E par r {a | a∈A ∧ ∃d.(d∈E ∧ (d,a)∈r)} 110 {a | a∈A ∧ ∃d.(d∈E ∧ (d,a)∈r)} La surcharge : r<+p l’écrasement de la relation par la relation p {(d,a) | (d,a)∈DxA ∧ ((d,a)∈p ∨ (d∉dom(p) ∧ (d,a)∈r))} Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 111. II.6.4. Fonctions: 4 caractéristiques la fonction totale (-->) tout élément de l’ensemble de départ a une et une seule image La fonction partielle (+->) tout élément de l’ensemble de départ a au plus une image 111 l’injection (>-) tout élément de l’ensemble d’arrivée a au plus un antécédent la surjection (->>) tout élément de l’ensemble d’arrivée a au moins un antécédent Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 112. II.6.4. Fonctions : nouveaux opérateurs l’image fonctionnelle d’un élément : f(x) f doit être une fonction x doit appartenir à son domaine fonctions abstraites (lambda expressions) : 112 fonctions abstraites (lambda expressions) : λ λ λ λx.(x∈ ∈ ∈ ∈D | e) D est le domaine de définition de la fonction e une expression paramétrée par x définissant l’image pour tout x de D (λ noté % en ASCII) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 113. II.6.5. Arithmétique des entiers Les comparateurs <, >, ≤, ≥ (<= et >= en ASCII) Les opérateurs binaires 113 Les opérateurs binaires +, -, *, / (la division entière) mod (le modulo) xy (x**y en ASCII) Les opérateurs unaires succ, pred Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 114. II.6.6. Arithmétique des ensembles L’opérateur card(E) : Le nombre d’éléments d’un ensemble Les opérateurs max(E) et min(E) Prennent un ensemble d’entiers non vide en paramètre Retourne l’entier le plus grand (resp. le plus petit) de l’ensemble 114 Les opérateurs ∑ et ∏ (SIGMA et PI en ASCII) Calculent la somme (le produit) d’expressions arithmétiques ∑(x,y…).(P | E) P est une formule de la logique des prédicats et E une expression arithmétique (P et E dépendant des variables x,y…) Somme pour toutes valeurs de variables x,y… satisfaisant P des expressions E correspondants aux valeurs des variables Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 115. Opérateurs sur les ensembles 115 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 116. Opérateurs sur les relations 116 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 117. Opérateurs sur les relations 117 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 118. Opérateurs sur les relations 118 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 119. Exemple : Application à la modélisation Soit un ensemble personne ⊆ PERSONNE : R1 : toute personne est soit un homme, soit une femme R2 : une personne ne peut être à la fois un homme et une femme R3 : seules les femmes peuvent avoir un mari qui est un homme 119 R4 : les femmes ont au plus un mari R5 : les hommes ne peuvent être mariés qu’à au plus une femme R6 : les mères d’une personne sont des femmes mariées Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 120. Exemple : Application à la modélisation 120 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 121. Exemple : Application à la modélisation d’un ascenseur On souhaite spécifier le fonctionnement simplifié d’un ascenseur. une porte à chaque étage l’appel intérieur et l’appel extérieur ne sont pas distingués il n’y a pas de panne une constante donne le nombre d’étages : max_etage (> 0) Les opérations sont : 121 Les opérations sont : ouvrir, fermer une porte, appeler l’ascenseur, déplacement de l’ascenseur l’ascenseur reste dans la limite des étages si une porte est ouverte l’ascenseur est arrêté à l’étage correspondant chaque appel est traité en un temps raisonnable si l’ascenseur est arrêté à un étage, l’appel à cet étage est considéré comme traité . . . Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 122. Exemple : Application à la modélisation d’un ascenseur 122 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 123. Exemple : Distributeur de carnets de timbres 123 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 124. Exemple : Distributeur de carnets de timbres 124 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 125. Exemple : Distributeur de carnets de timbres 125 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 126. Exemple : Application à la modélisation Problème : On veut spécier une opération qui alloue un mot dans une mémoire et retourne l'adresse de l'emplacement alloué, s'il y a de la place en mémoire. ADRESSES ensemble abstrait d'adresses 126 ADRESSES ensemble abstrait d'adresses memoire : les adresses de la mémoire à allouer libres : l'ensemble des adresses libres null : une adresse particulière Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 127. Exemple : Application à la modélisation Solution 1 l’utilisateur n’a pas à tester la précondition. Si l’adresse de retour est null, cela signifie à l’utilisateur que la mémoire est pleine et que l’allocation n’a pas été possible : 127 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 128. Exemple : Application à la modélisation Solution 2 Moins d’indéterminisme 128 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 129. Exemple : Application à la modélisation Description des états des utilisateurs d’ordinateurs Un utilisateur ne peut être en même temps connecte et non connecte a un ordinateur. Cependant un utilisateur est connecte ou non connecte. 129 Seules les connectes ont des numéros de compte. Les connectes n’ont qu’un seul numéro de compte. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 130. Exemple : Formalisation Soit les ensembles abstraits UTILISATEUR et NUM Connecte ⊆ UTILISATEUR NonConnecte = UTILISATEUR – Connecte 130 NonConnecte = UTILISATEUR – Connecte aPournumcompte ∈ Connecte --> NUM Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 131. Exemple : Le contrôle d'accès aux bâtiments P1. Le modèle comprend des personnes et des bâtiments P2. Chaque personne est autorisée à pénétrer dans certains bâtiments (et pas dans d'autres). Les bâtiments non consignés dans cette autorisation sont implicitement interdits. Il s'agit d'une affectation permanente. P3. A un instant donné, une personne se trouve dans un 131 P3. A un instant donné, une personne se trouve dans un bâtiment au plus. D1. Le système gère le passage des personnes d'un bâtiment à l'autre. P4. A un instant donné, une personne se trouve dans un bâtiment au moins. P5. Toute personne se trouvant dans un bâtiment est bien autorisée à y être. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 132. Exemple : Le contrôle d'accès aux bâtiments (les personnes et les bâtiments) sont représentés par des ensembles abstraits, les autorisations aut d’accès des personnes aux bâtiments ainsi que les communications com entre les bâtiments sont représentées par des relations constantes, 132 représentées par des relations constantes, c’est à dire par des ensembles de couples, dont les types sont contraints dans la clause INVARIANT. La situation dynamique sit des personnes dans les bâtiments est représentée par une fonction totale. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 133. Exemple: Le contrôle d'accès aux bâtiments Outre l’information sur les types, l’invariant affirme qu’à chaque état, les personnes ne peuvent être que dans les bâtiments où elles sont autorisées d’entrer 133 com est irreflexive (aucun bâtiment ne communique avec lui-même). Le modèle présente une seule opération notée pass qui représente l’entrée d’une personne p dans un bâtiment b à condition que p soit autorisée d’entrer dans b et que b communique avec le bâtiment où se trouve p. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 134. Exemple : Le contrôle d'accès aux bâtiments (specification initiale, abstraite) 134 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 135. II.6.7. Ensembles, fonctions, relations MACHINE ASCENSEUR SETS ASC ; DIR = {mo, de} CONSTANT rdc, haut PROPERTIES bas ∈ INT ∧ haut ∈ INT ∧ bas < haut DEFINITIONS ETG == bas .. haut ; inactif == ASC - actif ; 135 ETG == bas .. haut ; inactif == ASC - actif ; VARIABLES actif, etage, direction, entrees, sorties INVARIANT actif ⊆ ASC ∧ etage ∈ ASC —› ETG ∧ dir ∈ ASC —› DIR ∧ entrees ∈ ETG ↔ DIR ∧ sortie ∈ ASC ↔ETG … INITIALISATION actif, entrees, sorties := Φ, Φ, Φ | | etage, dir := ASC x {bas}, ASC x {mo} Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 136. II.6.8. Tableau MACHINE TABLEAU (INDEX, VALEUR) VARIABLES tab INVARIANT tab ∈ INDEX —› VALEUR i ‹ — chercher (v) = PRE v ∈ VALEUR ∧ tab -1 [{v}] ≠ Φ THEN i :∈ tab -1 [{v}] 136 tab ∈ INDEX —› VALEUR OPERATIONS changer (v, i) = PRE v ∈ VALEUR ∧ i ∈ INDEX THEN tab (i) := v END ; v ‹ — valeur (i) = … ; THEN i :∈ tab -1 [{v}] END ; b, i ‹ — rechercher (v) = PRE v ∈ VALEUR THEN IF tab -1 [{v}] ≠ Φ THEN b := true || i :∈ tab -1 [{v}] ELSE b := false || i :∈ INDEX END END ; END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 137. II.6.8. Tableau b ‹ — est_present (v) = PRE v ∈ VALEUR THEN b := bool (tab -1 [{v}] ≠ Φ) b, i ‹ — rechercher (v) = PRE v ∈ VALEUR THEN IF tab -1 [{v}] ≠ Φ 137 b := bool (tab -1 [{v}] ≠ Φ) END ; i ‹ — chercher (v) = PRE v ∈ VALEUR ∧ tab -1 [{v}] ≠ Φ THEN i :∈ tab -1 [{v}] END ; IF tab -1 [{v}] ≠ Φ THEN b := true i :∈ tab -1 [{v}] ELSE b := false i :∈ INDEX END END ; END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 138. II.6.9. Les suites finies (Séquences) Les sequences Sequence finie d’elements de E : Toutes les sequences possibles d’elements de E Seq(E) : ∪ ∪ ∪ ∪ (n ∈ ∈ ∈ ∈ IN / 1, …, n → E) 138 Seq(E) : ∪ ∪ ∪ ∪n(n ∈ ∈ ∈ ∈ IN / 1, …, n → E) Seq1(E) = Seq(E) – Φ [ ] : sequence vide d’ elements de E [3, 7, 5] : represente la sequence des 3 entiers 3, 7, 5 [ ] = 1, …, 0 → E [ 3, 7, 5] = [1 ↦ 3, 2 ↦ 7, 3 ↦ 5] ↦ 3, 2 ↦ 7, 3 ↦ 5] ↦ 3, 2 ↦ 7, 3 ↦ 5] ↦ 3, 2 ↦ 7, 3 ↦ 5] Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 139. Opérations sur les sequences Ajout d’un élément à gauche a → S / a ∈E et S ∈ Seq(E) ⇒ ⇒ ⇒ ⇒ ; II.6.9. Les suites finies (Séquences) 139 a ∈E et S ∈ Seq(E) a → [ ] = {1 ↦ a} ↦ a} ↦ a} ↦ a} S ≠ ≠ ≠ ≠ Φ ⇒ ⇒ ⇒ ⇒ a → S = {1 ↦ a} ↦ a} ↦ a} ↦ a} ∪ ∪ ∪ ∪ {Succ {Succ {Succ {Succ ; S} [3, 7, 5] = (3 → (7 → (5 → [ ]) ; Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 140. Opérations sur les séquences size : longueur d’une séquence size ([ ]) = 0 ; II.6.9. Les suites finies (Séquences) 140 size ([ ]) = 0 Size(a → S) = 1 + size(S) Concaténation ^ [ ] ^ t = t a → S ^ t = a ^ t = a ^ t = a ^ t = a → (S ^ ^ ^ ^ t) ; Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 141. Operations sur les séquences Ajout à droite d’un element : ← [ ] ← b = b → [ ] (a → S) ← b = a → (S ← b) ; II.6.9. Les suites finies (Séquences) 141 rev : inverser la séquence rev([ ]) = [ ] rev(a → S) = rev(S) ← a Size(a → S) = 1 + size(S) Conc : Concaténation généralisée Conc ([ ]) = [ ] Conc (S → u) = S ^ = S ^ = S ^ = S ^ conc (u) ; Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 142. Selection des sous parties d’une séquence donnée Restriction à partir du bas notée S↑n ↑n ↑n ↑n : on garde les n premiers éléments de S Restriction à partir du haut notée S↓n ↓n ↓n ↓n : : : : ; II.6.9. Les suites finies (Séquences) 142 on supprime les n premiers éléments de S first(S) = S(1) last(S) = S(size(S)) tous les éléments sauf le premier: tail(S) = S↓1 ↓1 ↓1 ↓1 tous les éléments sauf le dernier: front(S) = S↑(size(S) ↑(size(S) ↑(size(S) ↑(size(S) – – – – 1) 1) 1) 1) ; Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 143. Exemple: Suites finies MACHINE SUITE (VALEUR, taille_max) VARIABLES sui INVARIANT sui ∈ seq (VALEUR) garder_les_premiers (i) = PRE i ∈ 0 .. size (sui) 143 sui ∈ seq (VALEUR) size (sui) ≤ taille_max OPERATIONS ajouter_a_la_fin (v) = PRE v ∈ VALEUR size (sui) < taille_max THEN sui := sui ← v END i ∈ 0 .. size (sui) THEN sui := sui . i END v ‹ — changer (i, v) @ … ; enlever_au_debut @ … ; enlever_a_la_fin @ … ; l ‹ — longueur @ … ; b ‹ — est_present (v) @ … ; i ‹ — chercher (v) @ … ; END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 144. II.7. Processus de raffinement Objectif : Passer de la spécification d’un module à son implémentation M1 M2 X y I J op1 = op1 = • Peut-on remplacer M1 par M2 ? 144 • Partout où on utilise M1, M2 doit rendre les mêmes services • L’ interface externe doit être conservée En pratique S substitution utilisant les opérations de M1 T identique à S utilisant les opérations de M2 Un prédicat I, de M1 si S établit I, T doit également établir I pour tout I, [S]I ⇒ ⇒ ⇒ ⇒ [T]I Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 145. II.7. Processus de raffinement Toute opération spécifiée dans la machine abstraite doit être raffinée avec la même signature dans l’implantation (ou le raffinement) MACHINE IMPLEMENTATION (REFINEMENT) M iM 145 M iM IMPLEMENTS (REFINES) … M … OPERATIONS OPERATIONS y1,..yk opi(x1,..xn)= y1,..yk opi(x1,..xn)= … … END END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 146. Une substitution T raffine une substitution S (notée S⊆T) ssi Les pré conditions sont de plus en plus faibles : EtatsPre(S) ⊆ ⊆ ⊆ ⊆ EtatsPre(T) Le déterminisme est de plus en plus grand : PrePost(T) ⊆ ⊆ ⊆ ⊆ PrePost(S) où PrePost(X) représente l’ensemble des couples d’états Pre et Post possibles d’une substitution X II.7. Processus de raffinement 146 Dans une implémentation, PrePost(X) doit être une fonction T raffine S ? S = x>5 | (x:=0 [] x:=x-1) T = x>0 | x:=x-1 T remplit les mêmes services que S en tout point d’exécution prévu par S EtatsPre(S)={6,7,8…} ⊆ ⊆ ⊆ ⊆ EtatsPre(T)={1,2,3…} PrePost(T)={(x,x’)∈ZxZ|x’=x-1} ⊆ ⊆ ⊆ ⊆ PrePost(S)=Zx{0}∪{(x,x’)∈ZxZ|x’=x-1} Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 147. MACHINE EX 1 VARIABLES y INVARIANT y ∈ F(NAT1) INITIALISATION y := Φ OPERATIONS II.7. Processus de raffinement (Exemple) REFINEMENT EX 2 REFINES EX 1 VARIABLES z INVARIANT z = max (y ∪ ∪ ∪ ∪ {0}) INITIALISATION z := 0 147 OPERATIONS entrer (n) = PRE n ∈ NAT1 THEN y := y ∪ {n} END ; m ‹ — maxi = PRE y ≠ Φ THEN m := max (y) END ; END z := 0 OPERATIONS entrer (n) = PRE n ∈ NAT1 THEN z := max ({z, n}) END ; m ‹ — maxi = PRE z ≠ 0 THEN m := z END ; END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 148. À chaque raffinement, on précise, on fait des choix: réduction de l’indéterminisme II.7. Processus de raffinement 148 réduction de l’indéterminisme affaiblissement des préconditions changement de variables explicitation des algorithmes Le dernier raffinement est une implémentation pouvant utiliser des composants logiciels existants (ou développés indépendamment). Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 149. II.7.1. Réduction de l’indéterminisme Soit S = (x := 0) [] (x := x - 1) T = x := x - 1 ⇔ 149 T = x := x - 1 On a [S]I ⇔ [x := 0]I ∧ [x := x - 1]I [T]I ⇔ [x := x - 1]I Donc [S]I ⇒ [T]I. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 150. II.7.2. Affaiblissement des pré conditions Soit S = PRE x > 5 THEN x := x - 1 T = PRE x > 0 THEN x := x - 1 ⇔ 150 T = PRE x > 0 THEN x := x - 1 On a [S]I ⇔ x > 5 ∧ [x := x - 1]I [T]I ⇔ x > 0 ∧ [x := x - 1]I Donc [S]I ⇒ [T]I Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 151. II.7.3. Changement de Variables VARIABLES y VARIABLES sui INVARIANT sui ∈ seq (VALEUR) 151 INVARIANT y ∈ F(NAT1) VARIABLES z INVARIANT z = max (y ∪ {0}) sui ∈ seq (VALEUR) size (sui) ≤ taille_max VARIABLES tab, vrb INVARIANT vrb ∈(0 .. taille_max) ∧ tab ∈ 1 .. taille_max —› VA-LEUR ∧ sui = (1 .. vrb) <| tab Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 152. II.7.4. Expliciter des algorithmes d ‹ — empiler(w) = PRE w ∈ VALEUR THEN d ‹ — empiler(w) = PRE w ∈ VALEUR THEN 152 THEN CHOICE d := ok | | sui := sui ← w OR d := ko END ; THEN IF vrb < taille_max THEN d := ok | | vrb := vrb + 1 | | tab (vrb + 1) := w ELSE d := ko END ; Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 153. Exemple MACHINE EX 1 VARIABLES y INVARIANT y ∈ F(NAT1) INITIALISATION y := Φ OPERATIONS REFINEMENT EX 2 REFINES EX 1 VARIABLES z INVARIANT z = max (y ∪ {0}) INITIALISATION z := 0 OPERATIONS entrer (n) = 153 OPERATIONS entrer (n) = PRE n ∈ NAT1 (P) THEN y := y ∪ ∪ ∪ ∪ {n} (S) END ; m ‹ — maxi PRE y ≠ Φ THEN m := max (y) END ; END entrer (n) = PRE n ∈ NAT1 (Q) THEN z := max ({z, n}) (T) END ; m ‹ — maxi = PRE z ≠ 0 THEN m := z END ; Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 154. II.7.5. L’invariant de collage Il assure la liaison entre les variables abstraites et les variables (plus) concrètes 154 concrètes Il définit la transformation qui permet d’associer à tout état ER de la machine raffinée un état EA de la machine abstraite Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 155. II.8. Les obligations de preuve du raffinement MACHINE Ma … INVARIANT MACHINE Mr … INVARIANT J 155 INVARIANT I INITIALISATION B OPERATIONS P|S J INITIALISATION C OPERATIONS Q|T Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 156. II.8.1. Les obligations de preuve du raffinement (Initialisation) L’initialisation de Mr doit établir qu’il est impossible que l’initialisation de Ma établisse la négation du changement de variable [C] ¬ ¬ ¬ ¬ [B] ¬ ¬ ¬ ¬ J 156 [C] ¬ ¬ ¬ ¬ [B] ¬ ¬ ¬ ¬ J 1. [z := 0] ¬ [ y := Φ] ¬ (z = max (y ∪ {0})) 2. [z := 0] (z = max (Φ ∪ {0})) 3. 0 = 0 Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 157. II.8.2. Obligations de preuve de raffinement d’une opération Si : les valeurs des variables des deux composants (abstrait et raffiné) avant l’opération respectent les invariants I et J Et si : on est dans les conditions P d’exécution de l’opération abstraite Alors : 157 Alors : On doit être dans les conditions Q d’exécution de l’opération raffinée Quelque soit les nouvelles valeurs prises par les variables parmi celles définies par la substitution T de la machine raffinée, elles doivent correspondre par la transformation J à l’une des valeurs définies par la substitution S de la machine abstraite I ∧ ∧ ∧ ∧J∧ ∧ ∧ ∧P => Q∧ ∧ ∧ ∧[T]¬ ¬ ¬ ¬[S]¬ ¬ ¬ ¬J Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 158. II.8.3. Obligations de preuve de raffinement d’une opération Invariant de la spécification Invariant du raffinement Pré-condition de la spécification ⇒ ⇒ ⇒ ⇒ 158 ⇒ ⇒ ⇒ ⇒ Pré-condition du raffinement [Action du raffinement] [Action de la spécification] Changement de variable du raffinement Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 159. Exemple : Obligation de preuve de raffinement de entrer(n) 1. y ∈ ∈ ∈ ∈ F(NAT1) ∧ ∧ ∧ ∧ z = max (y ∪ ∪ ∪ ∪ {0}) ∧ ∧ ∧ ∧ n ∈ ∈ ∈ ∈ NAT1 ⇒ ⇒ ⇒ ⇒ n ∈ ∈ ∈ ∈ NAT1 ∧ ∧ ∧ ∧ [z := max ({z, n})] ¬ ¬ ¬ ¬ [y := y ∪ ∪ ∪ ∪ {n}] ¬ ¬ ¬ ¬ (z = max (y ∪ ∪ ∪ ∪ {0})) ⇒ ⇒ ⇒ ⇒ 159 2. y ∈ ∈ ∈ ∈ F(NAT1) ∧ ∧ ∧ ∧ z = max (y ∪ ∪ ∪ ∪ {0}) ∧ ∧ ∧ ∧ n ∈ ∈ ∈ ∈ NAT1 ⇒ ⇒ ⇒ ⇒ n ∈ ∈ ∈ ∈ NAT1 ∧ ∧ ∧ ∧ [z := max ({z, n})] (z = max (y ∪ ∪ ∪ ∪ {n} ∪ ∪ ∪ ∪ {0})) 3. y ∈ ∈ ∈ ∈ F(NAT1) ∧ ∧ ∧ ∧ z = max (y ∪ ∪ ∪ ∪ {0}) ∧ ∧ ∧ ∧ n ∈ ∈ ∈ ∈ NAT1 ⇒ ⇒ ⇒ ⇒ n ∈ ∈ ∈ ∈ NAT1 ∧ ∧ ∧ ∧ (max ({z, n}) = max (y ∪ ∪ ∪ ∪ {n} ∪ ∪ ∪ ∪ {0})). Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 160. Exemple : Obligation de preuve de raffinement de m←maxi I ∧ ∧ ∧ ∧ J ∧ ∧ ∧ ∧ P Q ∧ ∧ ∧ ∧ [[m := m']T] ¬ ¬ ¬ ¬ [S] ¬ ¬ ¬ ¬ (J ∧ ∧ ∧ ∧ m = m') 1. y ∈ ∈ ∈ ∈ F(NAT1) ∧ ∧ ∧ ∧ z = max (y ∪ ∪ ∪ ∪ {0}) ∧ ∧ ∧ ∧ y ≠ ≠ ≠ ≠ Φ ⇒ ⇒ ⇒ ⇒ 160 ⇒ ⇒ ⇒ ⇒ z ≠ ≠ ≠ ≠ 0 ∧ ∧ ∧ ∧ [m' := z] ¬ ¬ ¬ ¬ [m := max (y)] ¬ ¬ ¬ ¬ (z = max (y ∪ ∪ ∪ ∪ {0}) ∧ ∧ ∧ ∧ m =m') 2. y ∈ ∈ ∈ ∈ F(NAT1) ∧ ∧ ∧ ∧ z = max (y ∪ ∪ ∪ ∪ {0}) ∧ ∧ ∧ ∧ y ≠ ≠ ≠ ≠ Φ ⇒ ⇒ ⇒ ⇒ z ≠ ≠ ≠ ≠ 0 ∧ ∧ ∧ ∧ [m' := z] (z = max (y ∪ ∪ ∪ ∪ {0}) ∧ ∧ ∧ ∧ max (y) = m') 3. y ∈ ∈ ∈ ∈ F(NAT1) ∧ ∧ ∧ ∧ z = max (y ∪ ∪ ∪ ∪ {0}) ∧ ∧ ∧ ∧ y ≠ ≠ ≠ ≠ Φ ⇒ ⇒ ⇒ ⇒ z ≠ ≠ ≠ ≠ 0 ∧ ∧ ∧ ∧ (z = max (y ∪ ∪ ∪ ∪ {0}) ∧ ∧ ∧ ∧ max (y) = z) Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 161. Exemple : Implémentation Pas de variables en propre (on importe des machines) Les opérations sont précises et exécutables séquence, locale, conditionnelle, cas, tant que, appel, 161 séquence, locale, conditionnelle, cas, tant que, appel, affectations limitées Les variables sont importées Les valeurs données aux constantes sont implémentables. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 162. Exemple : Implémentation Exemple MACHINE Mem (init) CONSTRAINT init ∈ ∈ ∈ ∈ NAT VARIABLE v ∈ ∈ ∈ ∈ NAT INITIALISATION v := init IMPLEMENTATION EX 3 REFINES EX 2 IMPORT Mem (0) INVARIANT z = v 162 INITIALISATION v := init OPERATIONS aff (n) = PRE n ∈ ∈ ∈ ∈ NAT THEN v := n END ; r ‹ — lire = BEGIN r := v END ; END z = v OPERATIONS entrer (n) = Var i ∈ ∈ ∈ ∈ IN i ‹ — lire ; IF n ≥ ≥ ≥ ≥ i THEN aff (n) END END m ‹ — maxi = BEGIN m ‹ — lire END END Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 163. II.9. La modularité dans les spécifications B Dans la conception de logiciels de taille importante, la décomposition en plusieurs machines s'impose afin de faciliter la modularité. SEES, USES, 163 USES, INCLUDES, EXTENDS, IMPORTS, REFINES. Ces mécanismes autorisent un développement progressif de la spécification et la séparation des preuves pour chaque machine. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 164. II.9. La modularité dans les spécifications B Deux nouvelles clauses peuvent apparaître dans une implantation : -la clause IMPORTS qui crée des instances concrètes de machines abstraites dans un projet. Les opérations de ces machines importées sont 164 abstraites dans un projet. Les opérations de ces machines importées sont appelées dans les opérations de l’implantation. -la clause VALUES qui permet de donner une valeur aux ensembles abstraits et aux constantes concrètes de l’implantation. - La clause EXTENDS, correspond à la clause IMPORTS dans une implantation alors qu’elle correspond à la clause INCLUDES dans une machine abstraite ou un raffinement. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 165. II.9. La modularité dans les spécifications B Les clauses INCLUDES et IMPORTS servent à partager les fonctionnalités (les opérations) et les données définies dans un autre module B . Ce sont des clauses de liaison dont l'usage est proche de celui fait des 165 Ce sont des clauses de liaison dont l'usage est proche de celui fait des constructions de modularité usuelles des langages de programmation. Leur objectif est de permettre la décomposition d'un problème en se servant des fonctionnalités développées pour des sous problèmes. •les variables concrètes sont visibles; •les variables abstraites ne sont visibles que dans les invariants et •les opérations sont visibles. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 166. II.9. La modularité dans les spécifications B Les liens SEES et USES sont des liens transversaux dans l'arborescence des dépendances d'un projet B. Ils ne sont utilisés que pour consulter les informations des autres composants. Les liens SEES et USES étant des <<courts-circuits>> dans l'arborescence des dépendances, il est nécessaire que les composants soient attachés à cette arborescence par l'utilisation soit du INCLUDES soit du IMPORTS. 166 IMPORTS. Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014
  • 167. Arrêt En Marche Sélection Monnaie Leila Jemni Ben Ayed GLII- Spécification et Vérification de Systèmes - 2014 167 Sélection Distribution Trop Perçu