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

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)
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)
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
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
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. ?
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
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).
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.
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é.
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
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.
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
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.
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
fonctionnement
10
Spécification
Exigences de l’utilisateur : propriétés attendues
et la vérification de systèmes
2014

fonctionnement
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
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
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
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 :
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.
2014

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
2014

La validation permet de
Vérifier si le texte formel traduit bien la
demande informelle faite par celui qui
commande le logiciel
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
2014

Une spécification est une référence
pour la suite du développement
Permet au programmeur de :
18
Permet au programmeur de :
Décider les langages, bibliothèques…
Décider la complexité
Décider la généricité
2014

Définir le quoi pas le comment
Nom
Données en entrée
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
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 :
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
2014

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
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
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.
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
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.
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
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
propriétés
25
elle s’exprime sous la forme de:
F →
→
→
→ ◊
◊
◊
◊ G



(F →
→
→
→ ◊
◊
◊
◊ G)
2014

Atteignabilité
Ces propriétés énoncent qu’une certaine situation
peut être atteinte.
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é.
2014

Equité
énonce que, sous certaines conditions, quelque chose
aura lieu un nombre infini de fois.
Equité faible
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.
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
2014

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
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
2014

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
Caractérisation de la disponibilité (état en service)
Etat = es ⇒ feuA ≠ rouge ∨ feuB ≠ rouge
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
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)
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
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
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.
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.
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.
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é
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
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.
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
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
2014

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
2014

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
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
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
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.
2014

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.
2014

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)
2014

• 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
2014

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
2014

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)
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
2014

Exemple : réservation
MACHINE
reservation
VARIABLES
nbPlacesLibres, capacite
52
INVARIANT
nbPlacesLibres ∈ NAT ∧
capacite∈ NAT ∧
nbPlacesLibres ≤ capacite
END
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
2014

…
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
2014

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
…
OPERATIONS
55
OPERATIONS
…
r ‹ — plus (a, b) =
PRE
a ∈ ENTIER ∧
b ∈ ENTIER ∧
a + b ∈ ENTIER
THEN
r := a + b
END ;
...
2014

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
2014

MACHINE Chaudière
SETS
ETATS = {arm, dsm}
VARIABLES
T, Alarme
INVARIANT
T ∈ NAT ∧
Alarme ∈ ETATS ∧
⇒
57
(T > 130) ⇒ (Alarme = arm)
OPERATIONS
changerT (v) ==
PRE
v ∈ NAT ∧ v ≤ 130
THEN
T := v
END
…
2014

Exemple : reservation
MACHINE
reservation
…
OPERATIONS
58
OPERATIONS
reserver(nbPlaces)=
PRE
nbPlaces ∈ NAT1 ∧
nbPlaces ≤ nbPlacesLibres
THEN
Transformation
END
END
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
2014

Exemple : reservation
reserver(nbPlaces)=
PRE
60
THEN
nbPlacesLibres := nbPlacesLibres-nbPlaces
END
2014

(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)
2014

MACHINE
M
VARIABLES Obligation de preuve pour l’initialisation
V Init ⇒
⇒
⇒
⇒ I
INVARIANT Obligation de preuve pour une opération o
I
62
I
OPERATIONS I ∧
∧
∧
∧ Q ⇒
⇒
⇒
⇒ I après V
u ← O(W) =
PRE
Q
THEN
V
END
END
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
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
2014

Exemple : réservation
MACHINE I ∧
∧
∧
∧ Q ⇒
⇒
⇒
⇒ [V]I
reservation
VARIABLES
INVARIANT
nbPlacesLibres ∈ NAT ∧
capacite∈ NAT ∧
I
64
capacite∈ NAT ∧
nbPlacesLibres ≤ capacite
OPERATIONS
reserver(nbPlaces)=
PRE
THEN
nbPlacesLibres := nbPlacesLibres-nbPlaces
END
END ```
I
Q
V
2014

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
2014

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
66
((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
2014

Caractérisation de l’état hors service
Etat = hs ⇔ feuA = jaune ∧ feuB = jaune
Caractérisation de l’état en service
⇒
67
⇒
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
2014

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)
2014

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
2014

Exemple : Controleur de feux
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
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
2014

OPERATIONS
Réserver
PRE Nb ≠ 0
THEN
Nb := Nb –1
72
END ;
Libérer
PRE Nb ≠ Maxi
THEN
Nb := Nb + 1
END ;
END
2014

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
2014

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
2014

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 := ∅
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
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
2014

Substitutions multiples
Choix borné
78
Substitution gardée
Substitution vide
Choix non borné.
2014

79
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
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)
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
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
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
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)
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
2014

II.5.3. Substitutions gardée
Syntaxe
IF P THEN S END [P ⇒
⇒
⇒
⇒ S]
⇒
⇒
⇒
⇒ ⇒
⇒
⇒
⇒
87
⇒
⇒
⇒
⇒
Sémantique
[P ⇒
⇒
⇒
⇒ S]I P ⇒
⇒
⇒
⇒ [S]I
2014

II.5.3. Substitutions gardée
Exemple
IF v > 130 THEN
T := v | | Alarm := arm
else
88
else
T := v
END
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)
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
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
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)
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
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)
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 ∧
MACHINE Chaudiere
SETS
ETATS = {arm, dsm}
VARIABLES
T, Alarme
INVARIANT
95
((T > 130) ⇒ (Alarme = arm)))
Après application de la
substitution, on obtient:
2. T ∈ NAT ∧
((T > 130) ⇒ (Alarme = arm))
∧ v ∈ NAT ∧ v ≤ 130
⇒
(v ∈ NAT ∧
((v > 130) ⇒ (Alarme = arm))).
INVARIANT
T ∈ NAT ∧
(T > 130) ⇒ (Alarme = arm)
OPERATIONS
changerT (v) ==
PRE
v ∈ NAT ∧ v ≤ 130
THEN
T := v
END
…
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 ∧
MACHINE Chaudiere
SETS
ETATS = {arm, dsm}
VARIABLES
T, Alarme
INVARIANT
96
((T > 130) ⇒ (Alarme = arm)))
∧(v > 130 ⇒
[T := v] [alarme := arm]
(T ∈ NAT ∧
((T > 130) ⇒ (Alarme = arm)))
∧
[T :=V][alarme := arm]
(T ∈ NAT ∧
((T > 130) ⇒ (Alarme = arm)))
INVARIANT
T ∈ NAT ∧
(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
…
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
2014

II.6.1. Logique : connecteurs
ET ∧ (ASCII : &)
OU ∨ (ASCII : or)
NON ¬ (ASCII : not)
98
NON ¬ (ASCII : not)
SI-ALORS ⇒
⇒
⇒
⇒ (ASCII : =>)
EQUIV. ⇔ (ASCII : <=>)
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)
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
{}
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.
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
a|->b ≠ b|->a
P(E) (POW en ASCII)
Négation des prédicats par le symbole /
∉ devient /: en ASCII
2014

II.6.2. Ensemble : les prédicats
x ∈ E (: en ASCII)
E1 ⊆ E2 (<: en ASCII, ⊂ notée <<:)
E1 x E2 (* en ASCII)
103
a|->b ≠ b|->a
P(E) (POW en ASCII)
Négation des prédicats par le symbole /
∉ devient /: en ASCII
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
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
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
2014

vocabulaire
r est un sous-ensemble du produit
cartésien D x A de deux ensembles
106
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
2014

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)}
2014

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}
2014

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)
{(d,a) | (d,a)∈r ∧ a ∈ B} ;
l’anti-restriction : E r (<<| en ASCII)
{(d,a) | (d,a)∈r ∧ d∉E}
l’anti-co-restriction : r B (|>> en ASCII)
{(d,a) | (d,a)∈r ∧ a∉B}
2014

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))}
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
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)
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
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
2014

Opérateurs sur les ensembles
115
2014

Opérateurs sur les relations
116
2014

117
2014

118
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
2014

modélisation
120
2014

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é
. . .
2014

modélisation d’un ascenseur
122
2014

Exemple : Distributeur de
carnets de timbres
123
2014

carnets de timbres
124
2014

carnets de timbres
125
2014

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
2014

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
2014

modélisation
Solution 2
Moins d’indéterminisme
128
2014

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.
2014

Exemple : Formalisation
Soit les ensembles abstraits UTILISATEUR et NUM
Connecte ⊆ UTILISATEUR
NonConnecte = UTILISATEUR – Connecte
130
NonConnecte = UTILISATEUR – Connecte
aPournumcompte ∈ Connecte --> NUM
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
bâtiment au plus.
D1. Le système gère le passage des personnes d'un bâtiment
à l'autre.
bâtiment au moins.
P5. Toute personne se trouvant dans un bâtiment est bien
autorisée à y être.
2014

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.
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.
2014

aux bâtiments (specification initiale,
abstraite)
134
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}
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
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
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]
2014

Opérations sur les sequences
Ajout d’un élément à gauche a → S /
a ∈E et S ∈ Seq(E)
⇒
⇒
⇒
⇒
;
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 → [ ])
;
2014

Opérations sur les séquences
size : longueur d’une séquence
size ([ ]) = 0 ;
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)
;
2014

Operations sur les séquences
Ajout à droite d’un element : ←
[ ] ← b = b → [ ]
(a → S) ← b = a → (S ← b)
;
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)
;
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 :
:
:
:
;
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)
;
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
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
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
2014

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
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
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}
2014

MACHINE EX 1
VARIABLES
y
INVARIANT
y ∈ F(NAT1)
INITIALISATION
y := Φ
OPERATIONS
(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
2014

À chaque raffinement, on précise, on
fait des choix:
réduction de l’indéterminisme
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).
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.
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
2014

II.7.3. Changement de Variables
VARIABLES
y
VARIABLES
sui
INVARIANT
151
INVARIANT
y ∈ F(NAT1)
VARIABLES
z
INVARIANT
z = max (y ∪ {0})
size (sui) ≤ taille_max
VARIABLES
tab, vrb
INVARIANT
vrb ∈(0 .. taille_max) ∧
tab ∈ 1 .. taille_max —› VA-LEUR
∧ sui = (1 .. vrb) <| tab
2014

II.7.4. Expliciter des algorithmes
PRE w ∈ VALEUR
THEN
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 ;
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 ;
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
2014

du raffinement
MACHINE Ma
…
INVARIANT
MACHINE Mr
…
INVARIANT
J
155
INVARIANT
I
INITIALISATION
B
OPERATIONS
P|S
J
INITIALISATION
C
OPERATIONS
Q|T
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
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
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
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})).
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)
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.
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
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.
2014

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.
2014

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.
2014

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.
2014

Arrêt
En Marche
Sélection
Monnaie
2014
167
Sélection
Distribution
Trop Perçu

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

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

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

Plus de MbarkiIsraa

Plus de MbarkiIsraa (18)

Dernier

Dernier (20)

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