Utilisation des mthodes formelles

pour la conception
dun systme mcatronique
Chrysostome Baskiotis, EISTI
cb@eisti.fr

Table des matires

1

Introduction

Prsentation des mthodes formelles

Caractristiques des mthodes formelles

Composants des mthodes formelles

Raffinement

Exemple : utilisation de la mthode B

6.1 tat . . . . . . . . . . . . . . . . .
6.2 vnements . . . . . . . . . . . .
6.3 Permanence des invariants . . . .
6.4 Initialisation . . . . . . . . . . . .
6.5 Blocage . . . . . . . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

7
8
9
9
12
12

Raffinement : rampe une voie

7.1 tat . . . . . . . . . . . . . .
7.2 vnements . . . . . . . . .
7.3 Initialisation . . . . . . . . .
7.4 Blocage . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

13
13
14
18
18

.
.
.
.

.
.
.
.

.
.
.
.

Conclusion

19

Rfrences

20

A Code du modle abstrait m0_parking

21

B Code du raffinement m1_rampe

22

Introduction

Un systme mcatronique, qui met en contribution des disciplines aussi

varies que la mcanique, llectronique, linformatique et lautomatique, est
un systme complexe. Lobjectif poursuivi actuellement est de pouvoir intgrer
les diffrentes disciplines par lunification du processus de conception, ce qui
nest pas facile cause de la diffrence des outils employs. Ainsi
en CAO/PAO on utilisera des outils spcialiss comme, par exemple Catia ;
en modlisation physique, on utilisera par exemple Modelica, et
en commande on pourrait utiliser Matlab/Simulink ou Scilab/Scicos.
tant donn que les systmes mcatroniques contiennent une partie logicielle importante, nous allons considrer le systme mcatronique sous laspect dun systme complexe dinformation. La premire exigence pour pouvoir
construire un tel systme est davoir des mthodes de spcification, de conception et de vrification efficaces, cest--dire capables de prendre en compte et
de gerer la complexit du systme.
Pour situer les endroits o peuvent se trouver dventuels problmes de
dveloppement, nous allons considrer le cycle de vie dun produit. Indpendamment du modle utilis pour dcrire le cycle de vie (linaire, en V ou en
spirale), on distingue, avant la phase de ralisation, la phase de la redaction du
cahier des charges, la phase de spcification et les phases de conceptions gnrale et dtaille. La phase suivante qui est la ralisation, utilise les rsultats de
la phase de la conception dtaille du systme et qui consistent en la dcomposition de chaque module en fonctions simples et au codage de ces fonctions. Si
dans les phases suivantes des tests et de validation on constate des erreurs, le
plus souvent ces erreurs proviennent des insuffisances pendant les phases de
la spcification et de la conception. Il faut donc porter notre attention principalement ces deux phases et utiliser pour la spcification et la conception des
mthodes efficaces.
Il est important avant de proposer des mthodes pour pallier ces inconvnients, dexaminer lorigine des erreurs. Les disciplines traditionnelles dingnierie sappuient sur une modlisation mathmatique qui permet dtablir
les caractristiques et les proprits des systmes. En ingnierie logicielle la
dmarche dlaboration dun systme est fonde sur la technique essai et erreur . Ainsi les erreurs de conception qui peuvent surgir dans un systme sont
dues une mauvaise anticipation des interactions entre les modules du systme ou entre le systme et son environnement. Il va de soi que plus le nombre
de modules et des interactions crot, cest--dire plus le systme devient complexe, plus les possibilits derreur augmentent.
Une famille des mthodes qui permettent dviter ce type derreurs sont les
mthodes formelles, qui sont dveloppes sur la base de modlisation mathmatique et de la logique formelle. Elles assurent la construction dun systme qui
est
correct et ceci peut tre prouv mathmatiquement ;
sr, et donc il pourra tre un systme critique ;
2

 portable, cest--dire indpendant de la plateforme et du langage de dveloppement, et

volutif, ce qui fait que le risque dobsolence est reduit.
En somme lintrt des mthodes formelles est la possibilit de vrifier de
manire rigoureuse les proprits dun modle formel.
Lobjectif de cet expos est de prsenter une mthode formelle laide dun
exemple de systme mcatronique simple.
Le plan de lexpos est le suivant :
Prsentation des mthodes formelles.
Caractristiques des mthodes formelles.
Composants des mthodes formelles
Raffinement
Exemple : utilisation de la mthode B

Prsentation des mthodes formelles

Une mthode formelle est un ensemble de techniques et outils fonds sur

les mathmatiques discrtes et la logique formelle et utiliss pour la spcification, la conception et la ralisation de systmes dinformation. Elle est dote
dun langage des spcifications avec une smantique rigoureuse et elle permet
de faire des dmonstrations mathmatiques, assistes par ordinateur, des proprits du systme en vue de vrifier le comportement du systme.
Dans les mthodes formelles la logique joue un rle analogue celui jou
par les mathmatiques dautres disciplines de lingnierie. Par exemple en
automatique, la modlisation mathmatique dun systme, permet, laide
dutilisation de lanalyse mathmatique (transforme de Laplace, systmes dquations diffrentielles, ...) de simuler le comportement du systme et, donc,
de prvoir son volution. De la mme faon en ingnierie logicielle, grce
la modlisation formelle (logique) du systme, on peut prvoir ses proprits
logiques par lintermdiaire des calculs logiques. En effet, si on traduit un systme en propositions logiques, lexistence dun modle (au sens de la logique)
signifie que lensemble des propositions se vrifie. On peut ainsi prouver, par
des calculs logiques, que le systme respecte les spcifications. Notons que les
calculs logiques sont, dans une large part, automatiss.
La modlisation formelle dun systme consiste en la traduction dun systme dcrit sous forme informelle (non mathmatique, par exemple texte en
franais, scenarios, diagrammes des flux des donnes, ...) en spcification formelle par lutilisation dun langage formel. Le rsultat est une description du
systme qui possde un haut niveau de prcision logique. Nous pouvons ainsi
tester la compltude et la consistance des exigences telles quelles taient formules partir du cahier des charges. Ainsi les mthodes formelles permettent
essentiellement trois choses :
choisir le meilleur modle (en termes de satisfaction des exigences, de
simplicit ou de sret de fonctionnement) pour le systme ;

 faciliter la communication entre plusieurs quipes travaillant sur le mme

projet, et
vrifier la satisfaction des standards par le modle en vue dune certification.
Les mthodes formelles peuvent tre appliques chaque phase de dveloppement du cycle de vie : spcifications, conception gnrale ou dtaille
et codage. Nanmoins il est plus profitable si on les applique chacune de
ces phases de dveloppement. Car, dans ce cas, on peut utiliser les mthodes
formelles pour avoir une traabilit entre les diffrentes phases de dveloppement. En effet, quand on passe dune phase de dveloppement une autre,
on passe dun niveau de description du systme un autre plus dtaill, dun
modle abstrait du systme un modle plus concret. Les mthodes formelles
permettent de dmontrer quune proprit qui tait vrifie un niveau de
description reste vraie au niveau immdiatement infrieur (plus dtaill) de
la description. Ainsi les mthodes formelles permetent de dmontrer que des
exigences dfinies un modle abstrait restent valables mme au niveau de la
conception dtaille.

Caractristiques des mthodes formelles

Il en existe plusieurs types de mthodes formelles : par contrat, par squences doprations, par types de donnes abstraits ou, encore, par transitions
dtats. Nous donnons ci-aprs les caractristiques communes de ces mthodes
Abstraction : Il sagit de lopration essentielle pour avoir la maitrise de
tout systme complexe. tant donn que le dveloppement de la modlisation dun systme est subordon une simplification et approximation de la
ralit, labstraction est la premire tape pour lutilisation dune mthode formelle. Ainsi au dbut de la modlisation dun systme on doit utiliser une description abstraite du systme qui se limitera aux caractristiques essentiels du
systme. Le modle donc qui est issu de cette description sera un modle abstrait. De cette faon on vitera davoir des dtails qui ne sont pas utiles pour
la description gnrale du systme et, par voie de consquence, on vitera des
implementations prmatures des modules. En particulier il faut savoir que
plus la classe de systmes que nous voulons dcrire est large, moins analytique sera leur description. Bien sr cette remarque est invalider dans des
stades plus avancs de la conception. Car on sait aussi que cest justement un
dveloppement avec une partie analytique importante qui permet de calculer
et de prvoir, cest--dire de faire en sorte que les mthodes formelles soient
rellement utiles.
Correction : chaque tape de lapplication dune mthode formelle, on
sassure, par preuve formelle (logique), que le systme ralise ce qui est dcrit
dans les spcifications initiales.
Raffinement : Il consiste en la construction progressive des modles corrects qui sont de plus en plus concrets. Il sagit, en partant dune spcification initiale la plus abstraite possible, dobtenir des modles de plus en plus
4

concrets en rajoutant des details et des nouveux lments. Ces transformations

se font de manire garantir que si le modle de dpart tait correct vis-vis du cahier des charges, les modles obtenus par la suite sont aussi corrects.
Donc le raffinement permet une prservation de la correction.
Dmonstrateur des thormes : Il cherche tablir une dmonstration dun
thorme en appliquant les rgles de deduction de la logique. Ici comme thorme on entend une proprit que le systme doit vrifier. Il sagit dun processus automatis.
Prcision : Pour quun modle soit rellement utile, il faut aussi quil soit
une reprsentation prcise du systme. La validit du modle est contrainte
par la prcision de la description du systme.

Composants des mthodes formelles

Un outil de mthode formelle contient les composants suivants :

Interface utilisateur qui gre les entres et les sorties.
Analyseur syntaxique : value la syntaxe et traduit en une reprsentation
interne le modle du systme.
Dmonstrateur : effectue de faon automatique des dmonstrations des
thormes issus du modle.
Animateur : effectue des simulations du fonctionnement du modle. Il
peut ou non tre accompagn des sorties graphiques.
Traducteur vers des langages de programmation usuels (par exemple
Ada, C, C++ ou java).
En dehors de ces lments, une mthode formelle peut avoir dautres composants comme des browsers qui tablissent des rfrences croises, gnrateurs de sortie en format spcifique (Latex, XML), etc.

Raffinement

La notion de raffinement a t introduite par Dijkstra et etendue par la suite

par Back. Il sagit dune relation entre deux spcifications S et S0 .
Pour dfinir le raffinement on doit partir de la logique de Hoare. Dans cette
logique une spcification S est compose de trois lments :
Un programme P qui reflte la partie opratoire de la spcification.
Une pr-condition Q qui permet dtablir tous les tats quil soit possible
dtre utiliss par P avant son excution.
Une post-condition R qui permet dtablir tous les tats atteignables par
les tats de Q aprs lexcuton de P.
Une spcification est totalement correcte vis--vis de Q et de R si, partir de
tout tat dans Q, le programme P se termine et fait passer le systme un tat
qui est dans R. Une telle spcification sera note S = {Q} P {R}.
La relation de raffinement sera not S v S0 , si S0 est un raffinement de S.
Cette relation doit tre

 reflexive : S v S.
transitive : si S v S0 et S0 v S00 , alors S v S00 .
monotone : si (Si )i et (Ti )i deux suites des spcifications avec Si v Ti , i,
alors lim Si v lim Ti , condition que les limites existent.
i

La premire proprit assure quune spcification doit tre le raffinement

delle-mme. La transitivit permet de sassurer que le dernier raffinement qui
conduit la spcification la plus concrte, vrifie les proprits de la premire
spcification, la plus abstraite. Enfin grce la troisime proprit nous pouvons decomposer une spcification, qui devient volumineuse, en parties plus
simples et effectuer le raffinement sur chaque partie sparement.
Lopration de raffinement peut se prsenter comme suit : on fixe S = {Q} P {R}.
On cherche S0 = {Q} P0 {R} tel que


Q, R : {Q} P {R} {Q} P0 {R}
o la flche designe limplication logique.
Cette relation est en gnral difficile vrifier dans des cas concrets. Les
mthodes formelles utilisent le plus souvent des techniques de simulation pour
assurer la correction du raffinement.
La simulation permet de tester la relation de correction qui doit exister entre
une spcification et son raffinement et aussi que le raffinement vrifie des proprits complmentaires.
Les mthodes formelles qui utilisent ce type de raffinement sont, entre autres,
la notation Z, la mthode B et le B-vnementiel.
Afin dillustrer lutilisation par les mthodes formelles de la logique de
Hoare examinons lexemple suivant : supposons que nous voulons calculer
la quantit mn , o m et n entiers, et stocker le rsultat dans r. En utilisant un
langage algorithmique, nous pouvons crire :
r 1;
k n;
tant que k 6= 0 faire
dbut
r r m;
k k 1;
fin
On peut dmontrer que ce programme calcule effectivement mn . En effet
chaque itration k de la boucle tant que, on a la relation
r mk = mn
Ce programme se termine toujours, car on commence par k n et chaque
tape on diminue de un la valeur de k. Cette faon de faire reste informelle.
Pour formaliser, on pose
Q : r mk = mn
B : k 6= 0
6

 P : r r m; k k - 1;
Au niveau le plus abstrait la spcification sera
S : {r 1 Q B} r r m; k k 1; {Q B}
On peut dmontrer que cette spcification ralise le but qui est r mn et le
programme se termine.
Un premier niveau de raffinement consiste prciser la faon dont le calcul
r mn sera fait. En utilisant la dcomposition squentielle, nous avons
S1

S2

{r 1 Q B} r r m; {Q }
{Q } k k 1; {Q B}

Un deuxime niveau de raffinement consisterait imposer des conditions la

valeur de n, savoir que n 0 car sinon on aurait jamais n = 0.
S1

S2

{n 0 r 1 Q B} r r m; {Q }
{Q } k k 1; {Q B}

Q : r mk = mn sappelle linvariant de la spcification. Il sagit dune proprit que le systme doit vrifier chaque tape. Cest elle qui garantit que
le systme fera ce que la spcification prcise quil doit faire. Donc si, au cours
des raffinements successifs, on retrouve cet invariant, on conclut que, si au niveau le plus abstrait la spcification tait ralise, elle sera aussi ralise lors
des raffinements successifs.

Exemple : utilisation de la mthode B

Nous allons maintenant utiliser une mthode formelle, la mthode B, pour

prsenter une tude trs simplifie de rgulation des entres-sorties dun parking. Nous avons choisi la mthode B car elle semble tre la plus complte des
mthodes existantes actuellemnt et, de plus, elle a son actif dimportantes
ralisations industrielles.
Lexemple sur lequel nous allons travailler, et qui est largement inspir de
[5], est en ralit un problme assez complexe et nous utiliserons, pour le dveloppement, une toute petite partie. Le problme peut senoncer comme suit :
nous voulons tablir un systme qui rgule les accs dans un parking. On suppose que les usagers sont munis dune carte qui leur permet dy entrer et de
sortir. lentre et la sortie il y a une borne de lecture de la carte. Il y a aussi
une barrire qui se lve aprs la lecture de la carte. La rampe daccs est une
voie et, par consquent, elle ne peut tre emprunte que par une voiture la
fois. Lentre la rampe est rgule par deux feux de circulation deux couleurs rouge et vert placs juste avant chaque borne. On suppose que les
voitures ne passent que quand le feu est vert. Enfin le parking peut contenir un
nombre limit de voitures.
7

Dans une premire approche on ngligera la lecture des cartes et le fonctionnement de la barrire. Ainsi au niveau le plus abstrait, nous pouvons formuler les exigences suivantes :
REQ-1 : Le systme consiste en la rgulation des entres-sorties des voitures
dans un parking via une rampe daccs.
REQ-2 :

La rampe est une voie.

REQ-3 :

Le nombre de voitures dans le parking est limit.

REQ-4 : Le systme a deux feux de circulation avec deux couleurs vert et

rouge.
REQ-5 : Les feux de circulation sont placs aux deux extremits de la rampe
daccs au parking et rgulent lentre et la sortie.
REQ-6 :

Les voitures empruntent la rampe seulement si le feu est au vert.

REQ-7 :

Le systme possde deux capteurs.

REQ-8 : Les capteurs dtectent la prsence des voitures qui rentrent ou sortent
du parking.
Dans le dveloppement que nous ferons ici nous ne prendrons pas en compte
toutes ces exigences. On sefforcera de construire un systme abstrait avec le
minimum dexigences possibles, afin que son fonctionnement soit acceptable.
On pourra ulterieurement rendre le modle plus complet, et plus concret,
laide des raffinements successifs.
Le modle quon construira on lappellera modle m0_parking . Pour laborer ce modle il faut tablir ltat du systme et les vnements que nous pouvons observer. Ensuite on doit tablir les invariants du systme ainsi que, le cas
cheant, les situations de blocage.

6.1

tat

En rgle gnrale, ltat dun systme est dcompos en deux parties :

la partie fixe ou contexte du modle qui contient la dfinition et les proprits des constantes, et
la partie variable du modle qui contient des variables dont le contenu
sera modifi comme consquence de loccurrence des certains vnements.
Ici nous pouvons envisager comme constante le nombre total nbTot de voitures que le parking peut contenir et comme variable le nombre nbVoit de voitures qui sont dans le parking un instant donn.
La constante nbTot a comme proprit dtre un nombre naturel, c--d.
prop_0_1 : nbTot N.
On note prop_0_1 pour la premire proprit du modle initial (c--d. du
modle 0).
Les proprits de la variable nbVoit sont appeles des invariants, car elles
doivent toujours tre vrifies, indpendamment des modifications subies par
nbVoit au cours du temps. Les deux invariants pour nbVoit sont :
8

inv_0_1 : nbVoit N ;
inv_0_2 : nbVoit nbTot.

6.2

vnements

Les vnements refltent les transitions qui permettent de passer dun tat
un autre.
Dans le stade actuel nous pouvons observer deux transitions :
PK_in : Entre dune voiture au parking. La situation juste aprs cet vnement est : n := n+1 ;
PK_out : Sortie dune voiture du parking. La situation juste aprs cet vnement est : n := n-1 ;
Loprateur := sappelle assignation et n := n+1 sera lu n devient gal
n+1. Il faut remarquer qucrire une assignation nest pas crire le code dun
programme, mais seulement prsenter de manire formelle lobservation de
lvolution discrte du systme.

6.3

Permanence des invariants

Quand on applique les assignations des vnements, il faut prouver de faon rigoureuse que les invariants restent valides. La dmarche suivre est prsenter ci-aprs.
Supposons que toutes les constantes du systme sont notes C. Leurs propits sont donnes par le prdicat p (C). De mme toutes les variables sont
regroupes avec la notation V et soit i (C,V ) le prdicat regroupant les invariants. Lapplication des vnements est donne par la fonction e (C,V ). Ainsi
on a V := e (C,V ).
La persistance des invariants sera prouve si la rgle dinvariance suivante
est vrifie :
p (C) i (C,V ) i (C, e (C,V ))
Dans la suite nous noterons cette rgle comme une clause de Horn, savoir
p (C)
i (C,V )

i (C, e (C,V ))
et qui peut aussi se mettre sous la forme
Proprits des constantes
Invariants

Invariants modifis

On applique maintenant la rgle dinvariance aux deux vnements PK_in

et PK_out.
Pour le PK_in on a :
Proprits des constantes
Invariants

Invariants modifis

nbTot N
nbVoit N
nbVoit nbTot

nbVoit + 1 N

et
Proprits des constantes
Invariants

Invariants modifis

nbTot N
nbVoit N
nbVoit nbTot

nbVoit + 1 nbTot

Pour le PK_out on a :
Proprits des constantes
Invariants

Invariants modifis

nbTot N
nbVoit N
nbVoit nbTot

nbVoit 1 N

et
Proprits des constantes
Invariants

Invariants modifis

nbTot N
nbVoit N
nbVoit nbTot

nbVoit 1 nbTot

On peut constater que la deuxime rgle dinvariance de PK_in et la premire de PK_out ne sont pas toujours vrifies. En effet il ny aucune raison
pour que on ait toujours nbVoit + 1 nbTot ou nbVoit 1 N. Pour que ces
invariants soient toujours vrifis, il faut accepter la ralisation dun vnement seulement si certaines conditions sont remplies, ou, pour suivre la terminologie introduite par Dijsktra, si des gardes de cet vnement sont satisfaites.
Dans la suite on notera par g (C,V ) les gardes dun systme et on aura la
rgle dinvariance avec garde suivante :
p (C)
i (C,V )
g (C,V )

i (C, e (C,V ))
10

et qui peut aussi se mettre sous la forme

Proprits des constantes
Invariants
Garde de lvnement

Invariants modifis
En appliquant la rgle dinvarance avec garde pour PK_in, on obtient :
Proprits des constantes
Invariants
Garde de PK_in

Invariants modifis

nbTot N
nbVoit N
nbVoit nbTot
nbVoit < nbTot

nbVoit + 1 N

et
Proprits des constantes
Invariants
Garde de PK_in

Invariants modifis

nbTot N
nbVoit N
nbVoit nbTot
nbVoit < nbTot

nbVoit + 1 nbTot

Pour PK_out on a :
Proprits des constantes
Invariants
Garde de PK_out

Invariants modifis

nbTot N
nbVoit N
nbVoit nbTot
0 < nbVoit

nbVoit 1 N

et
Proprits des constantes
Invariants
Garde de PK_out

Invariants modifis

11

nbTot N
nbVoit N
nbVoit nbTot
0 < nbVoit

nbVoit 1 nbTot

6.4

Initialisation

Linitialisation des variables est un vnement spcifique. Ici on considrera

que le nombre de voitures au parking au dbut est 0. On aura donc
init_0_1 :

nbVoit := 0

On remarque que linitialisation respecte les proprits de la constante. En

effet on a
Proprits des constantes

Invariants modifis

nbTot N

0N

Proprits des constantes

Invariants modifis

nbTot N

0 nbTot

et

6.5

Blocage

Dans la mesure o les vnements PK_in et PK_out se dclenchent maintenant sous le contrle dune garde, il est possible darriver une situation
de blocage si toutes les gardes sont fausses. Pour viter cette situation il faut
introduire une requte supplmentaire
REQ-9 :

Le systme lanc, fonctionne toujours.

Pour formaliser cette requte on note par gi (C,V ) , i = 1, . . . , n la garde de

diffrents vnements. La rgle dabsence de blocage assure quau moins une de
gardes est vrifie chaque instant. Elle peut se formuler comme suit :
p (C)
i (C,V )

g1 (C,V ) gn (C,V )

ou, encore

Proprits des constantes

Invariants

Disjonction des gardes

En appliquant la rgle de labsence de blocage dans le modle du parking

nous avons
Proprits des constantes nbTot N
Invariants
nbVoit N
nbVoit nbTot

Disjonction des gardes

nbVoit < nbTot 0 < nbVoit
On peut observer que la disjonction des gardes peut ne pas se vrifier si
nbTot = 0. Dans ce cas nbVoit = 0 daprs inv_0_1 et nbVoit nbTot daprs
inv_0_2. Donc la disjonction des gardes est fausse. Si on veut viter le blocage
il faut rajouter la proprit
12

prop_0_2 :

0 < nbTot

Vous trouverez en annexe A le code complet en B-venementiel du modle

initial pour le parking.

Raffinement : rampe une voie

Nous allons maintenant procder un raffinement du modle du parking,

cest--dire nous allons essayer dobtenir un modle plus concret et qui ne sera
pas en contradiction avec le modle initial. Pendant le premier modle nous
navons pas pris en considration la rampe dentre-sortie qui est une voie.
Nous allons maintenant laborer un raffinement du modle initial o on prendra en compte la rampe. Nous allons commencer par le raffinement de ltat,
on poursuivra avec le raffinement des vnements et ensuite on soccupera des
rgles.

7.1

tat

La constante nbTot est maintenue mais la variable nbVoit est remplace par
trois variables :
nbSort : nombre de voitures qui sont sur la rampe et qui sortent du parking ;
nbEntr : nombre de voitures qui sont sur la rampe et qui entrent dans le
parking, et
nbRes : nombre de voitures qui sont dans le parking.
Les invariants pour ces variables sont :
inv_1_1 :

nbSort N

inv_1_2 :

nbSort 1

inv_1_3 :

nbEntr N

inv_1_4 :

nbEntr 1

inv_1_5 :

nbRes N

inv_1_6 :

nbSort + nbEntr + nbRes = nbVoit

inv_1_7 :

nbSort = 0 nbEntr = 0

Le dernier invariant exprime le fait que la rampe est une voie.

Les variables nbSort, nbEntr et nbRes sont des variables concrtes, par
opposition nbVoit qui est une variable abstraite.

13

7.2

vnements

Les vnements PK_in et PK_out seront raffins en tenant compte des variables concrtes. On obtiendra ainsi des vnements concrets.
Dans la suite on prsente les versions abstraite et concrte de chaque vnement. Pour PK_in nous avons

PK_in_abstrait

nbVoit < nbTot

nbVoit := nbVoit + 1

nbEntr + nbRes < nbTot

nbSort = 0
, PK_in_concret

nbRes := nbRes + 1

Comme on peut le voir la version concrte de cet vnement a des gardes

compltement diffrentes de la version abstraite. Il faut donc examiner si cette
version nest pas contradictoire avec la version abstraite. Si les gardes de la
version concrte se vrifient, alors cette version de lvnement peut se raliser.
Et, a fortiori, la version abstraite peut aussi se raliser. Car les deux gardes
concrtes nbEntr + nbRes < nbTot et nbSort = 0, impliquent que nbEntr +
nbRes+ nbSort < nbTot, cest--dire que nbVoit < nbTo, ce qui est la garde
de la version abstraite. De plus quand nbRes augmente dune unit, les autres
variables restant inchanges, alors nbVoit, dans la version abstraite, augmente
aussi dune unit, daprs linvariant inv_1_6.
Pour PL_out nous avons

PK_out_abstrait

0 < nbVoit

nbVoit := nbVoit 1

, PK_out_concret

0 < nbSort

nbRes := nbRes 1

Un raisonnement analogue montre que la version concrte nest pas contradictoire avec la version abstraite.
Bien sr ces raisonnements ne sont pas formels. Pour un raisonnement formel, il faut dabord prouver que la version concrte est plus forte que la version
abstraite. Plus forte signifie ici que la garde de version concrte implique la
garde de la version abstraite. Car sinon on pourrait avoir un vnement concret
sans une partie correspondante dans la version abstraite.
Dans la suite on notera par i (C,V ) les invariants abstraits et par j (C,V,W )
les invariants concrets, o W repsente les variables concrtes. Notons aussi par
g (C,V ) la garde de lvnement abstrait et par h (C,W ) la garde de lvnement
concret.
Le raffinement de lvnement scrit de faon formelle :

14

p (C)
i (C,V )
j (C,V,W )
h (C,W )

g (C,V )

ou, encore

Proprits des constantes

Invariants abstraits
Invariants concrets
Gardes concrtes

Gardes abstraites

Le raffinement des invariants scrit :

p (C)
i (C,V )
j (C,V,W )
h (C,W )

j (C, e (C,V ) , f (C,W ))

ou, encore

Proprits des constantes

Invariants abstraits
Invariants concrets
Gardes concrtes

Invariant concret modifi

Lapplication du raffinement pour lvnment PK_in donne

Proprits des constantes nbTot N
0 < nbTot
Invariants abstraits
nbVoit N
nbVoit nbTot
Invariants concrets
nbSort N nbSort 1
nbEntr N nbEntr 1
nbRes N
nbSort + nbEntr + nbRes = nbVoit
nbSort = 0 nbEntr = 0
Gardes concrtes
nbEntr + nbRes < nbTot
nbSort = 0

Gardes abstraites
nbSort < nbTot
ou, en simplifiant
nbEntr + nbRes = nbVoit
nbEntr + nbRes < nbTot

nbVoit < nbTot

Pour lvnement PK_out nous avons

15

Proprits des constantes nbTot N

0 < nbTot
Invariants abstraits
nbVoit N
nbVoit nbTot
Invariants concrets
nbSort N nbSort 1
nbEntr N nbEntr 1
nbRes N
nbSort + nbEntr + nbRes = nbVoit
nbSort = 0 nbEntr = 0
Gardes concrtes
0 < nbSort

Gardes abstraites
0 < nbVoit
ou, en simplifiant
nbSort nbVoit
0 < nbSort

0 < nbVoit
Il faut que le raffinement des invariants soit appliqu chacun de sept invariants ce qui conduit quatorze preuves pour les deux vnements. titre
dexemple on lapplique aux deux derniers invariants.
PK_in et inv_1_6 :
Proprits des constantes nbTot N
0 < nbTot
Invariants abstraits
nbVoit N
nbVoit nbTot
Invariants concrets
nbSort N nbSort 1
nbEntr N nbEntr 1
nbRes N
nbSort + nbEntr + nbRes = nbVoit
nbSort = 0 nbEntr = 0
Gardes concrtes
nbEntr + nbRes < nbTot
nbSort = 0

Gardes abstraites
nbSort + nbEntr + (nbRes + 1) = nbVoit + 1
ou, en simplifiant
nbSort + nbEntr + nbRes = nbVoit

nbSort + nbEntr + (nbRes + 1) = nbVoit + 1

PK_in et inv_1_7 :
16

Proprits des constantes nbTot N

0 < nbTot
Invariants abstraits
nbVoit N
nbVoit nbTot
Invariants concrets
nbSort N nbSort 1
nbEntr N nbEntr 1
nbRes N
nbSort + nbEntr + nbRes = nbVoit
nbSort = 0 nbEntr = 0
Gardes concrtes
nbEntr + nbRes < nbTot
nbSort = 0

Gardes abstraites
nbSort = 0 nbEntr + 1 = 0
ou, en simplifiant
nbSort = 0

nbSort = 0 nbEntr + 1 = 0
PK_out et inv_1_6 :
Proprits des constantes nbTot N
0 < nbTot
Invariants abstraits
nbVoit N
nbVoit nbTot
Invariants concrets
nbSort N nbSort 1
nbEntr N nbEntr 1
nbRes N
nbSort + nbEntr + nbRes = nbVoit
nbSort = 0 nbEntr = 0
Gardes concrtes
0 < nbSort

Gardes abstraites
(nbSort 1) + nbEntr + nbRes = nbVoit 1
ou, en simplifiant
nbSort + nbEntr + nbRes = nbVoit

(nbSort 1) + nbEntr + nbRes = nbVoit 1

PK_out et inv_1_7 :

17

Proprits des constantes nbTot N

0 < nbTot
Invariants abstraits
nbVoit N
nbVoit nbTot
Invariants concrets
nbSort N nbSort 1
nbEntr N nbEntr 1
nbRes N
nbSort + nbEntr + nbRes = nbVoit
nbSort = 0 nbEntr = 0
Gardes concrtes
0 < nbSort

Gardes abstraites
nbSort 1 = 0 nbEntr = 0
ou, en simplifiant
nbSort = 0 nbEntr = 0
0 < nbSort

nbSort 1 = 0 nbEntr = 0

7.3

Initialisation

On considre au dbut que les variables nbSort, nbEntr et nbRes sont initialises zro :
init_1_1 :

7.4

nbSort , nbEntr , nbRes := 0

Blocage

Il reste maintenant tablir la rgle de labsence de blocage. Ici en ralit il

faut vrifier seulement que les gardes concrtes ne conduisent pas un blocage.
Donc la rgle dabsence de blocage scrit comme suit :
p (C)
i (C,V )
j (C,V,W )
g1 (C,V ) gn (C,V )

h1 (C,W ) hm (C,W )

ou, encore

Proprits des constantes

Invariants abstraits
Invariants concrets
Disjonction des gardes abstraites

Disjonction des gardes concrtes

En rgle gnrale, on peut ne pas tenir compte dans les premisses de la rgle
de la disjonction des gardes abstraites, dans la mesure o cette disjonction a t
vrifie lors des vrifications du modle prcdent.
En appliquant au modle raffin du parking, on a

18

nbTot N
0 < nbTot
Invariants abstraits
nbVoit N
nbVoit nbTot
Invariants concrets
nbSort N nbSort 1
nbEntr N nbEntr 1
nbRes N
nbSort + nbEntr + nbRes = nbVoit
nbSort = 0 nbEntr = 0

Disjonction des gardes concrtes (nbEntr + nbRes < nbTot nbSort = 0)

nbSort > 0 nbEntr > 0 (nbRes > 0 nbEntr = 0)
Proprits des constantes

Le code complet du raffinement est donn en annexe B.

Bien sr cette brve prsentation est loin dpuiser le problme. Il y a des
raffinements supplmentaires faire concernant les feux de circulation, le fonctionnement des capteurs, le fonctionnement de la barrire, ainsi que la lecture
des cartes. Le lecteur intresse pourra reporter la rfrence [5] o un problme
analogue est trait.

Conclusion

Lors de cet expos, laccent a t mis sur limportance de lapplication des

mthodes formelles pour la construction des systmes dinformation srs, portables et volutifs. Bien videmment, et lexemple prsent le montre assez
bien, lutilisation de telles mthodes nest pas facile. Elle ncessite de la part de
lingnieur une approche logico-mathmatique du systme, parfois assez dlicate mettre en uvre. Cette difficult explique, au moins en partie, que lutilisation des mthodes formelles ne soit actuellement pas trs rpandue. Il est
esprer que cette situation voluera rapidement. En effet beaucoup dcoles
dingnieur ENSEEIHT, ENSEIRB, le CNAM, la ntre aussi ont dans leur
cursus des cours sur les mthodes formelles. Il existe actuellement des jeunes
ingnieurs qui connaissent bien ces mthodes et leur nombre va crotre dans
les prochaines annes.
De plus, on observe une tendance vers la convergence entre mthodes semiformelles (UML, SYSML) et mthodes formelles. Des outils, comme par exemple
UML2B encore sous forme experimentale permettent de passer dune description UML une description selon la mthode B. Des outils analogues existent
aussi pour la notation Z et le model checker SPIN. On peut donc esprer dans
un proche avenir de dmarrer une tude laide dune mthode semi-formelle
et basculer ensuite une mthode formelle.
Enfin si le systme dvelopper nest pas trs complexe, on peut se contenter des mthodes formelles plus faciles dutilisation comme la notation Z et le
19

model checker SPIN qui possdent, du point de vue dmonstration, animation

et traduction vers dautres langages de programmation, les mmes possibilits
que la mthode B et, parfois, mme suprieures.

Rfrences

Pour la rdaction de cete expos les livres et articles suivants ont t utiliss :
[1] J.-R. Abrial : The B Book - Assigning Programs to Meanings, Cambridge
Univ. Pr., 1996
[2] J.-R. Abrial : Le cahier des charges, ClearSy, 1998
[3] J.-R. Abrial : tude systme : mthode et exemple, ClearSy, 1998
[4] J.-R. Abrial : Guidelines to formal systems studies, ClearSy, 2000
[5] J.-R. Abrial : Formal method course. II Example : Controlling cars on a
bridge, ETHZ, 2005
[6] D. Cansell, D. mry : Foundation of B method, Computing and Informatics,
vol. 22, pp. 1-31, 2003
[7] M. Ben-Ari : Mathematcal logic for computer science, 2nd edition, SpringerVerlag, 2001
[8] Fr. Gervais, M. Frappier, R. Laleau : Vous avez dit raffinement ?, Cedric Cnam, 2005
[9] H. Habrias : Spcification formelle avec B, Editions Herms, 2001
[10] P. A. Lindsay : A tutorial introduction to formal methods, Univ. Queensland, 1998
[11] G. Pouzancre, J.-Ph. Pitzalis : Modlisation en B-evnementiel des fonctions mcaniques, lectriques et informatiques dun vhicule, Technique et Science
Informatique, vol 22, pp.119-128, 2003
Un site pour tout ce qui concerne les mthodes formels
http ://vl.fmnet.info/
Le site franais pour la mthode B
http ://www-lsr.imag.fr/B/

20

ANNEXES

Code du modle abstrait m0_parking

MODEL
m0_parking
CONSTANTS
/* Nombre maximal de voitures dans le parking */
nbTot
PROPERTIES
/* prop_0_1 et prp_0_2

*/

nbTot:NATURAL &
nbTot>0
VARIABLES
/* Nombre de voitures dans le parking */
nbVoit
INVARIANT
/*

inv_0_1

et inv_0_2

*/

nbVoit:NATURAL &
nbVoit<=nbTot
THEOREMS
/*

Disjonction des gardes

*/

(nbVoit<nbTot or nbVoit>0)
INITIALISATION

21

/*

init

*/

n:=0
EVENTS
/* Entre dans le parking */
PK_IN = WHEN nbVoit<nbTot THEN nbVoit:=nbVoit+1 END;
/* Sortie du parking */
PK_OUT = WHEN nbVoit>0 THEN nbVoit:=nbVoit-1 END
END

Code du raffinement m1_rampe

REFINEMENT
m1_rampe
/* Introduction dune rampe daccs */
REFINES
m0_parking
VARIABLES
/* Nombre de voitures qui sont sur la rampe pour entrer au parking */
nbEntr,
/* Nombre de voitures qui sont dans le parking */
nbRes,
/* Nombre de voitures qui sont sur la rampe pour sortir du parking */
nbSort
INVARIANT

22

/* Inv_1_1 inv_1_5
nbEntr:NATURAL &
nbRes:NATURAL &
nbSort:NATURAL &
/* Invariant

*/

nbEntr<=1
nbSort<=1

inv_1_6

*/

nbEntr+nbRes+nbSort=nbVoit &
/* Invariant inv_1_6

Rampe une voie */

(nbEntr=0 or nbSort=0)
THEOREMS
/* Absence de blocage */
((nbEntr+nbRes<nbTot & nbSort=0) or /*
nbSort>0

)/*

gardes concrtes de PK_in

et inv_1_6 ou inv_1_7 */
Garde concrte de PK_out et inv_1_6 ou inv_1_7
*/

INITIALISATION
nbEntr,nbRes,nbSort:=0,0,0
EVENTS
/* Entre au parking PK_in et inv_1_6 */
PK_IN = WHEN nbEntr+nbRes+nbSort<nbTot & nbSort=0 THEN nbEntr:=nbEnt+1 END;
/* Sortie du parking,

PK_out et inv_1_6 */

PK_OUT = WHEN nbSort>0 THEN nbSort:=nbSort-1 END

END

23