Génie Logiciel : Méthode de

Spécification et développement formel

de logiciel
Prof Atsa Etoundi Roger
Maître de conférences
 Développement de logiciels

Nature des logiciels :

– séquentiels, parallèles,
– flot de données, transactionnels,
– autonomes, centralisés,
– répartis, réactifs, temps-réels
– embarqués, protocoles, mobiles,
– etc
 Cycles de vie
Ils ont été pendant longtemps le support
méthodologique du développement du logiciel.
Les plus représentatifs de ces cycles de vie :
– Cycle en V,
– Cycle en cascade,
– Cycle de Balzer
 Intérêts et limites des méthodes semi-
formelles
– SADT (Structural Analysis and design technique),
– SA-RT (Structiral Analysis and Reuse Technique),
– SSADM (Structured Systems Analysis and Design Method), . . .
– JSD-JSP (Jackson System Development- Jackson Structured Programming),
– Merise, Axial, . . .
– OOA (Objet Oriented Analysis), OMT (Object Modelling Technique), . . .
– UML (Unified Modelling Language)

Ces méthodes permettent de réaliser une analyse parfaite du problème. La contribution de ces méthodes
est certes positive même si elle reste insuffisante. Elles permettent de dégrossir le problèmes. La
sémantique des modèles conçus reste informelle et mal définie, il y a un manque de rigueur
mathématique, analyse profonde du problème très difficile et couteuse. Par conséquent, il est difficile
prouver certaines propriétés du système. Elles ne garantissent pas la sécurité du système.

En bref, ces méthodes ont une sémantique ou de règles de validation incomplètes. Mais il est impossible
de raisonner/analyser formellement sur le système en vue. Il peut ainsi y avoir des ambigüités, . . .;
ceci constitue des sources de BUG dans le système.
 Méthode formelle
Une méthode formelle utilise les mathématiques pour laisser
moins de place aux intuitions et aux erreurs. Elle dispose
des entités suivantes:
1. Un langage qui est un moyen pour exprimer et concevoir
un système, la nature de ce langage peut être symbolique,
graphique etc.
2. Une sémantique qui donne la signification des éléments
du langage
3. Des règles de validation qui permettent d’exprimer les
propriétés désirées du système;, et d’utiliser la
sémantique du système pour validation. Les règles doivent
laisser moins de place aux erreurs et à l’intuition.
 Spécification formelle

La spécification formelle est une expression dans un

langage formel du quoi d’un système à
développer.
– Résultat de la phase d’analyse
– Plusieurs formes possibles selon la nature du
système
Cette expression est faite dans un langage ou un
formalisme de spécification formelle comme la
logique, les langages de spécification
algébriques, algèbres de processus, etc
 Démarche de spécification
Dans la mise en place d’un système, l’on peut s’interesser aux aspects
données ou bien aux aspects opérations.

A ce titre, deux grandes écoles de spécification formelle et de

méthodes formelles ont vu le jour.
– Les données d’un système permettent de décrire les états du système
– les opérations du système permettent de décrire son fonctionnement ou
son comportement par des axiomes

Il convient de distinguer :
– les opérations exprimant le comportement d’un système
– des opérations caractérisant les données du système.

Les premières opèrent sur les données du système, alors que les dernières
permettent de construire et exploiter les données du système.
 Démarche de spécification
Il y a un troisième paradigme qui semble être transversal. C’est le
paradigme des processus (les algèbres de processus). Dans ce
paradigme des processus les systèmes sont décrits par les
équations exprimant leur comportement ou leurs états.

Les principales algèbres de processus à la base des autres

formalismes sont :
– CSP: Communication Sequetial Processes défini par C.A.R Hoare
en 1978
– CCS: Calculus of Communicating Systems defini par Milner en
1980
– ACP: Algebra of Communicating Processes defini par Jan
Bergstra en 1984
 Eléments de classification
La principale classification des approches consiste à distinguer deux
principales approches de spécifications formelles et de méthodes
formelles :
- l'approche opérationnelle : orientée modèle ou état
- et l'approche axiomatique : orientée propriétés.

D'autres classifications (de bas niveau) sont rencontrées :

(a) classification basée sur les paradigmes :
- données : (data-oriented) + états, + opérations,
- processus : process-oriented
- Hybride

(b) une classification basée sur les langages :

- les langages généraux : Z, spécification algébriques, HOL, PVS, etc
- les langages orientés « contrôle‘ »: CCS, CSP, SIGNAL, ESTEREL,
LUSTRE, etc
 Spécifications orientées états
(model-based approach ou state-based approach)
Dans cette approche, on privilégie les données du système, on s’intéresse à l’état du
système.

Principe
Une spécification permet de construire, à l’aide des concepts de base fournis, un
modèle du système (logiciel) à développer.

Ce modèle doit avoir les propriétés du système. On peut ensuite raisonner sur le
fonctionnement du système en utilisant le modèle.

Concepts de base
On utilise essentiellement les mathématiques discrètes (Théorie des ensembles), et la
Logique.

Quelques exemples de formalismes

• Z, VDM, B etc pour les systèmes séquentiels,
• Réseaux de Pétri, CCS, CSP, Unity, etc pour les systèmes concurrents et distribués,
avec CCS et CSP relèvant du paradigme des processus.
 Spécifications orientées propriétés ou
axiomatiques

(axiomatic approach, algebraic approach, operation oriented)

Principe
La spécification permet de construire une axiomatisation qui fournit
les propriétés (comportementales) du système à développer en
utilisant les concepts de base cités ci-après.

Concepts de base
Logique, Algèbre, Domaines définis inductivement.

Exemples de formalisme
les langages de spécification algébriques : LPG, ASL, ACT ONE, CLEAR,
OBJ, PLUSS, LARCH, CASL... pour les systèmes séquentiels
les algèbres de processus : LOTOS (combine ACT ONE et CCS,
CSP) pour les systèmes concurrents.
 Spécifications hybrides (hybrid approach)
Principe
La spécification permet de compléter une axiomatisation par un
modèle de données ou bien de compléter un modèle de données
par une axiomatisation.
Concepts de base
Concepts de base des approches orientées état et propriétés.

Exemples de formalisme
– RAISE (Combine VDM et CSP)
– VDM-SL et Réseaux de Petri,
– Extended LOTOS(combine ACT ONE, CCS et CSP),
– ZCCS (combine Z et CCS),
–...
 Méthodes de développement formel

Pour résumer l’essentiel des idées dans le processus de mise en place d’un
logiciel reprenons en cœur le slogan :
« Prouver c’est programmer et programmer c’est prouver ! »
La deuxième façon de résumer est de considérer l’interprétation suivante de
l’isomorphisme de Curry-Howard:
Axiomes
Preuve Théorèmes est équivalent à Développement Spécifications
Programmations
Il y a plusieurs approches dans les méthodes formelles :
- l'approche opérationnelle :
le développement est basé sur la description d'un système par un
modèle qui a les propriétés du système.
Vérification des propriétés sur le modèle.
Des raffinements corrects successifs sont effectués sur le modèle.
- l'approche axiomatique :
le développement est basé sur l'axiomatisation qui décrit le
comportement du système.
Des vérifications des propriétés sont effectuées, raffinements
possibles.
- l'approche hybride Intégration de méthodes formelles
 Quelques définitions
Méthode formelle =
(1)Langage formel (syntaxe précise et sémantique précise) et (2) Système de preuve ou
de raisonnement formel.
Développement formel = transformation systématique des spécifications en
programmes en utilisant des lois préséniles.

Modelisation :
Hoare : A scientific theory is formalised as a mathematical model of reality, from
which can be deduced or calculated the observable properties and of a well-defined
class of processes in the physical world.

Il y a deux principales notions de modèles (en informatique).

1. Modèle = une approximation de la réalité par une structure mathématique.
Un objet O est modèle d'une réalité R, si O permet de répondre aux questions que l'on
se pose sur R.
En Mathématique, Physique, ... système d’équations portant sur des grandeurs
(masses, énergie, ...) ou des lois hypothétiques.
 Quelques définitions (suiv)

2. (Logique, théorie des modèles) Un modèle d'une théorie T est une structure dans
laquelle les axiomes de T sont valides.
Une structure S est modèle d'une théorie T, ou bien S satisfait T si toute formule de T
est satisfaite dans S.

La réalité est un modèle d'une théorie !

Théorie (du 1er ordre) = tout ensemble de formules logiques (du 1er ordre) dans un
langage donnée (précisément défini).
Modèle comme interprétation d'une spécification cation - une algèbre comme modèle
d'une spécification cation algébrique (axiomatisation).

Ces deux utilisations de modèle se retrouvent dans les approches orientée modèle (ou
état) et orientée propriétés.
Dans le langage courant,
- modèle = (archétype), ce qui sert ou doit servir d'objet d'imitation pour reproduire
quelque chose.
- modèle = (paradigme), modèle de déclinaison, de conjugaison, etc
- modèle = (référence), . . .
 Exemples de théories
La théorie des ensembles : elle est basée sur un
ensemble d'axiomes.
Les objets de cette théorie sont appelés
ensembles.
La classe des ensembles est appelée univers.
Les axiomes de la théorie des ensembles (de
Zermelo+Fraenkel) sont les suivants :
- Axiome de l'ensemble vide : il existe un ensemble qui ne contient aucun élément :
c'est l'ensemble vide.
- Axiome d'extensionalité : deux ensembles sont égaux si et seulement si ils
contiennent exactement les mêmes éléments

- Axiome de l'union : l'une union d'ensembles est un ensemble { Axiome de

l'ensemble des parties :les parties d'un ensembles forment une partie

- Axiome du schéma de remplacement (Fraenkel, 1922) : Lorsqu'on définit une

fonction par des formules de la théorie des ensembles, alors les éléments pour
lesquels cette fonction vérifie une certaine propriété forment encore un ensemble.

De plus, on ajoute à ces axiomes, l'axiome de l'infini: il existe un ordinal infini.

ZFC = ZF + axiome du choix

- Axiome du choix : Soit une famille d'ensemble disjoints, si on considère un élément
de chaque ensemble de la famille, alors on en forme un ensemble.
 Définitions (suiv)
Méthode semi formelle =
 Langage graphique [+ formel] (syntaxe précise
et sémantique non précise) et
 Outils d'analyse divers.
 Combinaison de langages /méthodes
/techniques n'ayant pas tous une sémantique
précise.
Exemples : JSD, OMT, OOX, UML
 Définitions (suiv)
Méthode formelle =
 Langage formel (syntaxe précise et sémantique
précise) et
 Système de preuve ou de raisonnement formel.
Exemples : CCS, CSP, HOL, Z, B

Développement formel =
 transformation systématique des spécifications
en programmes en utilisant des lois prédéfinies.
Exemples : Synthèse, Raffinement
 Quelques définitions (suite)

Vérification : montrer que le système (S) est

correct par rapport à des propriétés(P)
S P
Validation : montrer que le système est correct
par rapport aux spécifications informelles
S S informelle
Raisonnement formel : Consiste à appliquer un
système formel à une spécification.
Exemples de raisonnement formel
- Raffinement de spécification,
- vérification des propriétés d'un système,
- validation par vérification,
- preuve de théorèmes (theorem proving),
- analyse d'un système (représenté par machine à
états) par rapport à des propriétés (model
checking).
 La logique est le fondement des approches
formelles
Logique du premier ordre
Règles d’inférence du calcul propositionnel
Logique des prédicats
Formation des prédicats
 Approches dans les méthodes
formelles
– l’approche opérationnelle : le développement
est basé sur la description d’un système par
un modèle qui a les propriétés du système.

– l’approche axiomatique : le développement est

basé sur l’axiomatisation qui décrit le
comportement du système

– l’approche hybride
 Développement formel
• Développement formel de logiciel
= Transformation systématique d’un modèle
mathématique en code exécutable
= Transformation de l’abstrait en concret
= Passage des structures mathématiques aux
structures
informatiques
= Raffinement jusqu’au code dans un langage de
programmation
 Nouveau cycle de vie

Avec les méthodes formelles les cycles de vie classique ne marchent plus. Il
faut les adapter.
Le cycle de vie de Balzer représente la nouvelle famille de cycles de vie
adaptés au développement formel (ou rigoureux !).
Présentation synthétique du
développement formel
Développement correct de logiciels:
Activité de développement formel
Développement de systèmes
informatiques
 Aperçu des formalismes et méthodes
de l’approche orientée modèle
Caractérisation des méthodes : un aperçu
Plusieurs caractéristiques peuvent être utilisées pour
caractériser les méthodes.
Considérons les caractéristiques syntaxiques et
sémantiques :
- L'aspect syntaxique → les moyens de description des
spécifications formelles
-L'aspect sémantique → les possibilités de description
sémantique associées aux spécifications
 Eléments d'analyse
Quelles méthodes pour quels systèmes ?

Le terme méthode désigne à la fois les formalismes ou les techniques.

Selon les systèmes à développer →une famille de techniques,
méthodes, outils.

- C'est un fait pour les spécialistes des méthodes formelles.

- Malheureusement, la pratique est loin de cet état de fait.
- pour les non spécialistes, ce problème du choix de la (des)
bonne(s) méthode(s) n'est pas évident.

→ C'est aux spécialistes de guider le développement de logiciels

 Eléments d'analyse
Quels systèmes ?
Les systèmes complexes présentent plusieurs facettes → multifacettes.
 Irréaliste : Développer formellement un système avec une
méthode (spécification, conception, vérification, simulation,
implémentation, tests).

La nature des systèmes complexes oblige le développeur à utiliser

les formalismes, techniques et outils appropriés au bon moment

 Nécessité : Intégration de plusieurs approches pour le

développement des systèmes informatiques : intégration de
méthodes.
 Méthodes en génie logiciel

Méthode formelle =
Langage de spécification
 Système formel (de raisonnement)
 Langage de spécification
 Logique, théorie des ensembles : langage de données
 Systèmes de transition, algèbres de processus : langage de
comportement
 Système formel (de raisonnement)
 Systèmes de type
 Prouveur de théorèmes (theorem proving)
 Vérificateur de modèles (model checking)
 Développement formel
Développement formel de logiciel =
Transformation systématique d'un modèle mathématique
exécutable.
= Transformation de l'abstrait en concret
= Passage des structures mathématiques aux structures
informatiques
= Raffinement jusqu'au code dans un langage de
programmation.

Exemple : B = Méthode formelle

+ théorie de raffinement (de machines abstraites)
méthode de développement formel
Aperçu des formalismes et méthodes
de l’approche orientée modèle
Aperçu des formalismes et méthodes
de l’approche orientée modèle (suiv)
 Aperçu de méthodes formelles
• Methode B
 Développer des logiciels à partir de
spécifications formelles : la méthode B

• comment passer du quoi (la spécification) au

comment (le code associé) par raffinements
successifs : conception et codage
• L'objectif de ce cours est d'avoir une ouverture
sur le développement de logiciels par
spécifications formelles
B : Méthode formelle
+ théorie de raffinement (de machines abstraites)
⇒ méthode de développement formel
 La méthode B : le raffinage
• Raffiner consiste à reformuler les données et opérations d'une
machine abstraite à l'aide de données et opérations plus proches de
l'implémentation 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 boucles
• 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.
 La notion de machine abstraite

• En B
– On spécifie
– On prouve
– On développe
– On code
Une (ou plusieurs) machine abstraite
• Cette notion est proche
– Type abstrait, Module, Classe, Composant
 Notion d’états et d’espaces d’états
• Observons une variable dans un modèle logique ;
• Elle peut avoir différentes valeurs au cours du temps, ou
encore plusieurs états au cours du temps ;
• Par exemple une variable entière I : on peut observer
logiquement I = 2, I = 6, I = 0 , ··· à condition que I soit
modifiée... ;
• Suite à une modification I change d’états ;
• Le changement d’état peut être modélisé par une action
qui substitue une nouvelle valeur à celle de la variable ;
• De façon générale, pour I entier, il y a potentiellement tout
l’espace des entiers comme états que I peut avoir : on parle
d’espace d’états.
• On généralise à plusieurs variables hI, Ji, hV1, V2, V4, ...i
 Approche de développement en B
• L’approches B est dite : orientées modèle (à états)
– Décrire un espace d’états
– Décrire des opérations qui parcourent cet espace
– Système de transition entre états
 Approche de spécification
• Un nuplet de variables décrit un état
(mode = jour, lumiere = eteint, temp = 20)
• Un prédicat (sur les variables) décrit un espace
d’états
lumiere = eteint ∧ mode = jour ∧ temp > 12
• Une opération qui affecte les variables change
l’état
mode := jour
• Spécifier en B = Modéliser, décrire un système de
transition (avec une approche logique)
Machine abstraite
Machine Abstraite
Machine abstraite
Machine abstraite
Machine abstraite
Machine abstraite: Exemple de
régulation de la lumière
Machine abstraite : offre des
opérations
 Interface des operations

(avec/sans paramètres entrée/sortie)

Aucun paramètre : nomOperation = ...
Que des paramètres d’entrée : nomOperation(p1, p2, ··· ) = ...
Paramètres de sortie r1, r2, ··· <— nomOperation = ...
Entrée et sortie r1, r2, ··· <— nomOperation(p1, p2, ··· ) = ...
 Système de régulation de lumière
Etude
Exigences :
• La lumière ne doit pas être allumée s’il fait jour
• La température ne doit pas dépasser 29 degrés
quand il fait jour
etc
⇒ trouver et formaliser les propriétés dans
l’invariant.
 La machine abstraite
Op
Op
Op
D
Op
Op

Op Op
• Un en-tête (nom)
• Des données cachées
• Des opérations visibles d’accès à la machine
 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
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
 L’en-tête

• Un nom + optionnellement des paramètres

pour la généricité

MACHINE MACHINE MACHINE MACHINE

calculatrice reservation pile(ELEMENT) variable (TYPE)
END END END END
 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
– 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 de
comparateurs arithmétiques.
 Exemple : réservation

MACHINE
reservation
VARIABLES
nbPlacesLibres, capacite
INVARIANT
nbPlacesLibres  NAT 
capacite NAT 
nbPlacesLibres ≤ capacite
END
 Exemple : variable

MACHINE
variable (TYPE)
VARIABLES
valeur
INVARIANT
valeur  TYPE
END
 Les opérations
• Une en-tête (la signature)
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 nominales 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 valeur aux paramètres
de sortie
 Exemple : reserver

MACHINE
reservation
…

OPERATIONS
reserver(nbPlaces)=
PRE
nbPlaces  NAT1 
nbPlaces ≤ nbPlacesLibres
THEN
Définition de l’opération
END
END
 Exemple : opérations de variable

MACHINE
variable (TYPE)
…
OPERATIONS

v<--obtenir = Définition de l’opération ;

affecter(v) =
PRE
v TYPE
THEN
Définition de l’opération
END

END
 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 :=
– 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ée par
des substitutions indéterministes
 Exemple : reserver

reserver(nbPlaces)=
PRE
nbPlaces  NAT1 
nbPlaces ≤ nbPlacesLibres
THEN
nbPlacesLibres := nbPlacesLibres-nbPlaces
END
 Exemple : affecter

affecter(v)=
PRE
v TYPE
THEN
valeur := v
END
 Preuve de cohérence

• La dernière étape de la spécification consiste à

prouver la cohérence de chaque machine abstraite
• 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 dans des conditions
nominales
• la pré-condition P d’appel est supposée vérifiée
– alors sa transformation S amène la machine dans un état
correct
• un état qui satisfait l’invariant I
 Deux étapes de preuve

1. Calcul de [S]I la plus faible pré-condition

– Condition minimale garantissant que l’état de la machine
après l’opération respecte l’invariant
– On applique simplement la substitution S à la formule I
2. On prouve que les conditions initiales (invariant et
pré-condition) impliquent cette plus faible pré-
condition
– Pour chaque opération, la formule dont il faut établir la
validité est donc de la forme
I  P  [S]I
 Illustration sur reserver
MACHINE
reservation
VARIABLES
nbPlacesLibres, capacite
INVARIANT
nbPlacesLibres  NAT 
capacite NAT 
nbPlacesLibres ≤ capacite
OPERATIONS
reserver(nbPlaces)=
PRE
nbPlaces  NAT1 
nbPlaces ≤ nbPlacesLibres
THEN
nbPlacesLibres := nbPlacesLibres-nbPlaces
END
END
 B en pratique

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 ;
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
 B : le principe de la méthode
L’invariant d’un système (ou logiciel)
on modélise l’espace des états corrects par une propriété (une
conjonction de propriétés).
Tant que le système est dans un de ces états, il est fonctionne
bien ; il faut l’y maintenir !
Donc il faut éviter qu’il sorte de cet espace d’états.
Donc s’assurer de l’état résultant, avant de faire les
changements
d’états.
Exemples : trajectoire d’un robot (éviter les points de
collision).
* Les opérations qui changent l’état ont une précondition.
Originalité de B : tout en logique (données et opérations)
• Espace d’état : Invariant : Prédicat : P(x, y, z)
Un état : une valuation des variables
x := vx y := vy z := vz dans P(x, y, z)
⇒ Substitution logique
• Une opération : transforme un état (correct) en un
autre état.
Transformer un état = transformer le prédicat (invariant)
Opération = transformateur de prédicat = Substitution
Effets autre que affectation ⇒ substitutions généralisées
 B : la pratique
• Quelques règles de spécification en B
• Une opération d’une machine ne peut pas appeler une autre
opération de la même machine (violation de la PRE) ;
• On ne peut pas (de l’extérieur) appeler en parallèle, deux
opérations d’une même machine (par exemple : incr k decr) ;
• Une machine doit comporter des opérations auxilliaires pour tester
les préconditions des principales opérations fournies ;
• L’appelant d’une opération doit vérifier ses préconditions avant
l’appel ("On ne doit pas diviser par 0") ;
• Lors des raffinements, on affaiblit les PREconditions jusqu’à les faire
disparaitre (ce n’est pas le cas en B événementiel) ;
• ···
 B : les fondements
• Logique du premier ordre
• Théorie des ensembles (+ types)
• Théorie des substitutions généralisées
• Théorie du raffinement
• et une bonne dose de : abstraction et
composition
 B : Outils de Génie logiciel
• Modularité :Machine abstraite, Raffinement,
Implantation
• Architecture des applications complexes :
clauses SEES, USES, INCLUDES, IMPORTS, etc
• Atelier de génie logiciel : Editeurs, analyseurs,
prouveurs, etc
Analyse et développement B
Structure d’un développement en B
+ B : Approche développement correct → preuves
+ B : Cadre unique pour :
Analyse
Spécification
Conception
Développement
+ B: Raffinements successifs du modèle abstrait au
code.
(Autres) Approches : développement, test à
postériori → tests
 B - Langage des données - ensembles
et typage
• Ensembles prédéfinis (statut de type) BOOL,
CHAR, INTEGER (Z), NAT (N), NAT1 (N*) ,
STRING
• Produit cartésien E × F
• Ensemble des sous-ensembles P(E) noté
POW(E)
 B - Langage des données
A l’aide du langage des données
• On modélise l’état d’un système avec les données
qui le caractérisent
• On explicite les propriétés invariantes d’un
système
Modélisation de l’état :
• Abstraction, modélisation (ensembles abstraits,
relations, fonctions, ...)
• Propriétés logiques, algébriques.
 B - Langage des données
• Lorsqu’on modélise un système (par l’ensemble de ces
états) puis
• qu’on explicite ses (bonnes) propriétés, on s’assure
après que le système ne parcourent que l’ensemble
des états qui respectent es propriétés : c’est la
cohérence du système.
• Pour montrer qu’il est possible d’avoir des états
satisfaisant les propriétés énoncées, on exhibe au
moins un état (l’état initial).
• Le système spécifié est correct si après chacune de ses
opérations, l’état obtenu est un état respectant les
propriétés invariantes.
B - Langage des données
B - Langage des données
B - Langage des données
Union généralisée
Union quantifiée
Intersection généralisée
Intersection quantifiée
Les relations
Les relations (suite)
Les fonctions
Les séquences
Les séquences (suite)
 Concepts de base pour la partie
dynamique:
Les plus faibles préconditions
• Contexte : Logique de Hoare/Floyd/Dijkstra triplet de Hoare
• (Etat, espace d’état, commandes, exécution, triplet de
Hoare)
• {P} S {R}
• S une commande et R un prédicat décrivant le résultat de S.
• wp(S, R), prédicat qui représente :
• l’ensemble de tous les états | exécution de S commençant
par un
• d’entre eux se termine en un temps fini dans un état
satisfaisant R,
• wp(S, R) est la plus faible précondition de S par rapport à R.
 B : Substitutions généralisées -
Axiomes
• Généralisation de la substitution simple de la logique
classique
• (pour modéliser des comportements d’opérations).
• Soit R un prédicat à etablir, la sémantique des
substitutions
• généralisées est définie par le transformateur de
prédicat.
• Substitution simple S
• sémantique [S]R se lit : S établit R
• Substitution multiple x, y := E, F
• Sémantique [x, y := E, F]R
B : Substitutions généralisées - Jeu de
base
Non déterminisme - Substitutions
B - Langage des substitutions
généralisées
B - Langage des substitutions
généralisées
B - Langage des substitutions
généralisées
B - Langage des substitutions
généralisées
Extension du jeu de base : non-
déterminisme
Extension du jeu de base : non-
déterminisme
B - Langage des substitutions
généralisées
Structure des applications en B