REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

MINISTERE DE LENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE

SCIENTIFIQUE
UNIVERSIT EL-HADJ LAKHDAR BATNA
FACULT DES SCIENCES
DEPARTEMENT DINFORMATIQUE

THESE
Prsente par

REBAIAIA Mohamed-Larbi
pour obtenir le titre de

DOCTEUR en Sciences
Spcialit
INFORMATIQUE
Sujet de la thse :
Spcification et Vrification des Systmes Critiques :
Extension de lEnvironnement VALID pour la Prise en Charge du Temps Rel
___________________________

Soutenue publiquement le 16 fvrier 2011 devant le jury compos de :

M. Noureddine BOUGHECHEL
M. Mohamed BENMOHAMED
M. Djamel-Eddine SAIDOUNI
M. Allaoua CHAOUI
M. Azzedine BILAMI
M. Brahim BELATAR

Professeur
Professeur
Professeur
Matre de confrences
Matre de confrences
Matre de confrences

Prsident
Directeur de Thse
Examinateur
Examinateur
Examinateur
Examinateur

A la mmoire de ma mre et de mon pre.

A Saliha, ma femme.
A mes enfants : Aniss, Islem, Rayan et Assil.

REMERCIEMENTS
Les travaux exposs dans cette thse ont t raliss grce aux fruits dun long travail de
recherche ralis lUniversit de Batna, sous la direction de M. Mohamed Benmohamed.
Les premires tapes du projet de recherche de la thse prenaient naissance des ides
amorces dans deux projets de recherche financs par le MESR : lIntelligence Artificielle
Distribues (Multi-Agents en 1997-1998) et la Bisimulation des Systmes temps-rel (19992000) dont je suis linitiateur et le responsable du groupe. Plus tard, lincorporation de la
notion mme de spcification et de vrification des systmes ractifs ainsi que lextension du
systme VALID pour couvrir laspect temps-rel et la description UML/OCL pour le temps
rel a t amorce grce au concours de mon ami, Ammar Attoui, professeur au laboratoire
CESALP/ILP lUniversit dAnnecy que je remercie normment.
Cette thse a t dpose le 4 mars 2005 pour tre dfendue devant un jury. Mais, pour des
circonstances diverses elle a t recule jusquau jour de la soutenance.
Je tiens remercier tout particulirement, Mr. Mohamed Benmohamed, matre de confrences
au Dpartement dInformatique de luniversit de Constantine, qui a encadr cette thse. Je le
remercie aussi pour ses conseils, pour sa disponibilit et pour la confiance quil ma accorde
durant toute la priode de recherche. Je voudrai aussi lui tmoigner toute ma reconnaissance
pour mavoir laiss une totale libert daction.
Je voudrais aussi remercier M. Boughechel Nouredine, Professeur et doyen de la facult des
sciences de lingnieur de luniversit El-Hadj Lakhdar de Batna, davoir accept la
prsidence du jury. Je remercie aussi mes collgues et amis Belatar Brahim et Bilami
Azzedine, Matres de Confrences au dpartement dinformatique de lUniversit de Batna,
davoir accept la dtre membres du jury.
Je tiens aussi exprimer toute ma gratitude Messieurs Djamel-Eddine Saidouni et Alaoua
Chaoui, respectueusement Professeur et Matre de Confrence au dpartement dinformatique
de luniversit de Constantine davoir accept la tache dtre rapporteurs de ma thse.
Aussi, je tmoigne toute ma sympathie Mr. Zidani Majid et Mr. Zidat Samir responsables du
dpartement dinformatique de Batna pour avoir fait limpossible pour que la soutenance ait
lieu dans des dlais raisonnables.
Je voudrai aussi remercier toutes les personnes avec qui, jai eu des discussions scientifiques,
et qui dune manire ou dune autre mont t dune utilit quelconque. Je citerai plus
particulirement mes co-auteurs dans plusieurs publications, Mr Jihad Mohamad Jaam et Mr
Ahmad Hasnah, Professeurs au dpartement dInformatique de lUniversit du Qatar, Mr
Robert Valette, Professeur et Directeur de Recherche au LAAS CNRS de Toulouse, et surtout
Paul Pettersson professeur lUniversit Uppsala (Sude) de mavoir fournit le systme de
vrification UPPAAL. Que M. S. Eker et M. P. Olveczky assistants Professeurs et membres
de lquipe du Professeur Meseguer au laboratoire CSL/SRI lUniversit de Stanford
(USA), reoivent toute ma gratitude, pour les conseils prodigus et le programme Maude
Real-time qui ma t envoy, et surtout pour toutes les bonnes choses quils ont accompli
pour promouvoir le systme MAUDE.
Je remercie normment mes tudiants fin de cycle Ingnieur (Informatique) qui mont aid
dans lcriture du programme ROBDD, pour la programmation des algorithmes gntiques et
du module de simulation.
Jose aussi tmoigner de limplication bnfique dans la prparation de cette thse de
certaines personnes. Je citerai entre autres, ma femme pour mavoir encourag reprendre la
recherche aprs pratiquement une dizaine danne de vide scientifique. Je la remercie aussi
pour le soin dont elle a fait preuve lors de la prparation de ce document et les corrections
quelle a pu apporter.

Rsum : La technologie des systmes mixtes matriels et logiciels connat de nos jours une rvolution sans
pareille dans tous les domaines technologiques. Le fait de mlanger matriel et logiciel, ceci a donn naissance
des systmes trs complexes. La conception de tels systmes, ncessite lintervention de ressources humaine,
financire et technologique trs importante. Pour veiller au bon fonctionnement de leurs conceptions, ces
systmes doivent tre soumis des processus de validation trs rigoureux. Une telle tche nest point vidente
vue laccroissement rapide de la complexit et de lhtrognit des nouvelles architectures (matriel/logiciel).
Aussi correcte que possible, la conception doit tenir compte de certaines proprits dites critiques, qui sans leur
prsence risque dengendrer une situation de catastrophe et mme de ternir limage de la compagnie.
Dans ce travail, nous nous sommes intresses la mise en place dun environnement intgr pour le
dveloppement des systmes ractifs temps-rel. A cet effet, nous avons propos plusieurs solutions pour la
modlisation, la spcification et la vrification de plateformes matriel/logiciel. Dans un premier temps, nous
avons utilis une technique simple et efficace pour implmenter les diagrammes de dcision binaire utiliss pour
la reprsentation et la vrification des rseaux boolens symbolisant les systmes ractifs. Nous avons ensuite,
montr que laxiomatisation des logiques temporelles linaire LTL et arborescente CTL, permet de cerner de
peu le problme de la complexit combinatoire spacio-temporelle. Les automates temporiss et la logique TCTL
ont permis de mettre en place un modle trs utile pour la spcification et la vrification des systmes tempsrels.
En se basant dun cot sur la logique de rcriture comme modle de spcification algbrique et philosophie
universelle de raisonnement formel, et du systme Maude comme outil de programmation et dexcution de ces
spcifications, nous avons intgr le tout en tant que noyau de programmation de lenvironnement en question et
sur lequel un ensemble de modules intgrs et spcialiss sont venus se greffer. Nous avons dautant plus
compris durant cette recherche, que la description UML et son extension UML/OCL et UML-RT, constituent
pour le moment les meilleurs moyens pour la modlisation "semi-formelle" des systmes ractifs temps-rel.
Finalement, nous avons montr laisance mme de lutilisation de cet environnement travers plusieurs
exemples et benchmarks connus.
Mots-cls : Spcification, Vrification, ROBDD, Logique de Rcriture, Maude, UML/OCL, UML-RT, Mthodes
Formelles, Systmes Ractifs Temps-rel.
Abstract : With the increasing emergence of hardware/software distributed systems, designers need in some
ways efficient methods and tools to improve the safeness of such systems and to reduce drastically their design
engineering time. In general, some traditional methods as simulation and testing are used to detect errors and
bugs, but they are inadequate to certify the correctness of complex systems. To accelerate the design and to
avoid distributed systems malfunctions, new mathematical-based techniques have been used to improve the
deficiency of the old methods. During the last two decades, Model-checking and theorems proving have been the
major research verification fields intensively used to check the design correctness of some big projects (NASA
lance rockets, Pentium chips, etc.) In fact, despite the generalization of formal methods, some problems remain
in suspense in producing coherent specification fully integrated semantics and avoiding the size complexity of
designs.
In this Thesis, we present a hierarchical approach and an open environment to describe and to verify distributed
and concurrent systems. The system currently uses UML and extension UML/OCL and UML-RT notations and
provides rewriting logic, model checking, theorem proving, and simulation techniques. The Model checking
algorithm developed in this research work is based on the axiomatization of LTL linear temporal model and tree
temporal logic CTL. We have used temporal automata and TCTL to describe formal behavioral description and
to verify timed-based properties. Our experience has shown that combining Temporal Logics and a theoretical
well based techniques as the Rewriting logic embodied in the core of the fastest formal system (Maude), can
improve the verification of the correctness of large circuits and critical software, and can decrease the timeconsuming to perform a solution. Such good solutions are obtained due to the strategy rules incorporated in
Maude system which are based on the recent theoretic researches by the rewriting community. When one would
like to analyze the results depicted in the benchmark experiments results, he will be surprised because due to the
execution CPU time which is, in general insignificant comparing with other verification commercial tools.
Keywords : Specification, Verification, ROBDD, Rewriting Logic, Maude Language, UML/OCL, UML-RT,
Formal Methods, Reactive Real-Time Systems.

SOMMAIRE
CHAPITRE 1 : INTRODUCTION ET MOTIVATION
1.1
1.2
1.3

Problme tudi dans la thse

Contexte de Nos Travaux
Plan de la Thse

2
3
5

CHAPITRE 2 : ETAT DE LART

2,1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.8.1
2.8.2
2.8.3
2.9
2.10
2.11

Introduction
Mthodes Formelles
Processus de conception
Spcification Formelle
Vrification Formelle
Vrification du Matriel (Hardware)
Techniques de Vrification du matriel
Les spcifications comportementales
Les spcifications Axiomatiques
Les spcifications Logiques
Les spcifications Algbriques
Explosion des tats et Gnration de Modles
Quelques Exemples Notables de cas vrifis
Conclusion

8
8
9
10
11
12
12
13
14
14
14
15
18
18

CHAPITRE 3 : DEFINITIONS DE BASE

3.1
3.2
3.3
3.3.1
3.3.2
3.4
3.5
3.6
3.7
3.7.1
3.8
3.9
3.10
3.11

Introduction
Concepts fondamentaux
Systmes temps rel
Dfinition dun systme temps rel
Temps et contraintes temporelles
Les classes de systmes temps rel
LApproche Synchrone
LApproche Flot de Donnes
LApproche Asynchrone
Synchrone / Asynchrone
Langages et automates
Les multi-ensembles
quivalences de Bisimulation
Conclusion

20
20
21
21
22
23
23
24
25
25
25
27
28
30

CHAPITRE 4 : LES DIAGRAMMES BINAIRES DE DECISION

4.1
4.2
4.2.1
4.2.3
4.3
4.3.1
4.4
4.4.1
4.4.2

Introduction
Diagrammes De Dcision Binaire
Diagrammes De Dcision Binaires Ordonns (OBDD)
Comment Construire les BDDs
Implantation Informatique Des BDDs
Algorithme De Rduction Des BDDs
Manipulation Des ROBDDs
L approche Depth-First search (profondeur dabord)
Lapproche Breadth-First Search

32
33
34
35
36
37
37
37
39

4.5
4.6
4.7
4.8

Algorithme ITE
Ordre Des Variables
Implantation des techniques de reprsentation et de minimisation des systmes
concurrents
Conclusion

40
41
41
42

CHAPITRE 5 : THEORIE DU MODEL-CHECKING

5.1
5.2
5.2.1
5.3
5.3.1
5.3.2
5.4
5.4.1
5.4.2
5.4.3
5.5
5.5.1
5.5.2
5.5.3
5.6
5.6.1
5.6.2
5.6.3
5.7
5.7.1
5.7.2
5.7.3
5.7.4
5.7.5

Introduction
Modles Linaires
La Logique Temporelle Linaire (LTL)
Model-checking la Vole
Les Automates de Bchi.
Quelques dfinitions de Base
LAlgorithme du Model-checking dune Formule de LTL
Transformation dun graphe de Kripke en un graphe de Buchi
Implmentation de la Procdure du Model-checking
Transformation dune formule LTL en Automate de Bchi
Modles Arborescents
La Logique arborescente CTL
Oprateurs Temporels Auxiliaires
Axiomatisation de la logique CTL
Model-checking de CTL
Calcul des points fixes de fonctions monotones : une approche pour CTL
Caractrisation des points fixe pour CTL
La gnration de Contre-exemples.
Vrification des Systmes Temps-rel
Modlisation des systmes temps-rel
Systmes de Transitions Temporises
Composition dAutomates Temporiss
La Logique Temporelle Temporise (TCTL)
Conclusion

44
45
45
49
49
50
52
52
53
54
57
57
59
60
61
62
65
68
68
69
74
75
76
77

CHAPITRE 6 : LA LOGIQUE DE REECRITURE, MAUDE ET FULL-MAUDE

6.1
6.2
6.2.1
6.3
6.3.1
6.4
6.4.1
6.4.2
6.5
6.5.1
6.5.2
6.6
6.6.1
6.6.2
6.7
6.7.1
6.7.2
6.7.3
6.7.4
6.8

Introduction
La rcriture
Quelques concepts fondamentaux
Notions de base des systmes de rcriture
Syntaxe des systmes de rcriture
Spcification quationnelle (syntaxe-smantique)
Notions Gnrale
La dduction dans les Systmes de rcriture
La logique de rcriture
Introduction
Expression de la Logique de Rcriture dans La Thorie des Catgories
Diffrents Type dAlgbres Engendres par la Rcriture
Many Sorted Algebra
Order-Sorted Algebra
Le Langage Maude
Gnralits
Expression des Communications Synchrones et Asynchrones
Caractristique du Module META-LEVEL et de la Rflexions
Full-Maude
Conclusion

79
79
79
81
81
82
82
83
85
85
86
87
88
89
89
89
91
92
94
94

CHAPITRE 7 : SPECIFICATION DES SYSTEMES TEMPS REEL DANS LE CADRE DE

LA LOGIQUE DE REECRITURE
7.1
7.1.1
7.2
7.3
7.4
7.4.1
7.4.2
7.4.3
7.5

Introduction
Spcification des systmes temps rels
Modle temporis
Expression du temps comme une action
Logique de rcriture en tant que smantique pour les systmes temps rel
Application aux automates temporiss
Systmes temps-rel orient-objets
Exemple d'application
Conclusion

96
96
97
99
100
100
101
101
102

CHAPITRE 8 : PROPOSITION DUN ENVIRONNEMENT POUR LA MODELISATION

DES SYSTEMES REACTIFS
8.1
8.2
8.2.1
8.3
8.3.1
8.3.2
8.3.3
8.3.4
8.3.5
8.3.6
8.3.7
8.4
8.4.1
8.4.2
8.4.3
8.4.4
8.4.5
8.4.6
8.4.7
8.5
8.5.1
8.5.2
8.6
8.7
8.7.1
8.8
8.8.1
8.8.2
8.8.3
8.8.4
8.8.5
8.8.6
8.9

Introduction.
Choix dune mthodologie de modlisation
Choix dun langage pour la mthodologie
La notation UML (Unified Modelling Language)
Les bnfices dUML
Les Classes
Diagramme de Classes
Diagramme de Squences
Diagrammes de Collaboration
Diagramme de Statecharts (Diagramme de transitions)
Diagramme dActivit
Vue Gnrale Sur le Langage OCL
POURQUOI OCL?
DANS QUEL CAS UTILISER OCL
Invariants
Expressions Gnrales
Caractristiques Prdfinies sur Tous les Objets
Collection
Valeurs Prcdentes dans Les Post-conditions
Modlisation du systme Train-Gate-Controller en UML/OCL
Lapproche de modlisation par le langage UML
Spcification de Contraintes en OCL
Labstraction des contraintes temporelles en UML/OCL
Traduction du langage UML vers Maude.
Contraintes: passage de lOCL vers Maude
UML et le temps rel
Une reprsentation limite du temps
Illustration dUML pour la Modlisation des Systmes Temps rel
Une approche pour la Spcification des Systmes temps-rel en UML
Spcification des Systmes Temps-rel
Spcification de lExtension du Langage UML
Exemple de Spcification-Strotypes
Conclusion

104
105
106
107
107
108
109
109
111
112
114
115
115
116
116
117
119
120
121
122
122
123
126
126
129
131
131
132
133
133
135
136
137

CHAPITRE 9 : IMPLANTATION
9.1
9.2
9.2.1
9.2.2
9.3
9.4
9.4.1
9.4.2
9.5
9.6
9.6.1
9.6.2
9.7

Introduction
Module de Spcification et de Simulation des Systmes Ractifs
Le Systme VALID
Processus de Modlisation dans VALID
Simulation et Animation dans VALID 2
Transformation de Spcifications VALID en MAUDE
Vrification de la terminaison et de la confluence de la spcification.
Gnration de Code MAUDE Partir de Spcifications VALID
Proposition dun Model Checker bas sur la Logique Temporelle PTL
Exprimentation
Exemple de Spcification dun Systme Hardware
Exemple de Spcification dun Software
Conclusion

139
139
139
143
147
150
150
151
152
154
154
154
157

Conclusion et Perspectives

157

Bibliographie

157

Annexe A

174

Annexe B

178

TABLE DES FIGURES

1.1
1.2
2.1
2.2
2.3
3.1
3.2
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.9
4.10
4.11
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.13
5.14
5.15
5.16
6.2
7.1
7.2
8.1
8.2
8.3
8.4
8.5

8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13
8.14

Lancement et explosion du lanceur europen Ariane-5 le 4 juin, 1996; 36 secondes aprs

son lancement
Architecture gnrale du projet
Vue des tapes a posteriori dun systme de vrification
Cycle de Vie de Logiciels, la Dtection et la correction des erreurs
Une vue schmatique dune approche base sur le model-checking
Deux systmes de transition ayant les mmes traces
Deux systmes bisimilaires
Arbre de dcision binaire associ la fonction F(a,b,c)=abc+ac
Rduction par limination des feuilles et sous graphes identiques
Construction du BDD de f(a,b,c)=abc+ac
Reprsentation du BDD en Mmoire
La procdure Depth-first Search de Bryan
Reprsentation graphique de la dcomposition de Shannon
Opration de la rduction
Lalgorithme du Calcul de la Fonction ITE
L'influence des ordres sur la taille du BDD, applique la formule (x1x2) (x3 x4)

4
5
10
11
13
29
30
34
34
35
36
38
39
40
41
41

(x5 x6)
Interface Graphique du Module ROBDD
Une structure de Kripke simple
Le droulement temporel dun systme dans une logique linaire temporelle
Un automate de Bchi
Automate de Bchi
Systme de transitions
Automate de Bchi obtenu de la figure 5.5
Transformation dune structure de Kripke en un automate de Bchi
LAlgorithme de Recherche des Etats Valides
LAlgorithme EXPAND
Une structure de Kripke et son arborescence infinie
Graphe de Kripk de Dmonstration
Structure dun FSM Relative Un Systme Ractif
Circuit Analogique dun Compteur et son Graphe dEtat (FSM)
Trois automates pourvus dune seule horloge et diffrentes contraintes sur les transitions
Lautomate temporis dun interrupteur
Systme de rgles de Rcriture de Base
Graphe dun Automate
Un passage Niveau et son Automate Correspondant
Reprsentation de Diffrents Modles dans le Langage Maude
Caractristiques dune Classe
Association entre deux objets
Cration et destruction dobjets
Diagramme de Collaboration
Un Statechart correspondant un Systme dappel Tlphonique
Sous-tats Squentiels
Sous-tats Concurrents dans un Statechart
Expression des Barres de Synchronisations dans un Statechart
Un Diagramme dActivit
Diagramme dtat du TGC
Diagramme de Class du TGC
Diagramme de Squence du Sous-systme Train
Diagramme de Squence : Scnario dun train qui approche

42
45
46
50
51
51
52
53
54
55
57
60
64
67
71
72
85
101
102
105
109
109
111
112
113
114
114
114
115
122
122
125
125

8.15
8.16
8.17
8.18
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
9.11
9.12

Contraintes sur la zone Danger

126
131
132

Diagramme des classes dune bibliothque

Les diagrammes de classes (A), les diagrammes Statechart (B) et le diagramme des
squences (C)
Les diagrammes de classes et de statecharts du systme du Contrle de concentration
Signature des Systmes Concurrents supports par VALID
Spcification des comptes bancaires dans VALID
Processus de modlisation
Architecture de VALID
Exemple de systme dvelopp
Boite de Dialogue de Description dun Message
Schma exhaustif des diffrentes phases de spcification sous VALID de latelier de
fabrication
Architecture du simulateur et de lanimateur dobjets concurrents
Reprsentation (modlisation) du Protocole ABP
Une partie du code-Java gnre du protocole ABP
Le rsultat de la simulation et de lanimation du Protocole ABP

148
149
149
149

Le Circuit Muller_C avec Retard

154

140
136
142
143
144
145
146
147

SOMMAIRE DES TABLES

4.8
5.12
6.1
9.12

Fonctions Boolennes Pr-calcules et Exprimes sous Forme de la fonction ITE

Quelques axiomes dExpansion pour CTL
Systmes dInfrence
Rsultats dExprimentation Vrifies par Notre Model-Checker

40
61
83
157

CHAPITRE 1

Introduction et Motivation

1.1

Problmatique

La technologie des systmes mixtes matriels et logiciels en anglais hardware-software (H/S) connat
de nos jours une rvolution sans pareille dans tous les domaines technologiques. Le fait de mlanger
matriel et logiciel, a donn naissance des systmes trs complexes (plusieurs millions de composants
lectroniques et des centaines de milliers de lignes de code et mme plus). La conception de tels
systmes, ncessite lintervention de ressource humaine, financire et technologique trs importante.
Aussi important soit-elle, leur modlisation, avant dtre fabrique permet aux ingnieurs concepteurs
de rduire le nombre derreurs de conception, connue sous lappellation de bugs.
Pour veiller au bon fonctionnement de leurs conceptions, ces systmes doivent tre soumis des
processus de validation trs rigoureux. Une telle tche nest point vidente vue laccroissement rapide
de la complexit et de lhtrognit des nouvelles architectures H/S [Bal97]. Aussi correcte que
po.ssible, la conception doit tenir compte de certaines proprits dites critiques, qui sans leur prsence
risque dengendrer une situation de catastrophe sur le plan financier, humain et mme de ternir limage
de la compagnie. En gnral, ces proprits se rpartissent en deux classes : proprits de performance
(dure du cycle de conception par exemple) et proprits fonctionnelles (problmes dinterblocage par
exemple.)
La conception de composantes H/S dun systme intgr seffectuait traditionnellement de manire
spare, cest--dire que la partie logicielle obtenue, tait excute sur le prototype de la partie
matrielle. Si les contraintes de la spcification requises pour le systme ne sont pas satisfaites par le
design, le processus subit des modifications puis il est ritr dans lespoir dobtenir le bon prototype.
Cette technique de validation savre tre trs coteuse en temps et en cot de ralisation.
Pour parer de telles inconvenances, plusieurs ides ont man de la communaut scientifique pour
llaboration de nouvelles techniques de vrification et denvironnements de co-design groups sous
lappellation doutils et techniques CAD (System-level Computer Aid Design) qui, en ralit, sont des
plate-formes de modlisation, de validation et de synthse, surtout de circuits VLSI (Very Large Scale
Integration Circuits) [Bry91]. Comme la majeure partie des VLSI sont essentiellement des processeurs,
la conception de la partie matrielle et de la partie logicielle est un problme trs critique et complexe.
Aussi, compte tenu dune comptitivit trs prononce dans un march trs ouvert tout produit conu
dans des dlais moindres devient la cl du succs de tout projet.
Il est bien connu que les architectures H/S sapparentent en gnral avec les systmes enfouis
(embedded), critiques et temps-rel, ncessitant quau moment de la phase de validation, une attention
trs particulire mettant en place des mcanismes de vrification tendant viter toute situation
malencontreuse.
Au cours des dernires annes, la complexit de ces systmes (Embedded H/S Systems)[Ern98]
na cess de se dvelopper. Les progrs technologiques favorables, notamment en terme de finesse
de gravure, ont permis de diminuer considrablement leur taille. Cette miniaturisation entranait
incontestablement d'normes avantages, tant au niveau de leur consommation (lectronique grand
public : tlphones cellulaires, distributeurs ATM...), de leur puissance et de leur rapidit.
Lors de la conception des systmes enfouis, la phase de vrification est l'tape la plus longue.
Elle consomme jusqu 70 % du temps de conception. La notion de vrification elle-mme, date
des annes soixante avec les travaux de Dijkstra et Floyd. Celle-ci, sest tale sur plus de trois
dcennies de dcouvertes thoriques extraordinaires qui a vu natre carrment une nouvelle science
dite vrification formelle , qui a vite dclass certaines techniques traditionnelles telles que la
simulation, le testing et les anciennes mthodes de validation. Une prise de conscience de
l'importance de la vrification en tant que telle a merge lors de la mdiatisation de l'erreur de
conception du Pentium d'Intel en 1994 [Pra95]. La perte a t estime plus de 400 millions de
dollars. Ce cas n'est pas isol, puisque de nombreux exemples d'erreurs de conception ont t
mdiatises notamment le cas de l'accident lors du premier vol du lanceur europen ARIANE-5
[Ari96, RSS96] en 1996 (Figure 1.1) qui a t suivi de la vrification du systme complet par des

techniques d'interprtation abstraite, ce qui a permis la suppression de certaines erreurs parmi elles, celles
ayant entran la destruction de la fuse.
Actuellement, les circuits et gros logiciels deviennent de plus en plus labores rendant le
processus de conception trs complexe susceptible dengendrer un nombre maximum d'erreurs et
ceci tous les niveaux du processus de conception, depuis l'analyse du cahier des charges jusqu' la
fabrication du circuit lui-mme [CCL+99]. Il devient donc de plus en plus judicieux de disposer de
moyens thoriques et pratiques permettant de s'assurer de la validit d'un systme avant d'en arriver
la phase ultime de fabrication et de sa mise en service. Il faudrait aussi avant cela de disposer
doutils sinon dune mthodologie de modlisation et de conception base sur les nouvelles ides
tels que UML [OMG99a, OMG01], SDL [ITU01], MSC [ITU-T99, RGG96], Statecharts [Har87]
ou autre, pourvues dune bonne reprsentativit soit de rigueur.
En gnral, la ncessit de recourir aux techniques de vrification bases sur les mthodes formelles
simpose de nos jours. Il sagit donc de produire un modle qui est une reprsentation mathmatique,
graphique (rseau, automate) ou autres (logique, Statecharts, ) dun systme H/S de faon ce que
son comportement se confonde exactement avec sa spcification. Dans la ralit, au moment de la
modlisation certaines caractristiques doivent tre clairement dfinies compte tenu de leur importance
pour dpartager les conceptions, savoir : laspect squentiel ou concurrent (peut-tre bien les deux la
fois), laspect temporel et temporis (peut-tre bien les deux la fois), les aspects critiques,
dterministes ou non-dterministes, discrets ou continus (peut-tre bien les deux la fois appels
communment par le terme hybride), etc.
De nos jours, un grand nombre doutils de vrification acadmiques et commerciaux ont t crit.
Nous citons titre dexemples CheckOff-core technology dvelopp par Siemens, RuleBase-core
technology [BBL+97], dvelopp au CMU (Carnegie Mellon University (USA)). Quelques universits
ont aussi dvelopp les leurs, tels que SMV [McM99], crit par McMillan au CMU dailleurs bas
essentiellement sur un model checking symbolique. LUniversit de Montral possde aussi le sien,
appel MDG (Multiway Decision Graph) [ZB96], qui supporte la vrification de proprits (Property
checking) et lequivalence checking. Le plus populaire parmi ces systmes de vrification est VIS
(Verification Interacting with Synthesis) dvelopp luniversit de Berkeley California (USA). VIS
est constitu de programmes de vrification, de simulation et de synthse des systmes sous forme de
machines dtats finis [Bra95]. Il utilise le langage de description Verilog et permet la vrification par
les model checking et par lquivalence-checking des systmes squentiels et combinatoires, la
simulation cycle-based et la synthse hirarchique. Nous citons aussi Uppaal [UPPAAL] dvelopp
dans le cadre dun travail de collaboration entre lUniversit Uppsala en Sude et Aalborg en Norvge
sous la direction du professeur Wang Yi. UPPAAL est un systme trs efficace qui permet de vrifier
les systmes temps-rel utilisant des algorithmes de rsolution de contraintes et dautres techniques tels
que les BDD (Binary Decision Diagrams) [Bry86]. Il est disponible et tlchargeable au
http://www.uppaal.com. Dautres outils de vrification sont disponibles sur diffrents sites et chacun
deux possde ces propres caractristiques. Nous reviendrons un peu plus tard pour citer quelques-uns
parmi eux dans la partie Etat de lArt.

1.2

Contexte de Nos Travaux

Nos travaux de recherche, rentrent dans le cadre de la prospection et de lutilisation des modles de
spcification et de vrification des systmes informatiques ractifs (H/S). Nous utilisons une approche
formelle base sur la logique de rcriture [Mes90, Mes92, Mes98, Mes99, Mes00], du systme MAUDE
[CDS+00, CDE+99] et de lenvironnement VALID [AM94, AS94, AS96]. La dmarche de spcification
utilise un langage de description du type UML et tendue UML-RT (UML Real-Time). Les modles de
vrification utilisent deux types de logiques temporelles, lune linaire (LTL-PTL)[Pnu77] et lautre
arborescente (CTL) [eme96]. Nous tenons citer que certains de nos travaux ont contribu montrer le bien
fond de lutilisation de certaines mthodes hybrides bases sur les algorithmes gntiques et les rseaux de
neurones pour la description et la vrification des systmes critiques, loin de toute ambigut cre par

lcriture de spcifications formelles trs lourdes, bnficiant de mthodes simples programmer et

excuter sur des plate-formes maintenant trs rapides et disponibles sur le Web [RBJ+03c, RJH03b,
Reb03b, RB02, RBJ+03b].

Figure 1.1 : Lancement ( gauche) et explosion ( droite) du lanceur europen Ariane-5 le 4 juin,
1996; 36 secondes aprs son lancement.
Ce projet (objectifs de la thse), influenc de faon globale par le projet VALID dvelopp par
lquipe de A. Attoui, Professeur Annecy, a t batis VALID 2 [RJ04], pour ne pas sortir de la
mthodologie suivie par VALID. Nanmoins une grande diffrence subsiste entre les deux projets.
Le projet VALID 2 dixit VALID, permet la ralisation dun environnement intgr pour le
dveloppement des systmes ractifs temps rel complexes. VALID 2, quoi que pour le moment est en
phase dexprimentation et dassemblage permet de couvrir les phases de dveloppement, savoir,
lanalyse, la spcification, la conception, la vrification et la validation des systmes. La philosophie de
VALID 2 tire profit comme il a t dit de lexprience accumule par VALID qui dailleurs tourne
autour de trois architectures indpendantes, savoir VALID (le noyau), ANALD (outil daide au
diagnostic en temps rel et/ou en diffr) et RESOLVE (utilis pour la vrification des diffrentes
contraintes temporelles, topologique et de performance, mais aussi pour lauto-apprentissage de la
recherche de stratgies pour pallier certains vnements sous estims pendant la phase de
dveloppement et qui risquent de mettre en cause la cohrence globale du fonctionnement du systme).
VALID 2 est constitu dun noyau qui est VALID, remodel par lincorporation dune interface
graphique mettant en place un systme de modlisation et de spcification de systmes concurrents crit
en Java. Cette application gnre deux types de codes, lun fournit un code Java, utilis pour
lexcution dune simulation et de son animation en directe, et lautre un code formel crit en MAUDE.
VALID 2, incorpore aussi un rsolveur de contraintes bases sur la logique de rcriture, gnrant ainsi
un code excutable efficace et trs rapide. Aussi un vrifieur de spcification crit en MAUDE a t
adjoint au tout. Ce vrifieur appel aussi model checking est un puissant outils qui permet de dboguer
et de vrifier des plate-formes logiciels et matriels, il utilise deux types de logiques temporelles, lune
pour les modles linaires (LTL-PTL-PLTL) et lautre pour les modles arborescents (CTL). Une
troisime logique qui est particulire aux systmes temps rel a t dfinie et crite en MAUDE
(Timed-CTL). Indpendamment cela, nous avons dvelopp, un systme de reprsentation des plateformes Hardware/Software sous forme de ROBDD pour leur simplification dun ct, mais aussi pour
la vrification de lquivalence entre une spcification et son implmentation. Le systme ROBDD est
aussi utilis comme module SAT(isfaction) de contraintes dune faon abrge mais il sera considr
comme un sous module rcursif lors de lutilisation des algorithmes de model checking dus Emerson
et clarke mais pour la vrification de systmes et qui est base sur le CTL et le mu-calcul.
Le systme VALID 2 t enrichi, dun module de vrification crit en Java et qui sarticule autour
de la rsolution de contraintes temporelles qui se prsentent sous forme de systme linaire. Celui-ci (le
module) utilise dun cot les algorithmes gntiques et les rseaux de neurones. Ces deux applications
ne seront pas prsentes par la suite, le lecteur est invit consulter les articles [RBJ+03b, Reb03b]

pour mieux se situer. Dautres modules ont t crits tels que la rsolution des systmes logiques par la
dduction naturelle, les systmes de Gentzen, le rseau de Petri, la logique linaire, limplmentation
des bisimulations etc. Ces modules ne seront pas prsents, du fait de la lourdeur engendre par lcrit
de cette thse. Notons quen fin du chapitre 9, nous donnons un tableau exhaustif de plusieurs
benchmark qui ont t vrifi par le model-checker. Nous notons aussi dans le chapitre 9, quelques
problmes test de systmes ractifs qui seront prsents pour faciliter la comprhension de la notion de
formalisation, de spcification et de vrification.
La figure 1.2, nous donne un aperu gnral sur les diffrents composants du projet de cette thse.

Figure 1.2 : Architecture gnrale du projet

1.3

Plan de la thse

Donnons prsent le plan de ce document. Mis part le premier chapitre qui introduit la
problmatique, la motivation et le contexte de nos travaux de faon presque succincte, voici brivement
les centres dintrts de chacun des chapitres restants :

Le chapitre II dresse un plan dtaill de ltat de lart du contexte de notre thse, savoir les
mthodes formelles, la spcification, la vrification, les outils de vrification temporellestemporises etc.

Le chapitre III introduit quelques dfinitions de base sujettes extension, mais utiles pour
la prsentation de la problmatique. Nous citons les systmes ractifs et temps rel, les
multi-ensembles et la bisimulation.

Le chapitre IV prsente les mthodes de reprsentation des systmes matriels et logiciel

(H/W) sous forme symbolique par un diagramme binaire de dcision (BDD) et dresse des
algorithmes pour sa rduction et sa transformation en diagramme binaire de dcision
ordonn et rduit (ROBDD). Les ROBDD sont trs utiles dans notre cas puisquils
constituent un noyau dune grande importance pour la vrification des systmes et sont dun
apport thorique et pratique considrable pour limplantation des algorithmes dEmerson
pour le CTL et le mu-calcul.

Le chapitre V dfinie mticuleusement la logique temporelle linaire (LTL) et la logique

arborescente temporelle (CTL). Beaucoup dexemples ont t proposs pour bien expliquer

leur signification mais aussi leur force pour vrifier les diffrentes facettes de systmes
complexes. Nous avons prsent des algorithmes trs puissants sous trois formes : simple,
cest dire algorithmique; axiomatique mais aussi en se plaant dans un cadre bien prcis
savoir les automates de Buchi. Cette partie est considre comme le cur mme des
mthodes de vrification. Ce chapitre traite aussi les problmes des systmes temps rel
dfinis dans une forme abstraite qui est lautomate temporis, mais aussi comme des
systmes de transitions temporises. Dans cette partie nous introduisons une logique trs
puissante (TCTL) pour vrifier les systmes temporiss.

Le chapitre VI introduit le concept thorique de la rcriture, de la logique de rcriture et

du systme MAUDE. Nous verrons plus en dtail la force dexpression de la logique de
rcriture et la puissance du systme MAUDE pour la spcification, la vrification des
systmes complexes.

Le chapitre VII reprend une partie des dfinitions introduites dans le chapitre VI afin de
tracer dans ce mme cadre un chemin correct pour la spcification des systmes temps rel.

Dans le chapitre VIII nous proposons un environnement pour la modlisation des systmes
ractifs, qui dun cot utilise un langage particulier et normalis pour la description
graphique des systmes complexes : le langage UML. Ladjonction du protocole de
description de contraintes appel OCL est dun apport considrable ce qui enrichi UML
dun moyen en soit peu formel. Le temps rel est modlis particulirement en utilisant une
mthode singulire les machines dtats etc. Nous proposons une autre faon dapprhender
le temps rel autrement, juste en utilisant UML et OCL, un exemple trs intressant est
mme dress.

Enfin, le dernier chapitre explique la lettre presque tous les lments de notre systme
(environnement) et nous dressons un tableau rcapitulatif de la vrification de certains
benchmarks.

CHAPITRE 2

Etat de l Art

2.1

Introduction

Dans ce chapitre nous dfinissons ltat de lart dune manire trs slective pour montrer le bienfond des mthodes de vrification, leur utilit mais aussi leur pouvoir dabstraction sur les
architectures matrielle et logiciel.
Tout dabord nous prsentons les mthodes formelles en tant quoutils mathmatiques trs forts pour
modliser, spcifier et vrifier les systmes critiques temps rels. Nous donnons aussi des dfinitions
qui pour le moment sont gnrales sur la manire de prendre en charge un systme vrifier, de
dpartager sa spcification formelle de son implmentation et de constituer une base de donne de ses
proprits les plus cruciales.
Dans la suite de ce chapitre nous dfinissons le processus de conception dans un cadre unifi que ce
soit sur une architecture matriel ou bien logicielle, le processus dans les deux cas diffre de trs peu.
Nous introduisons aussi diffrentes techniques de vrification et nous mettons plus de dtail sur le
model-checking, puisque cest ce model qui sera uilise dans la suite de notre travail. A la fin de ce
chapitre nous relatons des cas rels de systmes trs connus qui ont vus ou bien leur fonctionnement
sarrter subitement, mais aussi des systmes qui ont carrment taient dtruits, ce qui a caus des
pertes normes en vies humaines mais aussi en centaines de millions de dollars.

2.2

Mthodes Formelles

Historiquement, les mthodes formelles ont t dfinies ds les premiers temps (vers la fin des
annes 60) comme des mthodes associant une logique, un certain ensemble daxiomes et des
techniques de preuve. De nos jours et plus gnralement, ces mthodes (formelles) sont dfinies comme
un cadre mathmatique (framework) utilis pour modliser les systmes et vrifier leur comportement
loin de toute ambigut. On parlera alors, de vrification formelle le cas de tester une spcification par
rapport son implmentation. La possibilit de prouver certaines proprits dun systme sappelle
technique de vrification de programme.
Les premires tentatives pour dcrire formellement le comportement des systmes sont dues en
majeure partie Turing, Church, McCarthy, Strachey, Floyd et bien dautres [AHU74]. Leurs travaux
avaient pour objectifs de reprsenter un programme dans un cadre mathmatique pur, loin de toute
mtaphore linguistique. Les rsultats de leurs recherches ont dans un premier temps pu tablir les
premiers fondements des systmes de preuve mcanique.
Ces dernires dcennies, la recherche produit de nouvelles techniques de vrification impliquant les
machines dtats finis (FSM : Finite states Machines) et abstraites (Abstract machines) [TSL+90], les
automates gnraliss [Wol97, VW86] et les automates de Buchi [Buc77], les logiques modales
[Che80, HC72] et temporelles [CES86, LPS99, Lam94, SE84, Koz83, SB00], les mthodes d
interpretatation abstraite des prdicats [CC77, Dam96, LGS95, MRS01, TY01], les modles
dquivalences bases sur les bisimulations [Mou92, FV98, FM90, Lar86], les langages de
spcification etc. Ces thories sattachent dfinir un cadre formel pour dcrire les systmes critiques et
en tudier leur comportement laide dun model formel. Dune faon informelle, les comportements
dun systme sont lensemble des excutions possibles. Le but de cette thorie sera dune part de
permettre de vrifier la consistance dune conception et de vrifier que la ralisation correspond aux
spcifications, cest dire que le comportement est conforme celui prvu dans le cahier de charges.
Dun point de vue formel, deux classes de modles simposent : les modles de comportement qui
sintressent aux comportements de la machine (programme) et les modles structurants qui sattachent
au systme lui-mme. Ces deux modles sont pris en charge diffremment selon des caractristiques
fondamentales trs prcises, donc selon des paradigmes diffrents.
En thorie il existe plusieurs modles abstraits pour traiter le comportement dun systme, les plus
tudis dans la littrature sont:


Les mthodes formelles Z [Led96], B [Ab96] et Hol [GM93] sont des systmes de
spcification et de vrification des systmes squentiels. Les tats sont dcrits laide de structures
mathmatiques bien connues tels que les ensembles, les relations et les fonctions; quant aux transitions
elles sont modlises comme des termes de pr- et de post-conditions.

Les langages formels CSP [Hoa85], CCS [Mil80, KS80], Statecharts [Har87], Temporal Logic
(TA) [Lam94], les I/O automata, les automates de Buchi [Buc77] etc., tous semploient spcifier le
comportement des systmes concurrents; les tats sont dcrits laide de domaines trs simples, tels
que les entiers naturels, par contre le comportement est dcrit en terme de squences, darbres ou
dordre partiel dvnements.
Nous citons aussi :

Les Pomsets de Pratt [Pra86] qui sont un modle de smantique causale et de temps linaire.
Les dpendances causales y sont reprsentes par un ordre partiel entre les actions (relation de
causalit). Une excution est alors vue comme une suite de multi-ensembles dactions indpendantes,
respectant la relation de causalit.

Les structures dvnements de Winskel [Win86, Pen88], sont aussi un modle de smantique
causale et de temps arborescent. A une relation de causalit, on ajoute une notion de conflit. Deux
vnements sont en conflits si loccurrence de lun est exclusive de celle de lautre.

Les rseaux de Petri [NPW81] qui sont trs bien connus, PVS [ORS92], Lotos [FGK+96 ],
et Lustre [CHP+91 ], ainsi que dautres, la liste est vraiment bien longue.

2.3

Processus de conception

Le processus de conception est un ensemble dactions, ordonnes et bien dfinies, excuter par
loutil ou loprateur de conception pour satisfaire une spcification dun systme, des consignes ou des
objectifs prdfinis. Ces actions sont troitement dpendantes de la nature du systme en cours de
conception. Fournie par le client, la spcification englobe toutes ou quelques consignes que
limplmentation doive satisfaire. Limplmentation peut tre labore nimporte quel niveau
dabstraction en fonction des paramtres des proprits de la spcification qui doivent tre bien
explicites pour que le test dquivalence de limplmentation avec la spcification puisse tre accompli
sans aucun problme. Aussi, le processus de conception peut tre dfinit comme lacte dcrire les
choses dune faon trs prcises, ce qui permettra aux dveloppeurs dviter ou de dceler les
inconsistances, les ambiguts et les incompltudes. En plus, la spcification est un moyen de
communication mettant en place les relations entre le client et le designer, entre le designer et
limplementeur, entre limplementeur et le testeur. Elle sert aussi comme un document qui accompagne
le code source du systme, mais un haut niveau de description.
La philosophie de conception dpend troitement quil sagisse dun modle Hardware ou dun
modle Software. Le foss nest pas trs large puisque chaque fois on rencontrera les mmes phases
un degr moindre.
1. Pour le cas des systmes Hardware, les processus de conception sont classifis en deux grandes
catgories :
- La conception personnalise ( custom design ) : Son utilisation est trs restreinte et saccommode
trs bien avec les applications spcifiques telles que les processeurs.
- La conception semi-personnalise ( semi-custom design ) : Mieux utilise que la premire, se
rparti en deux catgories : le design base de cellules et le design base de tableaux. Le premier
seffectue en utilisant des cellules de la librairie (des cellules); quant au second, il utilise des modules
MPGAs et FPGAs.
En gnrale, le processus de conception des systmes Hardware comprend les tapes suivantes :

Modlisation : Partant dune description crite dans un langage de spcification ou mme dans
le langage naturel, un modle HDL est tabli et doit tre valid en premier lieu. En gnral, deux
langages de description simposent pour la description du Hardware ; les mieux situs sont les langages
VHDL et Verilog.
Synthse : Dans cette tape, des outils de synthse sont utiliss pour optimiser au mieux selon
des contraintes spcifiques relatives au temps dexcution, la surface du circuit et son cot.
Synopsys et Cadence en tant quoutils de synthse sont la rfrence travers le monde.
Validation : Cette tape finale vrifie si le modle implment reproduit exactement la
fonctionnalit du modle spcifi (modle de rfrence). Aprs ltape de validation, viennent les
phases de mise en prototype et de fabrication.
2. Pour le cas de la conception des systmes logiciels, les diffrentes mthodes sont trs bien
connues et faisant partie du gnie logiciel englobent un degr prt les tapes reprsentes par un
organigramme en V et quil nest pas ncessaire de dtailler. Elles se prsentent comme suit :

Orientation et faisabilit des besoins

Conception prliminaire dun systme

Conception dtaille dun systme

Spcification fonctionnelle du logiciel

Conception dtaille du logiciel

Codage du Logiciel

Test Utilitaire du Logiciel

Intgration et Test dIntgration

Validation du Logiciel

Intgration Matriel-logiciel (Production)

Recette Systme Validation du Systme

Maintenance du Logiciel

Figure 2.1 : Vue des tapes a posteriori dun systme de vrification

2.4

Spcification Formelle

Une spcification formelle d'un logiciel est une description prcise et complte, dans un langage de
style mathmatique, des comportements que doit avoir ce logiciel. L'existence d'une spcification

10

formelle permet de vrifier que les comportements du logiciel sont bien ceux qu'on en attend. Elle peut
aussi tre utilise pour faciliter la gnration automatique de code excutable, et en tout cas pour
vrifier que l'implmentation est correcte. Etudies depuis longtemps pour les programmes squentiels,
ces mthodes formelles s'appliquent aussi la programmation dite parallle, en particulier dans le
domaine des protocoles de communication, et, plus rcemment, dans celui des systmes ractifs. Bien
que les mthodes dites classiques (ou semi-formelles) ont apport des amliorations trs sensibles
(clart et facilit), il est difficile, voire impossible, de vrifier la cohrence et la compltude des besoins
exprims laide doutils automatiques. Un investissement important en termes humains et en termes
de temps est ncessaire pour laborer seulement les premiers prototypes. Dans certains domaines
critiques comme les systmes temps-rel embarqus (systmes de conduite et de pilotage automatique
de fuse ou davion, systmes de contrle ferroviaire ou de centrale nuclaire), la moindre erreur est
fatale. Elle peut entraner des dommages matriels et humains. Les solutions pragmatiques (tests), mais
aussi de simulation sont dfaillantes et sont gnralement bien difficiles mettre en uvre, et ne
couvrent pas tout lespace des solutions.

2.5

Vrification Formelle

La vrification formelle est une approche algorithmique de la vrification logique. Plus

gnralement, ce type de vrification s'associe tout outil qui peut effectuer une preuve sur une
description, de manire mathmatique et exhaustive. Un outil de vrification formelle ne dit pas
simplement si un problme existe mais aide aussi le concepteur corriger le problme. La
vrification formelle consiste comparer la description d'un systme (l'implmentation) avec la
description des services attendus (les spcifications). Cette comparaison s'effectue selon une relation de
satisfaction dfinie elle aussi formellement, en gnrale elle est note |=.
Une approche possible de vrification formelle est l'utilisation de dmonstrateurs automatiques, de
simulateurs ou bien des systmes de rcriture. L'utilisation de ces systmes est en gnral ardue et au
mieux semi-automatisable. Le modle le plus couramment considr pour la vrification est un systme
de transitions tiquetes, c'est--dire un automate dont les transitions entre tats sont tiquetes par les
actions du systme. Le processus de vrification se dcompose alors en deux phases : compilation d'un
programme exprim dans un langage de description vers un systme de transitions tiquetes, un graphe
de Kripke ou bien un rseau de Petri (en ce qui concerne le choix des modlesla liste est vraiment
longue), puis vrification des spcifications sur ce systme de transitions tiquetes (ou autres). Un
intrt pratique de cette approche est qu'elle est compltement automatisable. Elle est par contre limite
par la taille des modles. La technique de vrification applique dpend du formalisme utilis pour les
spcifications.

Figure 2.2 : Cycle de Vie de Logiciels, la Dtection et la correction des erreurs

11

2.6

Vrific a t i o n du Matriel (Hardware)

Limportance de la vrification du matriel. La prvention du risque derreur dans la conception du

hardware est vitale pour toute entreprise. Le hardware a toujours t sujet un cot de fabrication trs
lev. La dcouverte dun dfaut de fabrication aprs la distribution dun produit risque de coter trs
chre lentreprise en question. Le fait de rappeler le produit pour le corriger certes de nos jours
une telle situation est accepte par le client, mais entrane en gnral la banqueroute de
lentreprise si ce nest plus grave. Nous pouvons avoir une ide sur les consquences dune telle
dbcle, justement sur le cas du rappel et la correction du processeur Pentium II, qui a caus une
perte sche de 475 Millions de Dollars Intel.
Lun des indicateurs de lvolution du nombre de portes logiques (logical gates) dans un circuit, la
trs clbre loi de Moore, dailleurs de tout temps vrifie en pratique vraie, atteste que ce nombre
tendance doubler tous les 18 mois ce qui est par consquent un obstacle de taille pour fabriquer des
produits corrects. Certaines tudes empiriques ont indiqu que plus de 50% des ASICs (ApplicationSpecific Integrated Ciruit) au dbut de leur design et fabrication ne fonctionnent pas normalement.
Donc, il nest pas surpris de voir des manufactures investir des sommes colossales pour que leurs
produits soient dpourvus derreurs, ce qui constitue en soit limportance quon donne aux mthodes de
vrification qui sont dailleurs une partie trs importante est bien-tablie dans le processus de
conception. Nous constatons aussi que 27% des efforts consentis au processus de conception sont en
gnrale rservs au design lui-mme, le reste soit peu prt 73% du temps est rserv la phase de
vrification, cest--dire, la recherche et la prvention des bugs.

2.7

Techniques de Vrification du matriel

Les techniques de vrification du Hardware se rpartissent en gnral en trois axes importants,

qui sont :
Emulation: est lune des mthodes de test. Un systme matriel gnrique (re-configurable) appel
lmulateur est configur de faon ce quil se comporte exactement comme le circuit cible pour
quil soit test. Comme pour le testing du logiciel, lmulation essaye de se munir dun ensemble de
stimulis injects au circuit et en retour rassemble les ractions de ce dernier. La comparaison seffectue
alors avec les donnes fournies par la spcification. Pour bien tester le circuit toutes les combinaisons
possibles seront alors utilises. Cette manire de tester les circuits risque dans un certain sens de se
confronter au problme de lespace temps qui risque de faire dfaut. Comme nous lavons dj signal,
tester toutes les possibilits est carrment impossible. Donc les concepteurs essayent toujours de choisir
lensemble test le plus pertinent, en gnral cest selon un canevas bien tudi. Donc, si le nombre de
possibilits diminue, ceci risque de laisser un trou inexplor et par consquent le circuit risque de ne pas
tre fiable 100%.
Vrification des Circuits par Simulation: il est bien connu que les techniques de simulation
constituent en pratique un moyen puissant en tant quoutils de vrification. Loutil de vrification qui
nest autre que le simulateur permet lutilisateur dtudier le comportement du systme sur la base de
la notion de la raction selon certain scnario bien spcifique (stimuli). Ces scnarios sont tablis selon
un plan de travail trs bien structur ou tous sont gnrs par le simulateur lui-mme et construit partir
de nombres alatoires. Il est, cependant trs difficile de trouver toutes les erreurs parce que tout
simplement il est impossible de gnrer tous les scnarios quun systme peut comporter. A titre
dexemple, pour un systme simple, disons un tlphone portable avec un nombre trs rduit de choix
par tape. Supposons que lon considre des scnarios 20 tapes, donc on aura vrifier 520, cest-dire peu prt 100,000,000,000,000 possibilits, un nombre absolument trs grand. Nous savons quen
pratique un nombre trs limit de scnarios possibles sont pris en considration. Par consquent, il

12

existe bel et bien un risque raliste pour que des erreurs indtectables cest--dire non prvues par ces
scnarios subsistent toujours, donc pourraient engendrer lerreur fatale.
Les techniques de simulation procdent toujours sur une reprsentation approche (graphique,
mathmatique ou autres ) du systme qui est le modle. Ce modle est crit dans un langage de
description; les mieux situs sont Verilog et VHDL, standardiss par IEEE. Bas sur les stimulis, les
chemins dexcutions sont examins par un simulateur. La simulation tant le moyen le plus utilis pour
la recherche derreur dans les ASICs, elle est utilise dans diffrentes phases du cycle de conception
(exemples : register-transfer level (RTL), gate et transistor level). Typiquement, environ 21% du
temps de vrification est utilis par lmulation, 63% par la simulation et 16% par les techniques de
lanalyse structurelle.
Vrification par Model-checking : le Model-checking est une technique de vrification qui explore
tous les tats possibles du systme, dailleurs nous pouvons assimiler le model-checker un programme
de jeux dchec qui, avant de bouger une pice doit calculer tous les mouvements possibles en prenant
soins de respecter les variantes pr-programmes (stratgies). Cette manire brute de parcourir tout
lespace engendr par les diffrents scnarios nous incite voir du cot des algorithmes de parcours de
lensemble des solutions, cest--dire que si lon associe, des algorithmes efficaces et des structures de
donnes fiables il est tout fait possible que des systmes trs complexes de lordre de 1020 jusqu
10476 et mme plus puissent tre vrifis. Une vue exhaustive des tapes suivies par le Model-checker
est consigne dans la Figure 2.3.

Figure 2.3 : Une vue schmatique dune approche base sur le model-checking

2.8

Les spcifications comportementales

Cest un ensemble de formalismes utiliss pour dcrire le comportement (souhait) dun systme
(programme). Donc vrifier (dans un sens) revient comparer le systme sa spcification moyennant
une certaine relation (mathmatique). En gnral, au moment de la conception du systme on dresse
dans le cahier de charge un certain nombre de spcifications. Ces spcifications sont prpares
minutieusement par des experts dans le but de prvoir un maximum de situations critiques
(comportement gnral, mais aussi, des situations bien prcises ou uniques). En thorie et dans la
pratique plusieurs formalismes sont utiliss. Nous citons titre dexemples les systmes de transitions
tiquetes (Labelled Transition Systems), les Statecharts de Harel, les rseaux de Petri, les machines
dtats, les automates gnraliss et ceux de Buchi, les structures de Kripke [CES86] et jen passe. Lon
noublie pas que la description peut se faire en utilisant un langage formel et les mieux adapts sont :
CCS [Mil80, Mil89], CSP [Hoa78, Hoa85], ACP [BK85], SDL [ITU01] etc. Il existe tellement de
formalismes quil serait trs difficile de choisir le bon moins dtre un expert, mme selon certaines
caractristiques (synchronicit, paralllisme, non-dterminisme, etc.). De la mme manire pour le

13

choix du formalisme de description, la relation de comparaison pose problme. En gnral, pour le cas
du comportement on utilise des relations dordre partiel [GPS96] ou bien des relations dquivalence,
qui prennent compte du critre dabstraction qui permet de ramener la description dtaille (systme)
vers une description plus abstraite (celle de la spcification). Pour le cas des formalismes formels
descriptifs, ces relations sont bases sur les relations de bisimulation et sont modules par une notion
dobservabilit des actions du programme. Le choix de la relation utiliser dpend essentiellement du
type de proprit que l'on souhaite prserver lors de la comparaison
Ces deux styles de spcification sont complmentaires et dans la plus part des cas, ils
saccommodent trs bien avec les Model-checking qui consistent dterminer lensemble des tats du
modle satisfaisant une formule de la logique temporelle.

2.8.1 Les spcifications Axiomatiques

Cest la forme la plus simple des spcifications formelles. La mthode axiomatique consiste dfinir
un systme dductif dcrivant la relation entre le programme et la spcification. Chaque relation est
spcifie en utilisant des pr- et des post-conditions. Une pr-condition spcifie les valeurs en entre de
la fonction, tandis quune post-condition spcifie les valeurs en sortie. Les pr- et post-conditions sont
en pratique des prdicats qui peuvent tre quantifis et dont les variables sont les paramtres de la
relation spcifie. La vrification devient alors une preuve modulo lensemble des axiomes et des rgles
dinfrence. Donc, il va falloir axiomatiser lquivalence choisie, la spcification et le programme.
Lorsque la spcification est logique, la relation de satisfaction procdera par induction sur la structure
du programme. Ce type de spcification sapparente trs bien avec la smantique axiomatique dont le
fondement a t tabli par Floyd et cest Hoare [Hoa69] qui lui donna sa forme actuelle dfinie sous
forme dun systme daxiomes et de rgles dinfrence. Cette forme de smantique est la base logique
du langage de spcification des processus CSP.

2.8.2 Les spcifications Logiques

Dans ce cadre de spcification, les proprits (spcifications) sont dcrites par des formules logiques.
La spcification est alors dclarative, et le problme rsoudre est de montrer que le programme
appartient lune des logiques de choix en termes de satisfaction. La plus part dentre elles, sont : la
logique propositionnelle, la logique de 1er ordre, la logique de 2ime ordre et dordre suprieur, mais
aussi, des logiques modales tel que le mu-calcul de Kozen [Koz77], plus prcisment elles sont
temporelles [Pnu77]. Elles savrent tre les mieux appropries compte tenu de leur pouvoir
dabstraction qui tient compte du temps en tant quentit symbolique et globale, donc qualitative.
Contrairement, lautre type de logique, plutt une extension pour couvrir laspect du comportement
dun systme temps-rel. Cette particularit, tire profit du temps non plus comme une abstraction
symbolique, mais bien quantitative et dense.

2.8.3 Les spcifications Algbriques

Les spcifications algbriques utilisent la notion dalgbre pour dfinir en mme temps des types de
donnes (data-type) et leur dynamique (comportement). Une algbre est dfinie par un ensemble
doprations appliquer sur les lments de cet ensemble. Par analogie, un type dfinit un ensemble
dobjets. Le comportement dynamique de ces objets peut tre dcrit travers des oprations qui
respectent certaines lois (composition de squentialit, de non-dterminisme, de paralllisme, ...). On
peut ainsi dfinir une algbre et donc parler de spcifications algbriques de ces objets. Cette approche
utilise les axiomes pour spcifier les proprits des systmes, mais les axiomes sont restreints des
quations. Entre autres, les algbres de processus constituent aussi une autre approche de modlisation,
de spcification, mais aussi ce qui est fort intressant, une technique de preuve. ACP de Bergstra &
Klop constitue un trs bon modle de spcification algbrique qui se prsente sous forme dun systme
daxiomes ou toutes les oprations de concurrence sont prsentes.

14

2.9

Explosion des tats et Gnration de Modles

Les mthodes de vrification base sur les modles (model-checking) prsentent un problme crucial
en rapport avec la taille de ce modle. Ds que les programmes tudis sont de complexit raliste, la
taille du modle correspondant devient rapidement prohibitive. Ce problme est connu sous le nom de
l'explosion combinatoire.
Ce problme s'avre donc complexe dans la pratique des outils classiques de vrification qui
travaillent sur le modle compltement gnr. Ces outils se trouvent de fait limits la vrification de
modles ayant environ 106 tats, ce qui est trs en de dans des cas ralistes.
Un certain nombre de mthodes ont t tudies et mis en oeuvre pour tenter de traiter diffrents
aspects du problme de l'explosion des tats. Ces mthodes jouent sur un ou plusieurs des paramtres
qui sont les suivants :
La gnration du modle. L'ide est alors d'essayer de gnrer un modle rduit, mais quivalent au
modle original du point de vue vrification des proprits valider. D'autre part, nous pouvons aussi
avoir des mthodes plus ou moins efficaces de reprsentation du modle, en fonction de ses
caractristiques.
L'exploration du modle. Il est possible d'amliorer considrablement les performances, en temps ou
en mmoire, lors de l'exploration du modle, en neffectuant qu'une exploration partielle ou en ne
mmorisant qu'une partie du modle.
La qualit du rsultat Le but de la vrification formelle est de dmontrer qu'une proprit est correcte
ou fausse pour un systme donn. Mais quand une proprit est fausse, il est souvent possible
d'appliquer des mthodes plus simples qui se contenteront de la recherche d'un contre exemple, comme
par exemple les diffrentes mthodes de test d'un programme. Ce sont des mthodes procdant par une
vrification partielle, permettant de dmontrer la non-satisfaction d'une proprit, mais pas leur
satisfaction.
Dans le mme cadre dide, il existe une multitude de mthodes pour minimiser dun ct les
modles (systmes vrifier) et de les vrifier. Dans ce qui suit, nous prsentons un nombre trs
restreint, mais les plus en vue, cest--dire celles qui ont attir un plus grand nombre de chercheurs et
implmentes dans des outils de vrification trs connus qui sont comme suit :
1. Vrification la vole. Ce type dalgorithme est du Fernandez et Mounier [FM90]. Au lieu de
construire tout le modle, puis de vrifier la proprit sur ce modle, lalgorithme procde par une
vrification instantane dite la vole (on the fly) pendant le parcours du graphe de transition relatif au
modle. Pour ce faire, il est en gnral suffisant de ne garder en mmoire que la pile permettant un
parcours en profondeur. Dans ce cas, le parcours du graphe seffectue en utilisant des algorithmes de
parcours tels que DFS (Depth First Search) et BFS (Breadth First Search). Pour acclrer le calcul, la
plupart des algorithmes la vole utilisent au maximum des piles (mmoire) pour garder le plus
possible des tats dj atteints. Les mmes algorithmes sont souvent utiliss pour une vrification
partielle, grce des mthodes de codage astucieux des ensembles dtats qui ne garantissent pas
forcment l'exploration de tout le modle.
2. Ordres partiels [Pra86, Pel96, GW93]. Une des causes reconnues de l'explosion des tats est
lie la reprsentation du paralllisme par l'entrelacement d'actions parallles asynchrones. Une ide
consiste alors viter de parcourir tous les chemins construits par entrelacement d'actions parallles,
pour n'en parcourir qu'un sous-ensemble caractristique pour la proprit vrifier. Le modle ainsi
parcouru peut tre beaucoup plus petit que le modle complet, surtout si le systme vrifier contient
beaucoup d'actions asynchrones. Cette technique se combine trs bien avec la vrification la vole,
chaque mthode tirant parti des avantages offerts par l'autre.
3. La Rduction. Puisque la taille du modle pose problme, une ide frquemment utilise est de
rduire cette taille en tenant compte soit de la relation de comparaison utilise, soit des spcifications
vrifier. S'il s'agit de spcifications comportementales, la comparaison s'effectue alors pour une relation
dquivalence R. La rduction du modle consiste alors effectuer la vrification sur un modle

15

quivalent pour R, mais plus petit en nombre dtats (de prfrence minimale). De nombreux travaux
ont abouti des algorithmes de rduction trs performants [Hop71, PT87, FV98, BCM+92, EH00,
GO01].
4. Abstraction L'abstraction consiste construire un modle abstrait partir du modle d'origine
dit modle concret, telle que chaque action du modle concret peut tre simule par une action dans le
modle abstrait. Cette technique qui est base sur une approche introduite par Cousot & Cousot vers la
fin des annes 70 [CC77, CH78] et sest dveloppe trs rapidement surtout ces dernires annes
[Uri98, LGS95, MRS01, Dam96]. Les proprits vrifiables par cette mthode doivent tre
prserves par la mthode d'abstraction. Dans ce cas, une proprit vrifie sur le modle abstrait est
valide sur le modle concret. Si la proprit n'est pas vrifie sur le modle abstrait, nous ne pouvons
tirer aucune conclusion, car la mthode d'abstraction peut ventuellement tre trop grossire pour la
vrification de cette proprit. Un grand nombre de travaux ont t consacr aux mthodes
dabstraction et se sont gnralises pour la vrification les systmes critiques, les systmes temps-rel
[TY01, MRS01], et mme les logiques temporelles nont pas t pargnes etc.
5. Composition. Un systme distribu tant construit par la mise en parallle de ces sous systmes,
des mthodes ont t proposes pour tirer partie de cette technique. En particulier, la construction d'une
abstraction du modle peut se faire par la composition d'abstractions de chacun des composants
parallles du modle, l'abstraction de chaque composante tant ventuellement plus facile raliser. De
mme, nous pouvons utiliser cette technique pour la rduction d'un modle, en construisant le modle
global d'un systme partir du modle minimal pour une relation dquivalence R de chacune des
composantes de ce systme. Une autre utilisation de la composition consiste vrifier une proprit
sparment sur chaque composant, et en dduire la validit d'une proprit globale. Nanmoins, un
inconvnient majeur simpose lors de l'utilisation de la composition cest celui de l'explosion des tats.
Mme si chaque composant ne dcrit quune partie du comportement du systme, le modle
correspondant est souvent de taille trs grande. En fait, lorsque certains composants sont modliss sans
tenir compte de leurs interactions avec les autres (relchement de contraintes de synchronisation) leur
modle peut mme tre de taille largement suprieure au modle du systme complet.
6. Techniques symboliques. La reprsentation numrative d'un modle se trouve directement
confronte au problme de l'explosion des tats, la taille de la reprsentation mmoire plus grande pour
des modles de moyenne dimension et quen serait-il pour ceux de dimension trs importante. Une ide
est alors de ne plus reprsenter chaque tat individuellement, mais d'adopter des mthodes de
reprsentation efficaces d'ensembles d'tats, et d'adapter les oprateurs utiliss dans les algorithmes de
vrification classiques pour travailler directement sur des ensembles. Cette approche a vritablement
pris son essor avec la dfinition par Bryant des Diagrammes de Dcision Binaires (Bdds)[Bry92] et leur
extension de Reduced Ordered BDD (ROBDD), qui permettent la manipulation efficace de fonctions
boolennes. De nombreux outils de vrification utilisent les Bdds avec succs, en particulier dans le
domaine de la vrification de circuits. D'autres reprsentations symboliques plus numriques sont aussi
utilises dans la vrification de systmes temporiss et de systmes hybrides [HNS+94, AD90, AH92],
il s'agit de versions plus ou moins particulires des polydres convexes [CH78]. Nous notons aussi que
les BDD ont t retenus pour notre tude et un logiciel t ralis et constitue un module du systme
global.
7. La vrification d'quivalence. Les outils de vrification dquivalence dominent actuellement
le march, principalement grce leur facilit d'utilisation. La vrification d'quivalence n'est pas
simplement un substitut la simulation fonctionnelle au niveau porte [Rit00]. Elle vrifie si deux
circuits ou bien plus simple encore, deux modles, dcrits dans un langage prcis sont quivalents.
Ceci peut tre utile si on possde dj une reprsentation "vrifie" d'un circuit et que l'on veuille valider une nouvelle implmentation. Mais cela permet aussi de vrifier le bon droulement d'une tape
de synthse. Pratiquement, la vrification d'quivalence est utilise des niveaux varis
d'implmentation : partir du haut niveau RTL jusqu'au niveau netlist obtenue aprs placementroutage. Ainsi, elle sert comparer deux descriptions, soit pour des conversions FPGA-ASIC (niveau
porte/niveau porte), des rutilisations de descriptions (niveau porte/RTL), des migrations de langages
(VHDL vers Verilog), des raffinements de descriptions (RTL/RTL), soit enfin pour des insertions de

16

BIST ( Built-In Self Test ) ou des remontes de fonctions partir des transistors [Ger01]. L'emploi
de la vrification d'quivalence par rapport la simulation est rentable lorsque la description
dpasse les 200 000 portes.
8. La vrification de modle. (Model-checking) Les outils de Model-Checking (ModelCheckers) veulent apporter une rponse une question trs dlicate : Ai-je crit la description
que je voulais? . Cette technique requiert de l'utilisateur qu'il cre une spcification en entrant
des proprits sur sa description. Ce type de vrification permet de dceler des failles, comme
les "deadlocks" (tats qui bloqueraient le systme) ou des "exclusions mutuelles" (un systme ne
fonctionne pas avec un autre). Le Model-Checking est une technique qui consiste vrifier les
systmes dont le comportement se modlise par des machines d'tats finis tels que les circuits
squentiels [BBE01]. Le Model-Checking symbolique possde ses racines dans les premiers
concepts du Model-Checking temporel, propose par Clarke et Emerson en 1981 [CE81]. Dans le
Model-Checking temporel, les spcifications sont exprimes dans une logique appele CTL
(Computation Tree Logic), et les descriptions valider sont modlises en systmes tatstransitions. Une procdure efficace base sur le calcul du point-fixe est utilise pour dterminer
automatiquement si les spcifications correspondent aux systmes tats-transitions. Soit l'outil de
Model Checking s'arrte avec la rponse True, indiquant que la description satisfait la
spcification, soit l'outil retourne False. Dans ce dernier cas, l'outil produit un contre-exemple
explicite. L'inconvnient de cette approche d'origine est le problme de l'explosion combinatoire :
l'espace d'tat des descriptions du monde industriel est typiquement trop grand pour permettre une
recherche exhaustive.
9. Model-Checking Symbolic. En 1986, Bryant [Bry86] dveloppa une nouvelle reprsentation
des fonctions boolennes, appeles OBDDs (Ordered Binary Decision Diagrams). La contribution
cruciale de Bryant a t de montrer qu'en fixant un ordre dans le test des variables boolennes
prsentes dans les diagrammes de dcisions binaires, ces diagrammes devenaient des reprsentations
canoniques. McMillan ralisa alors que les OBDDs peuvent reprsenter symboliquement les espaces
d'tats dans les systmes tats-transitions, et en 1987, il dveloppa un logiciel appelle SMV
(Symbolic Model Verifier) dans lequel les systmes contenant 1020 tats pouvaient tre vrifis, la
technique du model checking symbolique tait ne. Actuellement, les model-checking symboliques
sont largement utiliss dans les industries des semi-conducteurs, SMV tant l'un des outils les plus
utiliss. Plusieurs compagnies ont intgr les model-checking symboliques dans leurs propres
outils de conception propritaires. Par exemple, loutil RuleBase est utilis dans des projets
consistant vrifier des protocoles de bus ou d'autres composants. Le model-checker SVE
dvelopp Siemens est appliqu dans de nombreux projets de dveloppements internes, il a t
commercialis des clients externes. D'autres outils commerciaux, bass sur le model-checking
symbolique, incluent FormalCheck de Lucent [Cad99], commercialis par Cadence et Design
Insight.
10. Les dmonstrateurs de thormes. La dmonstration de thormes est une technique qui met
en place une description mathmatique du systme et des proprits vrifier sur ce systme. Cette
logique (Theorem-Proving) est donne en terme de systme formel, qui dfinie un ensemble
daxiomes et un ensemble de rgles dinfrence. La dmonstration de thormes est le processus de
rechercher la preuve dune proprit partir des axiomes et des rgles du systme. Lacte de
prouver une proprit est en gnral long est fastidieux, il require lintervention directe de
lutilisateur puisque le systme doit chaque tape gnrer des lemmes et des dfinitions
intermdiaires. Les dmonstrateurs de thormes sont des outils trs puissants qui contrairement
aux model-checker, ils peuvent vrifier des systmes infinis.
Lutilisation du dmonstrateur de thorme pour les architectures matrielles (PVS et NQTHM)
[ORS92, BM88], consiste formaliser le circuit dans une logique mathmatique. En le dfinissant
un tel niveau d'abstraction, il sera converti compltement dans une approche formelle. Par exemple,
cela fournit le moyen de crer une spcification mathmatique sur la manire dont un multiplieur
fonctionne, et d'tre capable de le prouver. Cette approche permet ainsi des raisonnements
arithmtiques qui peuvent tre impossibles avec les autres techniques.

17

Il existe galement des dizaines de prototypes universitaires et industriels, la plupart tant en

licence publique gratuite pour les utilisateurs. Les plus connus sont:

PVS, dvelopp par le SRI, est un dmonstrateur inductif bas sur une logique d'ordre
suprieur [ORS92]. Il dispose de nombreuses rgles de dduction et est utilis dans l'industrie. La
dmonstration n'est pas automatique et doit tre guide par l'utilisateur.

ACL2 [ KM96], dvelopp au CLI (Computational Logic Inc, Austin, Texas), puis
l'Universit de Texas Austin par J Moore et Matt Kaufmann, est un dmonstrateur inductif bas
sur une logique de premier ordre, sans quantificateurs. Il s'agit d'un dmonstrateur automatique qui
utilise un moteur d'enchanement de rgles de dduction, le programme vrifier est crit dans un
pseudo-code proche du langage LISP, dailleurs ACL2 lui-mme est crit en LISP. Cet outil est le
successeur du dmonstrateur de Boyer-Moore, appel Nqthm [BM88], afin de le rendre compatible
pour un usage industriel sur de gros exemples.

Coq [HKP97], dvelopp l'INRIA, est un dmonstrateur de thorme inductif, bas sur
une logique d'ordre suprieur. Plus prcisment, cet outil est bas sur le calcul des constructions
inductives, c'est--dire, il permet l'expression des dmonstrations comme des termes, et donc leur
traabilit. Ces dmonstrations peuvent tre revrifies par un systme indpendant et la
correction d'un systme ne repose que sur celle d'un noyau trs rduit. Coq propose donc une
intgration du raisonnement et du calcul.

HOL [GM93], dvelopp initialement l'Universit de Cambridge, est un dmonstrateur

inductif bas sur une logique d'ordre suprieur. Cette logique est simple mais expressive. La
dmonstration d'un thorme est manuelle. HOL a t utilis pour la validation de nombreux
systmes matriels, logiciels ainsi que des protocoles de communication.

2.10 Quelques Exemples Notables de cas vrifis

SRT division algorithm. En 1996, RueB, Shankar, and Srivas [RSS96] utilisrent une
technique de dmonstration de thormes base sur loutil PVS pour trouver lerreur qui a cause le
bug du Pentium 94. Cette mthode de vrification fonctionne automatiquement et pourrait trouver le cas
derreur sur le Pentium qui est cause par un mauvais calcul du quotient de la table de slection
Motorola 68020. En 1991 Boyer et Yu utilisrent une spcification du Microprocesseur de
Motorala 68020 en Lisp et lexcutrent sur le dmonstrateur de thorme Nqthm. Cette spcification
sera utilise par la suite pour vrifier plusieurs programmes sous forme de code-machine produits par
des compilateurs partir de code source crit en Ada, Lisp, et C.

AMD5K86. En 1995 Moore et Kaufmann du Computational Logic, Inc., et Lynch de lAdvanced

Micro Devices, Inc., Collaborrent pour prouver la correction crit en ACL2 du Micro-code de Lynch
relative lalgorithme de la division en virgule flottante implment sur lAMD5K86.
2.11 Conclusion
La premire partie de ce chapitre a t consacre, principalement, aux techniques de spcification et
de vrification bases sur les mthodes formelles. Nous y avons quelque peu dtaill le processus de
spcification des plate-formes hardware/software en utilisant un cycle de vie tout fait ordinaire
sappuyant sur un graphique mettant en valeur lvolution du nombre derreurs dans les conceptions
(H/W).
Dans la deuxime partie, nous avons expliqu le problme de lexplosion combinatoire des solutions
relatives aux mthodes de vrification. Nous avons en outre propos un ensemble de modles qui
contournent dans certains cas ce problme. Enfin de compte, nous avons dress une rcapitulation des
outils de vrification existants ainsi que certains bugs trs mdiatiss.

18

CHAPITRE 3

Dfinitions de Base

19

3.1 Introduction
Dans ce chapitre, nous donnons certaines dfinitions de base qui seront cites directement ou
indirectement dans la suite de notre thse. Nous dfinissons en premier lieu, les diffrentes catgories
de systmes (informatiques). Ce sont les systmes ractifs qui nous intressent de prt puisque nous
mettrons laccent sur les systmes ractifs temps rels et la notion mme du temps (mutli-forme) et de
contraintes temporelles.
Les approches synchrones, asynchrones, flot de donnes et synchrones/asynchrones (mixte) sont
introduites pour montrer le bien-fond et lutilit de chacune dentres-elles puisque ce sont des modles
de base utiliss pour linterprtation et la vrification des architectures materiel-logiciels.
Nous rappelons travers quelques dfinitions de la thorie des langages et automates, lments cls
de notre prospection pour manipuler la syntaxe et la smantique des mthodes formelles en relation
avec les logiques temporelles (LTL, CTL, TCTL) qui seront abordes par la suite.
La notion mme de muti-ensemble est un atout indniable pour reprsenter le nombre doccurrence
dun lment dans un ensemble. Ce paradigme est trs apprci pour dcrire le comportement des
systmes concurrents (modles) entre autres les rseaux de Petri et les machines abstraites de rcriture.
Nous apprcierons leurs utilits quand on abordera les chapitres 6 et 7.
La dernire partie de ce chapitre discute quelques fondements thoriques sur lquivalence de ce que
lon appelle les LTS (labelled transition systems), communment appels les graphes (systmes) de
transitions tiquetes. Ce type de systmes formels est utilis pour modliser les systmes concurrents.
La notion mme de bisimulation fait ressortir des points forts pour la comparaison des ces LTSs,
moyennant une relation, mais aussi dans certains cas des axiomes. Nous notons aussi que la
bisimulation permet de mettre en place un mcanisme pour minimiser la taille des LTS et ceci dpendra
de la relation utilise qui peut tre forte, faible, de branchement, etc. Nous introduirons par la suite
diffrentes catgories de bisimulation.

3.2 Concepts fondamentaux

Daprs la classification tablie par David Harel et Amir Pnueli [PH85], les systmes informatiques
se rpartissent en trois sous-classes :
1. Les systmes transformationnels rgis par des programmes de type classique qui disposent de
leurs entres ds leur initialisation, et dlivrent des rsultats lorsquils terminent lexcution ;
2. Les systmes interactifs qui interagissent continuellement avec leur environnement, mais
leurs propres rythmes tels que les systmes dexploitation ;
3. Les systmes ractifs, cest la classe de systmes qui nous intressent en premier lieu. Ce sont
des programmes (systmes) qui ragissent continuellement sans intermittence avec leur environnement
(dterminisme), mais avec une cadence dtermine par cet environnement. Cette classe englobe la
plupart des systmes industriels dits critiques, cest--dire quun disfonctionnement minime soit-il
risque de causer beaucoup de dsagrments, ils sont dits temps rel tels les systmes de contrlecommande, automatismes, systmes de surveillance de processus, de traitement du signal, etc., mais
aussi les protocoles de communication.
Ces systmes doivent possder les caractristiques suivantes :

Ils sont des systmes parallles : en effet, leur conception doit au moins prendre en compte le
paralllisme dexcution du systme et de son environnement. Donc, ils peuvent aussi tre vus comme
un ensemble de composants (sous-systmes concurrents) sexcutant en parallle et cooprant la
ralisation du comportement du systme souhait sur une architecture unique ou parallle.

20


Ils sont soumis des contraintes temporelles strictes, cest--dire quil sagit de tenir compte
de la raction du systme des stimulis extrieurs et des dlais bien prcis.

Ils sont aussi soumis des contraintes de sret particulirement svres, cest--dire quils
doivent tre vrifis rigoureusement pour quils fonctionnent dans des environnements hostiles et des
cadences bien prcises avec un risque carrment nul. Sinon, toute erreur risque dentraner des
situations dextrme gravit (perte de vie humaine, de somme dargent qui peuvent dans des situations
dpasser le milliard de dollars, retard sur le plan d excution projete, etc.).

Maintenance : cest aussi la cl des systmes ractifs qui pousse les concevoir pour durer le
plus longtemps possible (plusieurs dizaines dannes si cest possible), donc cest aussi de pouvoir les
re-compiler et les modifier outrance, sans naturellement perturber leur fonctionnement auquel ils sont
assujettis.
Comme les systmes ractifs temps-rels sont souvent trs complexes pour tre tudis tel quils
sont, alors on essaye de les abstraire tout en gardant leurs fonctions les plus importantes pour mieux
cerner le problme de la vrification des proprits du systme.
La conception des systmes ractifs considre plusieurs approches mises en place pour prendre en
charge tous les aspects cits ci-dessus. Naturellement, plusieurs quipes de recherche se sont carrment
spcialises dans lune ou dans lautre (approche) pour mieux cerner tous les aboutissants thoriques et
lcriture doutils trs puissants en travail mixte avec certains lobbies industriels. Par la suite, une
prsentation exhaustive sera donne pour dtailler, loutil conu et la tche auquel il est subordonn.

3.3 Systmes temps rel

De nombreuses disciplines scientifiques se sont intresses aux problmatiques souleves par les
Systmes Temps Rel (STR). Chacune tudiant un domaine diffrent, utilisant un vocabulaire
spcifique et dfinissant des concepts qui lui sont propres, la terminologie associe au temps rel ne fait
pas actuellement l'objet d'un consensus. Dans le domaine informatique, le terme mme de "temps rel"
suscite encore diffrentes interprtations.
Afin d'viter toute ambigut dinterprtation, certaines dfinitions relatives au temps rel seront
prsentes dans ce qui suit :

3.3.1

Dfinition dun systme temps rel

De nombreuses dfinitions ont t donnes pour les systmes temps rel, nous nous consacrerons
celle qui sera fournit ci-aprs. De plus amples explications formelles seront tayes par la suite.
Dfinition 3.1 (Systme temps rel) Un systme temps rel est un systme dont l'exactitude
(correctness) dpend non seulement des rsultats logiques, mais galement des instants o ces rsultats
sont fournis.
Cette dfinition permet de mettre de ct les dfinitions courantes qui sattachent le dfinir aussi
comme un systme constitu de processus dont lexcution est trs rapide. Un systme ayant des dlais
respecter exprims en heures peut tre considr comme un STR (Chaudires vapeur par exemple).
Ce n'est donc pas uniquement la rapidit des temps de rponse (au sens valeurs trs faibles des
dures) qui caractrise un STR. Nanmoins, la plupart des STR ont des temps de rponse exprims en
milli-secondes (ms). Le respect de telles contraintes de promptitude rend complexe le dveloppement
des systmes et constitue une des caractristiques importantes des STR.
Cette dfinition sexplique essentiellement par le fait que les STR sont des systmes appartenant la
classe des systmes dits ractifs. Par exemple, et de manire simplifie, le rle du systme ractif de
pilotage automatique dun avion sera justement dempcher sa chute, cest--dire de le maintenir une
altitude tolrable (ce que nous appelons le comportement matris).

21

3.3.2

Temps et contraintes temporelles

Le concept de temps est une notion difficile dfinir, ainsi que le rappelle saint Augustin :
Qu'est ce donc que le temps ? Si personne ne me le demande, je le sais ; mais si on me le demande
et que je veuille l'expliquer, je ne le sais plus. (Confession, 11, XV).
Pour notre part, nous ne donnons pas une dfinition philosophique ou mathmatique du temps. De
manire pragmatique, nous considrons simplement le temps comme un moyen d'exprimer des
synchronisations entre des activits concurrentes au sein d'un STR, mais aussi entre ces activits et
celles de l'environnement. Nous utilisons, ici, le terme "activit" au sens de fait temporel. Nous
dfinissons l'occurrence d'un vnement comme la manifestation (gnralement le dbut ou la fin) d'une
activit.
Les indications sur lordonnancement des vnements temporels sont prcisment les contraintes
temporelles (CT).
3.3.2.1

Les types de temps

La communaut informatique distingue deux grands types de temps [AH92]:

Le temps continu. C'est un temps que l'on suppose gnralement dense (et complet), au sens
mathmatique du terme. Il est suppos quentre deux instants t et t', il y ait toujours un troisime instant
t'', ce qui engendre en gnrale par coupure une infinit de temps intermdiaires entre deux temps.
L'observation de la simultanit d'vnements n'est donc pas possible. Cest lensemble des rels qui
semploie le dfinir mathmatiquement.
Le temps logique (ou discret). Correspond une succession d'instants discrets, prdfinis et
ordonns. Ces instants peuvent tre caractriss par des vnements ou par leur priodicit. Le temps
logique entre deux instants n'est pas dfini, il est non dense. La simultanit des vnements est donc
possible, c'est un temps chantillonn aussi appel discret pour les systmes informatiques. Il est en
gnral matrialis par lensemble des entiers naturels.
Temps local/global. Cette dfinition n'a de sens que dans un contexte o plusieurs horloges,
gnralement distribues existent dans le systme. Elle dcrit le fait que l'coulement du temps ne soit
pas mesur de la mme faon dans chacun des nuds du systme. Il s'agit d'un temps global si
l'coulement du temps est le mme pour tous les nuds du systme sinon il s'agit d'un temps local un
nud.
Temps relatif/absolu. Il dpend de la rfrence initiale de ce temps selon que cette rfrence est
partage par tous les temps (temps absolu) ou est spcifiques chacun des temps.
3.3.2.2

Les types de contraintes temporelles

a) Par rapport aux types de temps utiliss

Les contraintes temporelles (CT) pouvant tre exprimes avec les diffrents types de temps, nous
retrouvons les mmes catgories que celle du temps. Par exemple, lordonnancement des vnements
peut tre formul :
En reliant les vnements temporels des dates (utilisation dun temps physique ou
chantillonn),

En les reliant des vnements de rfrence (utilisation dun temps logique absolu),

O en les reliant entre eux par des relations d'ordre (utilisation dun temps logique relatif).
Souvent, on parle de contraintes temporelles implicites (ou qualitatives) lorsquelles sont exprimes
avec un temps sans mtrique (temps continu ou logique). On parle de contraintes temporelles explicites
(ou quantitatives) lorsquelles sont exprimes laide dun temps avec mtrique (physique ou
chantillonn).

22

b) Par rapport leurs origines

Lors du dveloppement de STR, il est courant de diffrencier les contraintes temporelles suivant
leurs origines. On parle alors de CT externes et des CT internes :

Les CT externes sont issus des besoins du systme. Elles expriment des relations d'ordre entre le
systme et des entits qui lui sont extrieures. Elles constituent un ensemble d'informations permettant
de caractriser le procd piloter. Elles vont se traduire par des exigences sur la faon d'observer et/ou
de piloter l'environnement. Ce sont des contraintes dfinissant le comportement naturel et matris du
procd. Cela peut tre des lois de commande, des vitesses de raction, des temps de rponse (dlai
entre la rception d'un stimulus et la gnration d'une rponse pour le systme). Elles peuvent aussi
provenir de besoins non plus dicts par l'environnement mais plutt par les clients et utilisateurs.
Les CT internes expriment des relations d'ordre entre les entits internes au systme. Ce sont des
CT inhrentes au fonctionnement du systme. Par exemple : la priodicit (ou non) des actions
effectuer, des synchronisations entre activits, des dlais d'attente entre chaque communication
(protocole de communication avec attente limit), la validit temporelle d'une donne, mais aussi des
informations concernant les processeurs, leurs vitesses, le systme d'exploitation utilis, les dlais de
communication, le dbit du rseau de communication, etc.
3.4 Les classes de systmes temps rel
Une distinction est faite entre les STR suivant la criticit des temps de rponse de ces systmes. On
parle alors de :
STR critiques ou strict (hard real-time),
STR fermes ou durs (firm real-time),
STR souples, lches ou mous (soft real-time).
D'autres critres de diffrenciation existent entre ces catgories : par exemple, des critres
statistiques sur les temps moyens des contraintes temporelles. Cependant, la criticit des contraintes
temporelles est une condition ncessaire et suffisante pour distinguer les trois types de STR prsents.
Naturellement, le dveloppement de STR stricts ou fermes ncessite imprativement des activits de
vrification et de validation du systme en construction.
La validation (au sens de validation des besoins) consiste s'assurer que le systme en construction
est bien celui attendu par les clients. Le "bon" systme est construit. La vrification (au sens de
vrification des proprits mathmatiques) consiste s'assurer que le systme est cohrent. Le systme
est "bien" (correctement) construit.
Dans ce qui suit nous prsentons rapidement quelques approches pour mieux lucider certaines
caractristiques, ce sont :

3.5 LApproche Synchrone

Les langages synchrones ont t introduits pour faciliter la tche du programmeur en lui fournissant
des primitives, permettant de raisonner comme si le programme ragissait instantanment aux
vnements externes. Chaque vnement interne du programme est prcisment dat par rapport au flot
des vnements externes, et le comportement du programme est compltement dterministe, tant de
point de vue fonctionnel que temporel. En pratique, lhypothse revient supposer que le programme
ragisse assez vite pour percevoir tous les vnements externes en bon ordre. Il est bien connu que les
langages synchrones sont susceptibles dtre implants de manire trs efficace. Le code produit nest

23

autre quun automate fini, dont une transition correspond une raction du systme. Comme le code
dune transition est linaire (il ne comporte pas de boucle) et son temps dexcution est maximal est
donc par consquent calculable, on peut ainsi vrifier le bien-fond de lhypothse de synchronisme. La
notion de synchronicit ne peut tre bien tablie que si lon considre les algbres de processus telle que
CCS.
Les principaux langages synchrones sont ESTEREL [BB91] qui est un langage impratif bien
appropri aux applications dont la partie contrle est prdominante (systme alarme, protocole de
communication ), cest aussi un langage orient automate. SIGNAL [BCG99] et LUSTRE
[HCR+91a, HCR+91b] sont des langages dclaratifs flots de donnes appropris pour les
applications dont la partie calculs prdomine (contrle de processus, traitement de signal) et les
Statecharts [Har85] langage purement graphique trs puissant.

3.6 LApproche Flot de Donnes

Dans le domaine des systmes ractifs, il existe une frange dutilisateurs de spcialit tout fait
diffrentes de linformatique, telles que llectronique et lautomatique, qui ncessitent dans leurs
tudes ou bien dans leurs recherches un outil (i.e modles) qui soit adapt leurs exigences. Dans ce
cas de figure, il est important de leur offrir un concept leur permettant dinterprter leurs dolances.
Lapproche flot de donnes (modles tudis en informatique sous le nom de flots de donnes
[Kah74, McG82]) constitue justement une trs bonne dmarche qui permet de mettre en place laspect
thorique et pratique de tels systmes (lectronique, automatique, etc.). On parlera dans ce cas, de
langages flot de donnes. Ces langages prsentent des avantages non ngligeable et se caractrisent
par :
1. Il sagit dun modle parallle grain fin : conceptuellement, ds quun oprateur possde
donnes ncessaires, il peut laborer les sorties correspondantes. Ainsi, les seules contraintes
squencement et de synchronisation sur les actions sont les contraintes de dpendance entre
donnes. Une description paralllisme rend possible toute une varit dimplantations, allant
squentiel pur jusqu lexcution sur architectures massivement parallles.

les
de
les
du

2. Le modle possde en gnral une proprit mathmatique qui fait dfaut aux langages impratifs
classiques, dans lesquels les notions de mmoire et daffectation introduisent la possibilit deffet de
bord complexe. Ce caractre mathmatique facilite lapplication de mthodes formelles pour vrifier,
construire et transformer les programmes.
3. La description sous forme de rseaux doprateurs fournit directement une reprsentation
graphique des programmes. Une notion de hirarchie est prsente aussi de faon reprsenter un sousrseau comme un oprateur. Lexistence dun formalisme textuel, quationnel quivalent au formalisme
graphique, permet aussi de combiner ces deux reprsentations.
Le langage LUSTRE est un langage synchrone fond sur le modle flot de donnes. Dans ce cas, un
programme peut tre vu comme un rseau doprateurs, et lhypothse de synchronisme consiste
supposer que chaque oprateur de ce rseau rponde instantanment ses entres. Dans le langage
LUSTRE il est fournit les moyens dcrire la spcification de vrifier son comportement travers les
oprateurs temporels disponibles, de gnrer diffrents codes, entre autres lautomate correspondant, et
de minimiser le code et le graphe associ cet automate.

24

3.7 LApproche Asynchrone

La majeure partie des systmes distribus est naturellement asynchrone du fait quils ne peuvent
garantir un dlai fixe pour assurer les communications entre leurs diffrents composants. Ce sont
diffrents processus (tches, activits, agents ) qui s'excutent en parallle des vitesses diffrentes
(pas d'horloge centrale) n'ayant pas forcment de mmoire commune avec des dlais de communication
pouvant varier. En gnral, la modlisation de ces systmes ncessite de considrer les horloges
gnrant des tick grains fins, cest--dire que les vnements peuvent tre gnrs dans un espace
temporis dense (continu).

3.7.1 LApproche Synchrone / Asynchrone

Les mthodes algbriques de spcification des systmes distribus sont considres comme un
puissant outil pour dun ct dcrire mathmatiquement les diffrents aspects des processus
communicants, mais aussi de vrifier leur comportement. Algbriquement, deux processus a et b qui
sexcutent en parallle sont interprt par (a || b). Il existe deux models de base qui permettent de
diffrencier les systmes distribus, cest le synchronisme et lasynchronisme. Lexemple suivant
permet de mieux cerner leur diffrence.
Synchrone : a || b = (a, b)
Asynchrone : a || b = a. b + b. a
exemple:
1. composition parallle de deux processus synchrones (loprateur est not double barres verticales
|| ) :
a.a || b.b (a, b) . (a, b)

2. composition parallel asynchrone (entrelacement = interleaving)

3.8 Langages et automates

On appelle un ensemble fini de symboles reprsentant des signaux (de communication)
X = {x0, ,xn-1} un alphabet de dimension n. Un vnement synchrone x de X est un ensemble de
signaux. La dnomination synchrone signifie que tous les signaux dun vnement sont supposs
survenir au mme instant.

25

Une excution dun programme synchrone est vue par un observateur extrieur comme une suite
dvnements composs par des signaux de son interface. On dfinit ainsi une excution dun
programme comme tant une trace (ou mot synchrone) sur X. Un mot m dfinit sur X est une suite finie
ou infinie dvnements synchrones sur X ( m = (x0,x1, ) | i, xi 2X). La longueur dun mot m est
note |m| (0 |m| ). On note le mot de longueur nulle.
Exemple 3.1
Soit X = {x1,x2,x3}. Alors {x1}, {x1, x3}, {x1,x2,x3} et sont des vnements synchrones sur X.
({x1}, {x2, x3}, {x1,x2,}, ,,{x1, x2}, ) est un mot synchrone sur X.
Dfinition 3.2 Un ensemble fini ou infini de mots est appel un langage. Un programme est dcrit
par lensemble de ces traces donc par un langage.
Si m = (x0, , xn) est un mot fini et m = (x0, ,xn, ) un mot de taille quelconque, on note m.m
la concatnation de ces deux mots, i.e., m.m = (x0, .. , xn, x0, ,xn, ). Notons en outre que X
lensemble des mots (finis ou infinis), X lensemble des mots infinis, X* lensemble des mots finis et
Xn lensemble des mots de taille n sur X.
Dfinition 3.3 Soit X un ensemble de signaux, et soit 2X lensemble des vnements sur X.
Un automate entre/sortie (I/O) A sur X est un tuple (QA,q0A,IA,OA,A) ou
-

QA est un ensemble fini dtats contenant ltat initial q0A.

IA X et OA A sont les ensembles disjoints, respectivement des signaux dentre et de sortie.

Dfinition 3.4 On appelle configuration un couple form dun tat et dun vnement dentre
(q,i) QA x 2IA ou A QA x 2 IA x 2OA x QA est la relation de transition.
Si lautomate est dans la configuration (q,i) QA x 2 IA , il peut passer dans ltat q en mettant la
sortie o si et seulement si (q,i,o,q)A . Quand il ny aura pas dambigut sur la relation de transition,
on notera q

q sil existe une suite infinie (q , q , , q , ) dtats, avec q

0

= q0A et pour tout

n 1, qn-1

x n1 I A

qn.

x n 1 o A

Dfinition 3.5 Un tel automate peut donc tre interprt comme un reconnaisseur de langage sur X
ou ventuellement un gnrateur de langage.
Dfinition 3.6 Un langage des traces est dit rgulier sil existe un automate A reconnaissant ce
langage (T = TA).
Dfinition 3.7 Un automate ractif ne peut pas refuser un vnement dentre. Il possde donc la
proprit
i

qQA,i2I A ,o2OA ,q'QA,qq'

o

Dfinition 3.8 Un automate dterministe a au plus une raction possible un vnement dentre
donn. Il possde donc la proprit
i

o1

o2

qQA,i2 I A ,o1,o22O A ,q'1 ,q'QA,qq'1 et qq'2 o1 =o2 et q'2 = q'1

Dfinition 3.9 Le produit synchrone est lopration de base pour faire communiquer des automates.
Soient A1 = (Q1,q01,I1,O1,1) et A2 = (Q2,q02,I1,O2,2), deux automates. Leur produit synchrone A1 x A2
est un automate,
A1 x A2 = (Q1 x Q2,(q01 , q02) ,(I1 \ O2) (I2 \ O1), ( O1 \ I2) (O2\ I1),12)
o

26

(q ,q )

(q1,q2)

l1 I1 O2, l2 I2 O1.

l1 (i I1)

q1

l2 (i I 2 )

q1

q2

(l2 o) o1

q2

(l2 o) o2

Intuitivement, ce produit synchrone est quivalent lier les entres/sorties de A1 avec celles de A2
portant le mme nom.
Un tat q Q est dit accessible si et seulement sil existe une excution finie (q0,q1,q2, ,q)
atteignant q.
Soit Q lensemble des tats accessibles. Cet ensemble est dfini par un plus petit point fixe.

3.9 Les multi-ensembles

Dfinition 3.10 (Multi-ensembles) Etant donn un ensemble X, un multi-ensemble sur X est une
fonction M : X N. Pour tout x X, nous appellerons M(x) la multiplicit de x dans M.
Nous noterons M(X) lensemble des multi-ensembles sur X. Nous dirons quun multi-ensemble est
fini pour tout x X, M(x) = 0 sauf pour un nombre fini dentre eux.
Nous notons le multi-ensemble vide de la mme manire que lensemble vide : .
Notations 3.11 (Oprations sur les multi-ensembles)
df

M 1 = M 2 xX
df

M 1 M 2 xX

M 1(x) = M 2(x)
M 1(x) M 2(x)

df

M 1 M 2 M 1 M 2 xX : M 1 = M 2(x)
M 1 = M 2 + M 3 df
ou
xX : M 1(x) = M 2(x) + M 3(x)
M 1 M 2
df

M 1 = M 2 M 3 xX : M 1(x) = min{M 2(x), M 3(x)}

df

M 1 = M 2 / M 3 M 3 M 2 xX : M 1(x) ={M 2(x) M 3(x)}

df

M1 =M 2 M 3 M1 =M 2 /

M1

{M 2 M 3 }

df

M (x)
1

x X

Exemple 3.12 Soit X = { x1, x2,x3} et soient M1 = { x1, x1, x1, x1} et M2 = { x1, x2, x2,x3} deux
multi-ensembles sur X, alors nous avons :
M1 + M2 = {x1,x1,x1,x2,x2,x3,x3}
M1 M2 = {x1,x2}
M2(x2) = 2

27

M 1 M 2 et M 2 M 1
M1 \ M2 nest pas dfini.

3.10 Equivalences de Bisimulation

Les systmes de transitions permettent certes de bien reprsenter les systmes parallles, mais offrent
peu de moyens pour vrifier que deux graphes de transitions seraient gaux. Dans ce cas de figure, il est
alors plus intressant de considrer la relation dquivalence dite de bisimulation forte [Mil80, Par81].
Dans la littrature de Glabeek [Gla94], 11 smantiques de concurrence ont t dveloppes et
dfinies sur les LTS (labelled transitions systems). La plus faible dentre elles tant la trace
semantics [Hoa85]. La plus intressante dentre elles tant la smantique de bisimulation telle que
dveloppe par Milner et utilise comme smantique de base pour dcrire le langage des processus CCS
[Mil80]. Lquivalence de bisimulation est le raffinement de la bisimulation observationelle, comme
introduite par Hennessy et Milner dans [HM85].Une autre smantique dquivalence dveloppe par
Bakker and Zucker site dans [Gla94], concide avec la smantique de bisimilation. Entre les deux (la
forte et la trace bisimulation). Par exemple failure semantics introduite par Brookes, Hoare & Roscoe
dans [BHR84]. Elle est plus fine que la trace bisimulation utilise comme systme de base pour
introduire le langage algbrique de processus CSP de Hoare [Hoa78, Hoa85]. De Nicola & Henessy
[DH84] ont dvelopp la Testing equivalence. Olderog & Hoare dvelopprent la readiness semantics
bisimulation. Nous retrouvons aussi ready trace semantics introduite par Pnueli dans [Pnu85] ainsi de
suite.
La bisimulation constitue lquivalence de base qui permet didentifier des systmes ayant un
comportement de mme structure. Son nom vient du fait quelle permet de dfinir la capacit de deux
systmes A1 et A2 simiter mutuellement, cest dire que toute action effectue par A1 peut tre imite
par une action de A2, et rciproquement. Dautre part les tats atteints aprs ces actions doivent tre
bisimilaires, cest--dire quils doivent permettre aux systmes davoir nouveau des comportements
bisimilaires.

3.10.1 Notions dquivalence de comportement

Soit un systme A qui volue par changement dtats, et que lon peut interrompre tout instant.
Lobservation dun tel systme consiste en une succession dactions quil peut effectuer. Lquivalence
de traces identifie les systmes qui admettent le mme ensemble dobservations. Cest--dire, plus
formellement :
Soient A1 et A2 deux graphes de transition (LTS, graphe de Kripke ou autres similaires). Dire que A1
et A2 sont bisimilaires, cest,
Lorsquil nest pas possible de les distinguer lun de lautre
Lorsque lon parcourt de lintrieur lun deux, il ne nous sera pas possible de dire dans quel
model nous y sommes.
Lune des bisimulations les plus utilises dans certains systmes de vrification synchrones, tel que
Aldebaran [FGK+96], incorpor dans la boite outils Toolbox , et dvelopp par lINRIA tant
lquivalence de traces. Dans ce cas de figure, lon considre toutes les excutions qui sont les traces,
uniquement depuis lorigine (le sommet), sans tenir compte de larborescence, cest--dire des
excutions non dterministes.

3.10.2

Equivalence de traces

Dfinition 3.13 Deux tats q1, q2 ont les mme traces, not q1 ~Tr q2, si Tr(q1) = Tr(q2).

28

Deux systmes de transition A1 et A2, ont les mmes traces, not A1 ~Tr A2, si les excutions partent de
leurs initiaux ont les mmes traces, i.e, Tr(A1) = Tr(A2).

Figure 3.1 : Deux systmes de transition ayant les mmes traces

Il est clair que ces deux systmes de transition sont quivalents modulo la relation dquivalence qui
est note ~T. Nous pouvons remarquer que les deux graphes respectent les mmes excutions qui sont
les traces (a.b, a.c).
Exemple 3.14 supposons que nous voulions modliser le comportement dun distributeur
automatique de boissons (caf et th). Ceci se fera comme dans les graphes de transition de la figure
3.1. Supposons en outre que les tiquettes (actions) a, b et c soient renommes en Pice (P), Caf (C) et
Th (T). Il va de soit que les deux systmes possdent le mme comportement, cest--dire quils
acceptent le mme langage, soit P.(C + T) pour le premier et P.C + P.T pour le deuxime graphe.
Une remarque de taille simpose delle-mme, en vrit le comportement de ces deux systmes nest
pas exact si lon dsire tenir compte des moments du droulement des vnements, savoir, quant on
met une pice dans la machine, lon aura le choix dappuyer sur le bouton Caf ou bien celui de Th.
Par contre dans le deuxime graphe celui de droite, nous aurons le choix tout au dbut que lorsque lon
mette une pice de monnaie la machine nous sert th, ou bien lorsque lon met une pice lon est servit
caf. On aura limpression que la machine possde uniquement deux boutons, lun autorise la
distribution du caf et lautre le th. Naturellement il faut que lon mette la pice avant.
Cet exemple introduit la notion du temps de branchement (arborescent) pour le premier cas et celui
de temps linaire pour le deuxime cas.
Pour mieux apprcier lutilit de la relation de bisimulation, lon doit tudier la relation de
bisimulation simple et celle de bisimulation forte.
Dfinition 3.15 Soit un systme de transition tiquet, une relation binaire Q x Q est une
bisimulation si et seulement si :

(p1, p2) . a A.
a

q1(p1q1 q2(p2 q2 (q1,q2)))

a

q2(p2 q2 q1(p1q1 (q1,q2)))

Donc, intuitivement deux tats p et q sont bisimilaires si pour chaque tat p accessible partir dun
tat q par lexcution dune action, il existe un tat p accessible partir dun tat q par lexcution de
cette mme action de faon ce que p et q soient bisimilaires, et vice-versa.
Si est une relation de bisimulation, alors,

29

pQ, (p, p) [rflexivit]

Si (p1, p2), alors (p2, p1) [symtrie] et

Si (p1 , p2), (p2, p3), alors (p1, p3) [transitivit]

Ce qui montre que la bisimulation est bien une relation dquivalence.

Dfinition 3.16 (Bisimulation forte). Une relation SA1 x SA2 ayant les proprits suivantes est
dite bisimulation forte si,
1.

Pour toute transition paA1p, il existe un tat q de A2 telque q aA2 q et p q.

2.

rciproquement, pour toute transition qaA2 q, il existe un tat p de A1 telque paA1 p et p

q.
Exemple :

Figure 3.2 : Deux systmes bisimilaires

Sur lexemple de la Figure 3.2, on a reprsent par les lignes pointilles la relation tablissant la
bisimilarit entre A1 et A2.
Prposition 3.17 Pour tous systmes de transitions A, A1, A2, A3,

IdA une bisimulation entre A et lui-mme

Si est une bisimulation entre A1 et A2, alors -1 est une bisimulation entre A2 et A1.

Si , sont deux bisimulations respectivement entre A1 et A2 et entre A2 et A3, alors o

est une bisimulation entre A1 et A3,

Si pour tout i I (I un ensemble quelconque) i est une bisimulation entre A et A2, alors iI
i est une bisimulation entre A et A .
1

3.11 Conclusion
Dans ce chapitre nous prsent certains concepts fondamentaux pour bien apprhend la suite de
notre travail. Nous avons donn dans un premier temps certaines dfinitions de base en relation directes
avec les systmes ractifs, puis nous avons quelque peu introduit une typologie des systmes temps-rel
et quelques-unes de leurs caractristiques (concurrence, synchronicit, dterminisme, interleaving, etc.).
Nous avons dans un deuxime temps rappel certains lments de la thorie des langages et surtout
pour nous avons dfinit formellement les automates.
En dernier lieu, la bisimulation des systmes concurrents a t aborde pour montrer la capacit des
algorithmes bass sur les techniques de bisimulation minimiser leur complexit ce qui leur confre un
moyen dabstraction et de raffinement par lintermdiaire des systmes de transitions tiquetes, des
structures de Kripke mais aussi des automates de Buchi.

30

CHAPITRE 4

Les Diagrammes de Dcision Binaire

31

4.1 Introduction
La conception des systmes Hardware/Software est une tche trs complexe compte tenu de
lentrelacement de limplmentation de logiciels spcialiss et de hardware dans une seule et unique
puce. Un ensemble de puces rparties dans un systme embarqu devient un problme critique qui
ncessite une sret de fonctionnement. La ncessit de rechercher dautres algorithmes de vrification
sest impos au dbut des annes quatre-vingts. Bryant et al [Bry92, Bry86, BRB90] sont les premiers
avoir utilis brillamment les travaux de Akers [Ake78] sur lutilisation des diagrammes de dcision
binaire pour la vrification symboliques des circuits intgrs. Limplmentation des BDD travers les
algorithmes restrict , apply et ITE [BRB90] permettent de vrifier le bon fonctionnement des
circuits de petite taille. Ruddel utilisa un algorithme bas sur les techniques de programmation
dynamique pour la rduction de la taille des BDD ce qui a permit de vrifier des circuits de grande taille
atteignant 2100 tats [Rud93]. Plus rcemment lextension des BDD en ROBDD (Reduced Ordered
Binary Decision Diagram) tels que les K*BMDs [DBR96] ont t dvelopps pour reprsenter les
fonctions arithmtiques dune faon plus compacte et donner ainsi les moyens pour prendre en charge
le cas de la vrification des circuits squentiels modliss par les machines dtats finis (FSM : finite
states machines) dite analyse daccessibilit. Le processus de vrification stablit par la comparaison
dune implmentation qui doit avoir les mmes valeurs en sortie que la spcification.
Dans cette partie de notre thse nous dcrivons une technique pour la manipulation de fonctions
boolennes base sur les diagrammes de dcision binaire rduits et ordonns (ROBDD). Cette
reprsentation est base sur une implmentation efficace de loprateur if-then-else (ITE). Une table de
hachage est utilise dun ct pour entretenir la forme canonique dans le diagramme ROBDD et pour
constituer avec le ROBDD lui-mme une structure compacte afin de gagner une grande partie de la
mmoire utilise pour leur manipulation. Cette technique fait appel une fonction de mmorisation
hash-based cache pour implmenter lalgorithme qui manipule la fonction rcursive ITE.
Lacclration de cette manipulation seffectue par lutilisation dun ensemble de rgles qui dtectent
lquivalence entre fonctions calcules.
Il est bien connu que la logique propositionnelle est un formalisme que l'on peut coder sous forme de
matriel : on peut construire des circuits en reliant des portes logiques (gates) les unes aux autres,
chaque porte ralisant un connecteur logique. Par exemple, une porte NAND est un bout de circuit
deux entres et une sortie; dans les ralisations positives de la logique, lorsque la tension des deux
entres est au niveau bas, reprsentant F, la sortie est haute, et si une entre est haute, alors la sortie est
basse. Elle ne peut pas dcrire des circuits avec des connexions cycliques (comme l'on fait usuellement
pour crer des dispositifs instables comme des horloges, mais presque tous les circuits dans un
ordinateur contemporain sont des superpositions de portes logiques. En simplifiant, un ordinateur rel
est une grosse formule propositionnelle code sous forme de matriel, plus une horloge (qui envoie des
suites de T(rue) et F(alse) une vitesse prdfinie) et des composants d'interface. En somme, la logique
propositionnelle est essentiellement suffisamment expressive pour dcrire n'importe quel ordinateur
rel. Comme il a dj t cit, l'lment de base de la logique propositionnelle tant la proposition qui
est considre comme tant une variable propositionnelle qui prend ces valeurs du domaine smantique
qui correspond ses deux interprtations : Vrai et Faux ou 1 et 0. En plus des dfinitions introduites
dans la partie Annexe, nous prsenterons ce qui suit :
Dfinition 4.1 Une algbre boolenne est un ensemble non vide A contenant deux lments T, F, et
muni d'oprations , , obissant aux quations suivantes :
a b=b a, a (b c)=(a b) c, a a=a, aT=a, aF=F,
a b=b a, a (b c)=(a b) c, a a=a, aT=T, aF=a,
a(b c)=(a b)(a c), a(b c)=(a b) (a c),
a a=F, a a=T, a=a,
(a b)= a b, (a b)= a b.

32

Dfinition 4.2 Une clause est la disjonction d'un nombre fini de littraux. On parle aussi de clause
conjonctive pour des clauses construites comme la conjonction d'un nombre fini de littraux.
Dfinition 4.3 (Forme Normale Conjonctive) Une Forme Normale Conjonctive, not CNF, est
l'criture de la formule sous la forme d'une conjonction de clauses (des ET de OU de littraux).
Thorme 4.4 Toute formule admet une forme normale conjonctive qui lui est logiquement
quivalente.
Dfinition 4.5 (Forme Normale Disjonctive) Une Forme Normale Disjonctive, note DNF, est
l'criture de la formule sous la forme d'une disjonction de clauses (des OU de ET de littraux).
Contrairement la CNF, il n'est pas toujours possible de calculer de faon polynomiale une
transformation en DNF pour une formule quelconque. En effet, cela reviendrait numrer des
solutions de la formule et il n'existe pas ce jour d'algorithme polynomial qui sache le faire.

4.2 Diagrammes de Dcision Binaire

Une autre ide qui fonctionne pour prouver des formules propositionnelles et qui vient d'ides
smantiques est celle des diagrammes de dcision binaire, ou BDD (Binary Decision Diagram). Le
crateur des BDD tels que nous le connaissons aujourd'hui est Randall E. Bryant en 1986 [Bry86].
Cependant, les BDD sont juste des arbres de dcision avec quelques astuces bien connues en plus, et les
arbres de dcision remontent George Boole (1854). Les ides sont trs simples, mais les ralisations
informatiques sont usuellement plus complexes qu'avec les mthodes prcdentes.
En gros, les techniques qui font que les BDD fonctionnent sont : d'abord, au lieu de reprsenter les
arbres de dcision comme des arbres en mmoire (o il y a un unique chemin de la racine n'importe
quel noeud, nous les reprsentons comme des graphes orients acycliques ou DAG, autrement dit nous
partageons tous les sous-arbres identiques. Ensuite, nous utilisons la rgle de simplification suivante : si
un sous-arbre a deux fils identiques, alors remplacer le sous-arbre par ce fils; Essentiellement, ce sousarbre signifie si A est vrai, alors on utilise le fils de droite; si A est faux, utilise le fils de gauche :
comme les fils de gauche et de droite concident, il n'y a pas lieu d'effectuer une slection fonde sur la
valeur de A. Enfin, nous ordonnons les variables dans un ordre total donn <, et exigeons que, si nous
descendons dans le BDD sur n'importe quel chemin, nous rencontrons les variables en ordre croissant.
Cette dernire proprit assurera que les BDD sont des reprsentants canoniques de formules
quivalence logique prs, c'est--dire que si et ' sont deux formules quivalentes, alors leurs BDD
construits sur le mme ordre sont identiques.
Les diagrammes de dcision binaires constituent un modle de reprsentation des fonctions
boolennes. Un arbre de dcision binaire est un arbre orient compos dune racine, de sommets
intermdiaires et de sommets terminaux valant 0 ou 1. La racine et les sommets intermdiaires sont
indexs et possdent deux sommets fils, un fils gauche et un fils droit. Le fils gauche est atteint en
empruntant la branche 0, le fils droit en empruntant la branche 1. Un arbre de dcision binaire est
obtenu en appliquant rcursivement la premire forme du thorme de Shannon sur lensemble des
variables de la fonction.
Thorme 4.6 (de Shannon) F(x1,x2,,xi,,xn) = x.F(x1,x2,,0,,xn) + F(x1,x2,,1,,xn).
Si ce thorme est appliqu F pour x1, puis aux deux sous-fonctions obtenues pour x2, et ainsi de
suite jusqu xn, on peut raliser un arbre de dcision binaire (un exemple est donn dans la Figure 4.1).

33

Figure 4.1: Arbre de dcision binaire associ la fonction F(a,b,c)=abc+ac.

Notons quil est possible de rduire la taille de larbre en sarrtant dans lapplication du thorme de
Shannon ds que lon se trouve en prsence dune constante 0 ou 1. Ainsi, dans lexemple prcdent
nous voyons que F(0,0, c) = 0, cest dire que F = 0 quelle que soit la valeur qui sera assigne c.

4.2.1 Diagrammes de Dcision Binaire Ordonns (OBDD)

Aprs sa construction, un arbre de dcision binaire peut tre rduit par transformation en un graphe
acyclique orient appel graphe de dcision binaire (BDD). Il est bien connu quun arbre de dcision
binaire possde des feuilles, et engendre en son sein des sous-graphes identiques. La reprsentation peut
tre simplifie en ne conservant quune seule reprsentation des feuilles et sous-graphes concerns, et
en remplaant les autres feuilles et sous-graphes par un arc vers le premier. Le graphe de dcision
binaire ainsi obtenu peut galement tre rduit par limination des sommets redondants, cest dire des
sommets ayant un fils gauche et un fils droit identique (figure 4.2).

Figure 4.2: Rduction par limination: (a) des feuilles et sous graphes identiques ; (b) des sommets
redondants
En cherchant et remplaant tous les sous-arbres quivalents dun diagramme de dcision binaire, on
obtient le diagramme de dcision binaire minimal pour lordre correspondant des variables (ROBDD). Il
est important de noter que pour un ordre donn de variables, le graphe de dcision binaire minimal est
unique. Cette unicit peut videmment tre utilise pour montrer lquivalence de deux expressions
logiques.
Remarque 4.7 La complexit de la procdure de rduction dun BDD est O(nlog n).
La structure du BDD (et en particulier sa taille) dpend de lordre dans lequel sont considres les
variables. Ainsi, pour deux ordres diffrents, les BDD peuvent tre de tailles trs diffrentes.

34

4.2.2 Comment Construire les BDDs [CYB98]

Afin de garantir la canonicit de la reprsentation, les contraintes suivantes sont imposes :

chaque variable ne peut apparatre quune fois au plus sur chaque chemin entre la racine et
une feuille

les variables sont ordonnes de telle faon que si un sommet de label xi a un fils de label xj
alors ord(xi) < ord(xj)

Il y a deux stratgies principales de construction des BDDs :

De la racine vers les feuilles (top-down). Cette mthode est utilise lorsquon part dune
formule algbrique

Des feuilles vers la racine (bottom-up) lorsque lon part dune description structurelle dun
circuit.

4.2.2.1

Mthode top-down

On utilise la formule de Shannon. Par exemple, soit f(a,b,c)=abc + ac avec ord(a)<ord(b)<ord(c)

Si lon fait lexpansion par rapport a on obtient la Figure 4.3 a

En faisant lexpansion par rapport b on obtient la Figure.4.3.b

En faisant lexpansion par rapport c on obtient la Figure 4.3.c

Figure 4.3: Construction du BDD de f(a,b,c)=abc+ac

4.2.2.2

Mthode bottom-up :

Dfinition 4.8 Le niveau dune formule est dfini par :

les variables dentre sont de niveau 0.

chaque sous-formule f = g <op> h a un niveau gal Max(niveau(g),niveau(h)) + 1.

La procdure suivante permet de construire le BDD dune fonction f de n variables :

Construire les BDD des variables.

Construire les BDDs des formules de niveau 1 laide de la fonction :

Appliquer (f1 : BDD, f2 : BDD, oprateur <op>) : BDD.

Rpter ltape 2 jusqu ce que tous les niveaux soient considrs.

Par exemple si f = x.y + z : on construit les BDD de x, y et z puis celui de x.y puis celui de x.y + z.
4.2.2.3

35

Oprations Logiques Entre deux Fonctions Reprsentes par BDD

Les oprations logiques applicables sur les BDD ont t dfinies par Bryant. Lalgorithme permettant
de dterminer le BDD rsultant dune opration logique entre deux fonctions est bas sur lapplication
rcursive du thorme de Shannon selon ce qui suit :
Etant donn deux fonctions F et G, un oprateur Op et un ordre des variables donn. Si nous utilisons
lexpansion de Shannon nous aurons :
F<Op>G = xi.(F/ xi=0 <Op> G/ xi=0 ) + xi.(F/ xi=1 <Op> G/ xi=1 )
Le BDD rsultant dune opration logique entre deux fonctions peut tre conu partir des deux
BDD originaux en appliquant la procdure suivante :
Considrer les sommets racines des BDD. En fonction de la nature de ces deux sommets, appliquer
rcursivement lune des rgles suivantes. Itrer le processus jusqu la gnration des sommets
terminaux.
Rgle1: Si les deux sommets node_f et node_g sont des sommets terminaux alors le sommet
rsultant est un sommet terminal de valeur Valeur(node_f) <Op> Valeur(node_g).
Rgle2 : Si le sommet node_f est un sommet terminal mais pas le sommet node_g, crer le
sommet node_g en lui associant comme fils droit le rsultat de la comparaison (node_g, fils droit de
node_f) et comme fils gauche le rsultat de la comparaison ( node_g, fils gauche de node_f).
Rgle 3 : Si ni le sommet node_f ni le sommet node_g ne sont des sommets terminaux alors :
Rgle 3.1 : Si node_f et node_g reprsentent la mme variable, crer un sommet reprsentant la
variable en lui associant comme fils droit le rsultat de la comparaison (fils droit de node_g, fils droit de
node_f) et comme fils gauche le rsultat de la comparaison (fils gauche de node_g, fils gauche de
node_f).
Rgle3.2 : Si node_f et node_g ne reprsentent pas la mme variable, crer un sommet S
reprsentant la variable intervenant la premire dans lordonnancement considr (S=min[ord(node_f),
ord(node_g)]) en lui associant comme fils droit (gauche) le rsultat de la comparaison entre le fils droit
(gauche) de min[ord(node_f), ord(node_g)] et lautre sommet (max[ord(node_f), ord(node_g)]).
Remarque 4.9 Etant donn deux fonctions F et G dont les BDD respectifs ont n et m sommets. En
termes dappels rcursifs, la complexit de la procdure dapplication dune opration entre ces deux
BDD est 2.n.m. La figure suivante rcapitule le fonctionnement de la procdure

4.3 Implantation Informatique Des BDDs

La figure 4.4, nous donne un aperu sur la manire utilise pour implmenter les BDD en mmoire.
Il suffit pour cela dutiliser une table trois entres. La premire stockera les variables (nuds). Dans la
deuxime et la troisime on mettra, les nuds de rfrence points par ces variables.
Exemple 4.10 S = a' + c' + b.c

Figure 4.4: Reprsentation du BDD en Mmoire

36

4.3.1 Algorithme De Rduction Des BDDs

Principe : suppression des sommets redondants et les sous-graphes isomorphes
Algorithme Suppression_Sommets
Faire id(v) = 0 pour chaque feuille v avec valeur(v) = 0 ;
Faire id(v) = 1 pour chaque feuille v avec valeur (v) = 1 ;
Initialiser le ROBDD avec 2 feuilles avec id =0 et id = 1 ;
Nextid = 1;

**** Nextid = identificateur suivant disponible

Pour (i = n to 1 avec i=i-1) { V(i) = { v V / niveau(v) = i };

Pour chaque v V(i) { if (id(gauche(v)) = id (droit(v))
{ id(v) = id(gauche(v))
enlever v de V(i)}
else clef(v) = id (gauche(v)) , id (droit(v))
/* la clef est dfinie comme la paire didentificateurs des fils*/ }
ancienne_clef = 0 , 0;
Pour chaque v V(i) tri selon la clef {
if clef(v) = ancienne_clef
id(v) = nextid

/* le graphe de racine v est redondant */

else { Nextid++;
id(v)=Nextid;
ancienne_clef = clef (v);
/*ajouter v au ROBDD avec des arcs allant aux sommets dont lid est gale ceux de gauche(v) et
droit(v)) }}}

4.4 Manipulation Des ROBDDs

Dfinition 4.11 Deux BDDs D et D sont isomorphes s il existe une application de sommets de
D sur les sommets de D tel que pour tout sommet v : si (v) = v, alors v et v sont des sommets
terminaux avec value(v) = value(v), ou v et v sont des sommets non terminaux avec index(v) =
index(v), (low(v)) = low(v) et (high(v)) = high(v).

4.4.1 Lapproche Depth-First search (profondeur dabord)

Les algorithmes typiques de BDD sont bass sur la procdure Depth-first search introduite par
Bryant. Nous prsentons trois algorithmes importants.
Le premier algorithme calcul nimporte quelle opration logique de base, par exemple AND, OR,.
Bryant a montr que la complexit de ces oprations est quadratique dans la taille du graphe des
arguments des entrs.
Cet algorithme prend loprateur logique (op) et ses deux oprandes (f et g), et retourne un BDD
comme rsultat de lopration f op g. Le rsultat BDD est construit par lexcution rcursive de la

37

dcomposition de Shannon, dans la manire Depth-first search. Cette dcomposition rcursive sarrte
quand le nouvel oprateur cre est un cas terminal (ligne 1) ou quand le rsultat est disponible dans la
table calcule (ligne 2). La ligne 3 dtermine le top variable de f et g. Les lignes 4 et 5 excutent
rcursivement la dcomposition de Shannon sur le cofacteur. A la fin de cette dcomposition rcursive,
ltape de rduction (ligne 6) assure que le rsultat est un BDD rduit. Le BDD est ainsi insr dans la
table unique (lignes 7-11) et finalement loprateur est insr dans la table calcule avec son rsultat.

Figure 4.5: La procdure Depth-first Search de Bryant

Le deuxime algorithme est appel le produit relationnel (relational product). Celui-ci calcule
v. f g . Lide de base est que le produit f g slectionne lensemble des transitions valides et la
quantification existentielle v. La complexit de cet algorithme est NP-hard.
Le troisime algorithme est appel restrict est un algorithme utilis pour minimiser la reprsentation
BDD d'une fonction boolenne par le choix des valeurs appropries et ne se soucie pas de lespace
utilis do son appellation en anglais (dont care-space).
Procedure RP(v,f,g)
/*calcul du produit relationnel : v.f g, ou v est l ensemble de variables quantifier et f et g sont deux BDDs*/

if (cas terminal) return simplified result

if the result of (RP,v,f,g) is cached, return the result
let be the top variable of f and g
r0 RP(v,f|0,g|1) /*Shannon expansion on 0-cofactors*/
if ( v) /* existential quantification on OR (r0, RP(v,f|1,g|1*/
if (r0 ==1)/* OR (1, RP(v,f|1,g|1) 1*/

r1

else r1 RP(v,f|1,g|1)/* Shannon expansion on 1-cofactors*/

rdf_op(OR,r0,r1)
else

r1 RP(v,f|1,g|1)/* Shannon expansion on 1-cofactor*/

r reduced, unique BDD node for(,r0,r1)

return r

38

Procedure restrict (f,c)

*compute care-space optimization :
*

if c then f else choose some value to minimize the result

*Precondition : c<>0. */
if(f is constant ) or (c==1) return f
if the result of(restrict, f ,c) is cached, return the result
let be the top variable of f and c
if( is not the top variable of f ) /*c has variables not in f. Quantify, then recurse*/
r restrict(f,df_op(OR, c|0, c|1))
else if (c|0= = 0) /* dont care about 0-branch*/
r restrict(f|1, c|1))
else if (c|1= = 0) /* dont care about 1-branch*/
r restrict(f|0, c|0))
else /*normal Shannon decomposition */
r0 restrict(f|0, c|0)) /*0-cofactors*/
r1 restrict(f|1, c|1)) /*1-cofactors*/
r reduced, unique BDD node for (,r0,r1)
return r

4.4.2

L Approche Breadth-First Search

La deuxime approche qui est aussi bien connue et utilise pour la construction du BDD est
l'approche Breadth-First search. Dans cette approche, l'expansion de Shannon pour une opration de
niveau suprieur est excute de la variable la plus haute (position) vers celle qui possde le rang le plus
bas. Toutes les oprations avec le mme ordre de variables seront tendues en mme temps et de la
mme faon. La phase de rduction est excute de bas en haut selon lordre des variables et toutes les
variables de mme ordre seront tendues en mme temps.
Pour illustrer le processus de construction du BDD avec lalgorithme breadth-first, on utilise une
approche graphique pour visualiser le processus de construction du BDD. Figure (4.6) illustre
lexpansion de Shannon pour lopration f op g. Dans la partie gauche de cette figure, loprateur est
reprsent avec un nud doprateur lequel fait rfrence aux reprsentations BDD de f et g comme
des oprandes de cet oprateur. La partie droite de cette figure montre lexpansion de Shannon de cet
oprateur et ou le nud original fera rfrence au top variable . Les deux nouveaux nuds doprateur
cres reprsentent lopration sur les cofacteurs-0 et cofacteurs-1.

Figure 4.6 : Reprsentation graphique de la dcomposition de Shannon

39

La Figure (4.6) illustre les deux rgles utilises dans la phase de rduction. La Figure (4.7.a) montre
le cas o les rsultats de deux branches (bdd0 et bdd1) sont distincts. La Figure (4.7.b) illustre le cas o
les deux branches sont les mmes et donc le BDD rsultant ne dpend pas de la variable .

Figure 4.7 : Opration de La rduction

4.5 Algorithme ITE

On peut manipuler de faon simple les ROBDD laide de la fonction ITE(f,g,h) (If Then Else) qui
est dfinie par : ite( f,g,h) = f.g + f.h (i.e. If f Then g Else h)
Soit x la premire variable (i.e. Ordre(x) = 1) de f,g et h.
Soit z = ite(f,g,h). La fonction z est associe au sommet de variable x et dont les fils implantent ite(fx,
gx, hx) et ite(fx, gx, hx). En effet :
z = x. Z. x + x. Z. x
= x (f .g + f. h)x + x (f.g + f.h) x
= x (f x . gx + fx .h x ) + x (f x. g x + f x. h x )
= ite (x, ite (f x , g x , h x ), ite (f x , g x , h x ))
En plus du calcul rcursif de la fonction ite, nous utilisons des identits remarquables pour viter de
les recalculer chaque fois. Ces identits sont consignes dans ce qui suit:
ite(f, 1, 0) = f ; ite(1, g , h) = g ; ite(0, g, h) = h ; ite(f, g , g) = g ; ite(f, 0, 1) = f
De plus toutes les oprations habituelles peuvent tre traduites en termes de loprateur ite :
Table 4.8: Fonctions Boolennes Pr-calcules et Exprimes sous forme de la fonction ITE

40

Figure 4.9: Lalgorithme du Calcul de la Fonction ITE

Cet algorithme utilise deux tables : Table et Table calcule. Table est un tableau dont chaque ligne
reprsente un sommet (c--d le tableau prcdent). Ses colonnes reprsentent lidentificateur du
sommet, le nom de la variable associe, lidentificateur du fils gauche et lidentificateur du fils droit.

4.6 Ordre Des Variables

Un des problmes lis aux OBDDs qui a t bien mis en valeur par Bryant [Bry86] est
l'ordonnancement des variables de la fonction. En effet, pour une mme fonction suivant l'ordre que l'on
prend sur les variables, la taille de l OBDD peut passer de l'exponentiel au linaire (Figure 4.10).
Il y a plusieurs approches utilises pour le classement des variables. On peut citer quelques-unes :
Approche dynamique [Rud93] : Cette approche consiste faire des modifications directement dans
l'OBDD. En effet, les ordres des variables dans l'OBDD ne sont plus statiques mais dynamiques
(changeant au fur et mesure de la construction de l OBDD).
Approche change de variables [ISY91] : Propose de pondrer la permutation l'aide du concept
d'nergie. Le dplacement des variables dans l'OBDD est assur, comme le ferait un lectron sur les
couches lectroniques d'un atome.

Figure 4.10: L'influence des ordres sur la taille du BDD, applique la formule (x1x2) (x3 x4)
(x5 x6)

4.7 Implantation des techniques de reprsentation et de

minimisation des systmes concurrents

41

Loutil que nous avons dvelopp pour prendre en charge la normalisation au sens de minimisation
des descriptions symboliques des systmes concurrents, nous fournit un graphe ROBDD (Reduced
Ordered Binary Decision Diagram) (Figure 4.11) plus le nombre de nuds de dpart et de fin, le temps
dexcution ainsi que dautres informations sans grande importance. Le fonctionnement dun tel outil
est trs simple, il suffit de lui communiquer la formule logique symbolique qui modlise la structure et
le comportement du systme en question.
Loutil a t crit en Java 1.2 et constitue une partie importante de notre systme de vrification
(Module) pousant par la mme occasion tous les lments quon vient de voir, savoir lalgorithme
ITE, lalgorithme de recherche DFS, la mthode de reprsentation minimale des BDD en mmoire etc.
Il constitue un autre apport dexactitude en plus de loutil SAT construit utilisant le concept des
mthodes gntiques. Pour avoir une ide sur son emplacement dans larchitecture gnrale du systme
global, il suffit de jeter un coup dil sur les modles de vrification des programmes CTL et du Mucalcul, cest justement lors des calculs des point-fixes.

Figure 4.11: Interface Graphique du Module ROBDD

4.8 Conclusion
Dans ce chapitre nous nous sommes intresss un modle de reprsentation et de simplification des
rseaux boolens qui pourraient modliser les systmes ractifs. A travers cette mcanique, nous avons
tent de rpondre certaines exigences exprimes durant tout le projet. En effet :

42

Nous avons montr le bien fond de lutilisation de lutilisation du thorme de Shannon

comme tant loutil de base des BDD qui sans lequel lalgorithme ITE ne pourrait
fonctionner.

Nous avons donn toutes les informations pour la bonne reprsentation et la manipulation
des fonctions boolenne travers les algorithmes RESTRICT et EXPAND.

Nous avons montr dans une telle philosophie deux algorithmes peuvent tre utiliss, lun
bas sur lalgorithme DFS et lautre sur BFS.

Finalement, nous nous sommes intresss limplmentation des BDD, puis des OBDD et
des ROBDD utilisant une procdure intelligente base sur la reprsentation de ces derniers
en mmoire de faon optimale.

CHAPITRE 5

Thorie du Model-Checking

43

5.1 Introduction
Les logiques temporelles les plus connues dentre elles sont CTL et LTL [Pnu77, CE81, Eme96].
Elles sont trs utilises pour la s p c i fication de systmes ractifs et en gnral concurrent.
Elles utilisent un modle simple et disposent d'algorithmes de model-cheking trs puissant
[QS82, EC82, CES86, Eme83]. Les logiques temporelles, sont utilises pour exprimer des
proprits relatives des comportements trs complexes des systmes critiques telles que :
pour to u t c h e min , tout moment s u r d e s c h e m i n s , si une alarme se d c l e n c h e , alors elle
conduit invitablement une r p o n s e , c e qui s ' c r i t AG(alarme AF rponse).
Les logiques temporelles CTL, LTL ou dautres de mme types tel que le mu-calcul
[SE84, Wal93, Koz83, KPS84] et TPA [Lam94], comme elles revtent plutt un aspect
qualitatif ne permettant pas (ou pas facilement) d'exprimer des asp e c t s quantitatifs sur le
temps. Cette limitation est parfois gnante : par exemple, si le fait de vouloir exprimer existe-t-il une
excution menant u n e c e r t a i n e situation avant un dlai maximal disons critique.
Les logiques temporises dites aussi temps-rel (timed logic ou simplement real-time
logic)[AH92, AD94] permettent d'exprimer ce genre de proprits pour un modle de temps
continu, discret ou carrment hybride, sur des automates temporiss. Prenons lexemple quon
vient de citer et exprimons la proprit la rponse se produit moins de 5 units de temps aprs
l'alarme , celle-ci scrit AG(alarme A F 5 rponse). De telles logiques sont actuellement mises
en oeuvre dans des outils tels que HyTech [HHW97], Uppaal [UPPAAL], ou Kronos [Yov97], la
complexit de tel model-checking est au moins PSPACE-dur [ACD93, AL99].
L'un des avantages d e s logiques est qu'elles reposent sur un modle simple et gnral appel
structure de Kripke, c'est--dire un automate pour lequel chaque tat vrifie u n c e r t a i n
nombre de propositions atomiques. Un autre avantage de ces logiques est l'existence d'algorithmes de
model-cheking efficaces.
Formellement, une Structure de Kripke est aussi un automate ou simplement un graphe. Il est admis
que les sommets (nuds ou tats) dans les structures de Kripke, chacun deux doit avoir au moins un
sommet successeur ce qui pousse ce que la relation de transition soit totale.
Supposons que AP soit un ensemble fini et non vide de propositions atomiques utilises pour
dcrire les proprits du systme dtats.
Dfinition 5.1 (Kripke structure) Une structure de Kripke est un quadruplet M = (S, , s0, L ) ou :
- S est lensemble fini des tats du systme, S x S est la relation de transition qui satisfait la
condition s S : sS : (s, s) ,
- L : S 2AP est une fonction dtiquetage qui associe chaque tat un ensemble de propositions
atomiques.
Dfinition 5.2 [Chemin] Un chemin dfinit sur une structure de Kripke est une squence infinie
dtats (s0, s1, s2, ) S tel que (si, si+1) pour tout i 0.
Quant on utilise les structures de Kripke comme formalisme, on doit considrer uniquement les
chemins (excutions) qui commencent partir des tats initiaux (pour le moment lon ne considrera
quun seul tat initial). Pour un chemin donn quon notera = s0 s1 s2 et un indice (entier) i 0,
[i] dnotera le (i+1)ime tat de . En outre on utilisera i pour dnoter le suffixe de obtenu par
suppression de ces i tats, cest--dire i = si si+1 si+2 Nous notons que i[j] = [i+1] et en particulier
0 = . Pour les chemins dune certaine rgularit on crira = (s0) au lieu de = s0 s0 s0 s0
Lensemble des chemins qui commencent partir dun tat s sont dnots Paths(s). Noter aussi que
Paths(s) = si s S0.
On dfinit aussi la fonction dtiquetage (renommage) L utilise pour projeter tout chemin de la
structure comme tant une squence infinie de labels sur les tats. Ces squences de labels peuvent tre
considres comme des mots infinis sur lalphabet des lettres (2AP). Le plus souvent tout sous-ensemble

44

L de (2AP) sera considr comme un langage des mots infinis sur lalphabet 2AP. Dans la suite nous
utilisons LM pour dfinir lensemble des mots gnrs par les excutions dune structure de Kripke M.
Nous dirons alors que LM est gnr par M.
Lexemple suivant dmontre tous les concepts dcrit ci-dessus.

Figure 5.1 : Une structure de Kripke simple

Dans cette structure nous avons les lments suivants :
AP = {p1, p2} ; M = (S, , S0, L) et tels que ;
S = {s0, s1, s2, s3, s4} ; = {(s0,s1), (s0,s2), (s1,s3), (s1,s4), (s2,s2), (s3,s0), (s4, s4)}
s0 = s0 ; L(s0) = {p1} ; L(s1) = {p1} ; L(s2) = ; L(s3) = {p1, p2}, L(s4) = {p2}.
Les deux excutions de M sont : (s0,s1,s3,s0,s1,s3, ) et (s0,s2,s2,s2, )
squences infinies suivantes :

correspondent aux

(L(s0), L(s1), L(s3), L(s0), L(s1), L(s3), ) = ({p1}, {p1}, {p1, p2},{p1}, {p1}, {p1, p2}, )
et (L(s0), L(s2), L(s2), L(s2), ) = ({p1}, , , , .)
Le chemin (s1,s3,s0,s1,s4,s4,s4, ) nest pas une excution car il ne commence pas par ltat s0.
La squence infinie ({p2}, {p1}, {p2},{p1}, {p2}, {p1}, ), nappartient pas au langage LM, M ne
possde pas dexcution de ce type.
Dans ce qui suit, deux types de logiques temporelles seront prsentes, savoir :

5.2 Modles Linaires

5.2.1

La Logique Temporelle Linaire (LTL)

Les logiques temporelles permettent de reprsenter le comportement des systmes ractifs au moyen
de proprits qui dcrivent lvolution du systme. Dans le cadre des logiques temporelles linaires le
temps se droule, comme son nom lindique, linairement. En clair, on spcifie le comportement
attendu dun systme sans relle possibilit de spcifier plusieurs futurs possibles. Dans la section
suivante nous prsentons une logique temporelle linaire propose par Manna et Pnueli [Pnu86]. Cette
logique a depuis t grandement amliore dun point de vue expressif par lajout de nombreux
oprateurs [MP92, MP95]. Mais, les principes de base restent les mme et dans un premier temps nous
nous contenterons de ce langage.

45

Action1

Action2

Action3

Action n

Figure 5.2 : Le droulement temporel dun systme dans une logique linaire temporelle
La signification de formule dans cette logique est dfinit par une relation de satisfaction (dnote |=)
entre un chemin et une formule de la logique (LTL, PLTL, ). Le concept est |= si est
seulement si est valide pour .
Lensemble des formules de la logique temporelle linaire est dfini par induction sur la structure des
formules comme suit. On admettra que AP reprsente lensemble des formules atomiques de la logique
propositionnelle.
Dfinition 5.3 (Linear Temporal Logic) Lensemble des formules de la logique temporelle linaire
est construit des chanes de caractres finies qui peuvent tre obtenues par application des rgles
suivantes :

Toutes les propositions atomiques de AP sont des formules de LTL.

Si est une formule de LTL alors est une formule de LTL.

Si et sont des formules de LTL, alors () est une formule de LTL.

Si est une formule de LTL, alors X est une formule de LTL.

Si et sont des formules de LTL, alors ( U ) est une formule de LTL.

La smantique de la logique temporelle linaire est dfinie sur les squences de sous-ensembles des
propositions atomiques AP comme suit :
Dfinition 5.4 (Smantique de LTL) Soit p AP une proposition atomique, un chemin infini et
, des formules de LTL. La relation de satisfaction |= est dfinie par :

|= p

ssi p L([0]), le premier lment de la squence.

|=

|= ( ) ssi |= ou |= .

|= X

|= ( U ) ssi il existe i 0 tel que i |= , et pour tout 0 j < i, j |= .

ssi non ( |= ).
ssi 1 |= .

Dautres oprateurs logiques et boolens peuvent tre dfinit comme abrviation dans le sens usuel
df

par : T (p p) pour toute proposition atomique.

df

Soit p AP, on dfinit T : la constante boolenne True ; et son cnjugu T ( false )). On
dfinit en outre certaines quivalences en rapport avec la logique propositionnelle.
Intuitivement, de la dfinition 5.4, la satisfaction des formules de LTL dpend seulement du premier
sous-ensemble de la logique propositionnelle dans la squence, seulement si la formule ne contient
aucun oprateurs X ou U. Dans le cas contraire, la satisfaction de la formule dpendra de la squence
entire, du moins dune partie delle. Pour mieux comprendre la notion de squence dun chemin et le
raisonnement sur les oprateurs temporels tel que le X (Next) et le U (Until), par exemple, la formule
X est satisfaite dans une squence infinie si la formule tient compte de la sous squence 1 de .
Donc loprateur X est dit oprateur Next time ou bien oprateur du futur immdiat. La formule
( U ) est satisfaite si et seulement si est valide maintenant ou bien dans quelque temps dans le
future, et est valide jusqu ce que le devient son tour. Dautres oprateurs peuvent tre drivs
de la dfinition de loprateur U.

46

5.2.1.1

Oprateurs Temporels Auxiliaires

Pour soulager la spcification de proprits appropries, quatre oprateurs auxiliaires peuvent tre
introduits. Ces oprateurs sont dfinis en utilisant certains oprateurs dj dfinis auparavant.
Loprateur temporel (quon prononce Always toujours ) et loprateur (prononc eventually
ou Future) sont dfinis comme suit :
df

Loprateur (T U ) ( eventually ),
df

( always ), et loprateur release

df

( R ) ( U ).
Exemple 5.5 (vrification de formule LTL)

Soit AP = {p1, p2}, et = (y0, y1, y2, ) = ({p1}, {p1}, {p1, p2},{p1}, {p1}, {p1, p2}, ) une
squence infinie sur 2AP. Vrifions que cette squence vrifie la formule LTL
p2 utilise pour dire
que p2 est toujours ventuellement vraie dans la squence, qui signifie aussi que p2 est vraie dans la
squence infiniment souvent.
Avant de procder la vrification, on aborde le problme de la simplification sur la structure de la
formule par rcriture, on obtient ainsi :
|= p2
|= (T U p2)
|= (T U p2)
|= (T U(T U p2))
non( |= (T U(T U p2))).
Daprs la smantique de LTL, |= (T U(T U p2)) si il existe un i 0 tel que i |= (T U p2), et
pour tout 0 j < i, j = T. Donc T U(T U p2).
1. Il nexiste pas de i 0 tel que i |= (T U p2) est vraie, donc i |= (T U p2) est vraie pour tout
i 0.
2. Pour tout i 0 tel que i |= (T U p2) il existe un 0 j < i pour lequel non ( i |= T).
En fait, le premier cas est vrai dans la squence suivante. Avant cela nous devons considrer que
pour tout i 0, i |=T :
i |=T
i |= p1 p1
i |= p1 ou i |= p1
i |=p1 ou non(i |= p1),
47

qui est vraie, puisque ou bien p1 yi ou bien p1 yi pour tout sous-ensemble yi 2AP et i 0.
Nous montrons maintenant que pour tout i 0, i |= T U p2. Notons que pour tout k 0, k+3 = k.
Par dfinition, i |=T U p2 si et seulement sil existe un i i telle que i |= p2 et pour tout i j < i,
j |= T. Nous avons montr auparavant et ceci pour tout j 0. Nous savons aussi que
2 |= (p1, p2},{p1},{p1},{p1, p2}, ) |= p2. Parce que k+3 = k pour tout k 0, il sensuit que
2+3k p2 et pour tout i 0 il doit exister un i i tel que i p2, alors p2.
Dans certaines littratures, loprateur du futur est dnot par F au lieu de , loprateur always
est dnot par G pour dire globalement ( Global ) et O est remplac par X. Donc on dfinira F est G
par :
FTU
G F
Loprateur U est appel the strong Until (le plus fort). On dfinit quelque fois the weak Until
(le plus faible) qui dfinit la situation que lorsque hold continuellement ou bien jusqu ce que
holds pour la premire fois ou travers le chemin. Cet oprateur est dfini par :
W = G ( U )
ou de faon quivalente nous aurons :
W = F ( U )
Le dernier oprateur auxiliaire sappelle the release operator dnot R ; il est dfini par :
R = ( U )
Intuitivement il est interprt comme suit :
La formule ( R ) est vraie sur le chemin si est toujours vraie, la ncessit est quil est relcher
aussi vite que devient valide.
Exemple 5.6 G p X(p G p) est une tautologie.
Preuve :
|= G p (X(p G p))

[par remplacement de limplication]

( |= G p X(p G p))

[par smantique de ]

( |= G p |= X(p G p)) [smantique de la conjonction]

((j 0.j |= p) 1 |= p (j 0.(1)j |= p))
smantique de X]
((j 0.j |= p) (j 0.j |= p))

[smantique de G deux fois, conjonction et

[par simple calcul].

Notons que toutes les tapes sont quivalentes, ce qui fait que le chemin inverse est aussi vrai.
5.2.1.2

Axiomatisation

La validit dune formule LTL de la forme peut tre drive en utilisant la smantique de
LTL et en prouvant :
|= si et seulement si |= sur tous les chemins.
Dans le mme sens dide essayons de vrifier lquivalence qui nous parait trs importante
puisquelle sera utilise un peu plus tard, savoir :
U ( X( U ))
Considrons la partie droite, soit :
|= ( X( U ))

48

 [ smantique de et ]
( |= ) ( |= |= X( U ))
[ smantique de X ]
( |= ) ( |= 1 |= U )
[ smantique de U ]
( |= ) ( |= (j 0. (1)j 0k<j. (1)k |= )
[ par calcul en utilisant (1)j = j+1 ]
( |= ) (j 0. j+1 |= 0k<j. (k+1 |= ) |= ))
[ par calcul en utilisant 0 = ]
( |= ) ( j 0. j+1 0k<j+1. (k |= )))
[ par calcul en utilisant 0 = ]
(j = 0. 0 |= 0k<j+1. k |= ( j 0. j+1 0k<j. (k |= )))
[ par calcul des prdicat ]
(j = 0. j |= 0k<j+1. k |= )
[ smantique de U ]
|= U

5.3 Model-checking la Vole

Rappelons-nous que pour reprsenter un systme (programme, protocole, etc.), il nous fallait utiliser
une certaine abstraction que nous avons appel model qui est dfinit par la reprsentation
M = (S, , L) qui peut tre un LTS (labelled transition system) ou bien une structure de Kripke tels que
dfinis auparavant. Nous reproduisons exactement les mmes dfinitions pour S qui reprsente
lensemble des tats dans lesquels le systme peut sy trouver, tant la relation de transition qui
dcrit comment le systme volue dun tat un autre. Nous ne voulons pas pour le moment tre trs
concis sur la nature des tats du systme. Ce qui nous importe cest plutt, la fonction tiquetage qui
associe chaque tat un label, cest--dire une valuation v que nous supposons pour le moment par
mesure dintgrit tre une formule propositionnelle (boolenne). On supposera aussi que v est vraie si
s L(s), autrement v est faux en s. Lide essentiellement qui nous intresse pour le moment, cest de
pouvoir reprsenter le systme et la spcification utilisant le mme langage. Cette ide t bnfique
puisquil existe dans la pratique un certain nombre dimplmentations qui fonctionnent selon ce
principe. Les plus connues sont : SPIN dvelopp au Bell Labs [Hol97, SPIN02] muni de son langage
de programmation formelle [Ger97], qui est un outil trs populaire utilis pour la vrification des
systmes distribus. Il a reu en 2001 le prestigieux prix (System Software Award) du meilleur logiciel
de vrification qui est distribu par ACM (Association of Computing Machinery). Ce type doutils
procde en gnral sur la spcification au sens des automates de Bchi, un puissant concept
thoriquement complet utilis pour dcrire le systme et ses proprits selon ce qui suit.

5.3.1

Les Automates de Bchi

Pour mieux apprhender la notion de vrification telle que dveloppe jusqu prsent, nous devons
nous donner les moyens thoriques pour reprsenter les tats de la spcification. Il sagit donc de
pouvoir reprsenter deux modles M1 et M2 (model du systme et model de la spcification), de les
excuter en parallle de faon ce que, chaque tape (excution) dans M1 (respectivement M2) sera
suivie dune excution dans M2 (respectivement M1).

49

Lune des solutions prsente dans la thorie tant de composer les deux modles (M1 et M2) pour en
crer un troisime (M). Le problme qui se pose dans ce cas tant lexplosion combinatoire
essentiellement lorsque lon utilise des invariants sur les tats. Pour remdier un tel problme, il suffit
dadjoindre la fonction dtiquetage sur les transitions et non plus sur les tats. Intuitivement, un label
sur une transition de s vers s indiquera que le systme empruntera cette transition uniquement que
lorsque la condition sur le label soit vraie. Cette faon de traduire le problme permet maintenant de le
faciliter et permettre ainsi dexcuter en parallle les deux systmes (M1 et M2). Cest--dire, on passera
dun tat vers un autre que lorsque deux transitions de M1 et de M2 soient syntaxiquement quivalentes
(mme label).
Avec ce nouveau type de raisonnement, nous avons besoins de prendre certaines liberts
(respectivement restrictions) pour dire que seulement des excutions dun certain type doivent tre
autorises (acceptes). Dans le mme cadre dide cest uniquement certains tats qui seront notifis par
le titre dtat accept, et quune excution est dite acceptable si elle comporte infiniment plusieurs tats
accepts.
Dans ce qui suit nous dtaillons tous les points qui viennent dtre cits. A savoir la notion de
modle qui sera interprte par un automate de Bchi, de lexcution en parallle de deux modles qui
nest dautre que lintersection dans la thorie des ensembles et ainsi de suite.

5.3.2

Quelques dfinitions de Base

Dfinition 5.7 (Automate de Bchi)[VW86, Var87, SE84, EH00] Un automate de Bchi est un
quintupl A = (S, T, S0, F, ) o

S est un ensemble dtats

S0 S est lensemble des tats initiaux

T S x x S est lensemble des transitions

F S, un ensemble dtats finaux dit aussi tats accepts par lautomate

est un alphabet (alphabet de A)

Dfinition 5.8 (Critre dacceptation de Bchi). Un mot (chane de caractre, string) sur est
reconnaissable par A si la chane des tats visits par lautomate en le lisant en partant du sommet s0,
passe par F infiniment souvent.
Exemple 5.9 Le graphe de la Figure 5.3 reprsente lautomate de Bchi A = (S, T, S0, F, ) dont les
composantes sont dfinies comme suit :

Figure 5.3 : Un automate de Bchi

Dfinition 5.10 Une excution dans A est dfinie par s0

a0

a1

s1L

avec s0S0 .

Dfinition 5.11 Une excution est dite accepte (reconnaissable) par lautomate si s i F infiniment
plusieurs i.
Dans ce qui suit on notera L(B), lensemble des mots sur reconnaissable par lautomate B.

50

Exemple de mot (excution acceptable) reconnaissable par lautomate de la Figure 5.3,

{ p, q} {q, r }

{ p}

{ p, q} { p, q}

{ p, q} { p, q} { p, q} { p, q}

{ p, q}

{q, r}

{ p}

s0 s1 s2 s0 s1s2 L donc le mot sera {p,q}{q,r}{p}{p,q}{q,r}{p}

s0 s1 s1s1s1s1L est une excution non reconnaissable par lautomate.
Exemple 5.12 On considre lautomate de Bchi de la Figure 5.4 ou F = {s1} et S = {s0}.
Lensemble des mots reconnaissable par cet automate est de la forme (a*ba*). Nous pouvons
remarquer que les mots de la forme (a*ba*)a ne sont pas reconnaissables pour cet -mots (un -mot
est reconnaissable sil contient une infinit de b).
Exemple 5.13

Figure 5.4 : Un Automate de Bchi

Figure 5.5 : Un Systme de Transitions

Supposons que p, q, r, s, t soient des propositions atomiques. La satisfaction dune formule de la
logique temporelle linaire (LTL) par le systme (reprsent par le chemin t1(t2t3t4) est dtermine par
le -mot
(1,1,0,0,1)[(1,1,1,0,0)(1,0,0,1,0)(1,0,1,0,0)]
est reconnaissable par lautomate de Bchi obtenu de lautomate de la figure en posant F = S et en
transportant ltiquetage de ltat vers la transition issue de cet tat. On obtient alors lautomate de
Bchi illustr la figure suivante :

Figure 5.6 : Automate de Bchi obtenu de la figure 5.5

Le thorme suivant nous donne le moyen de faire correspondre une formule de la logique
temporelle LTL un automate de Bchi, il en va de mme pour toute formule dune logique linaire.

51

Dans lnonc lon utilise || pour dnoter la longueur dune formule et |S| pour dnoter la cardinalit
dun ensemble S.
Thorme 5.14 (Wolper-Vardi-Sistla) (dans [GPV+95]) Etant donn une formule de PLTL, on peut
construire un automate de Bchi A = (S, T, S0, F, ) avec = 2AP et |S| 2O(||) tel que L(A) soit
exactement lensemble de tous les modles de ..

5.4 LAlgorithme du Model-checking dune Formule de LTL

Soient A et S deux automates qui reprsentent respectivement le systme et la spcification.
Supposons que L(A) et L(S) dfinissent tous les comportements possibles respectivement du systme et
de la spcification. Le problme qui se pose maintenant cest de se donner les moyens thoriques pour
dire que le systme A puisse satisfaire la spcification S (qui scrit A |= S), cest--dire en terme plus
clair dans la thorie des langages, ceci sinterprte par la notion de contenance (containment en anglais)
qui sexprime par L(A) L(S). Malheusement, limplantation dun tel calcul savre tre trs coteuse
puisque la complexit dun tel problme est NP. Jouant sur la notion ensembliste de lintersection de
deux ensembles, le problme de contenance est ramen vers un problme dintersection. Ce qui fait
quau lieu de considrer L(A) L(S) on considrera L(A) L(S) qui est plus simple concrtiser que
celle de linclusion (problme NP) dune part et dautre part, calculer le complment dun automate de
Bchi est difficile. Toutefois il serait meilleur de calculer S plutt que de calculer dabord lautomate
S puis de calculer son complment.
Le model checking suivant permet de rsoudre le problme de la vrification dans le sens dide
dvelopp dans ce cadre.

5.4.1

Transformation dun graphe de Kripke en un graphe de Bchi

Lalgorithme est trs simple, il suffit pour cela de reproduire le graphe de Kripke tel quil est, en
faisant attention de garder les tats et les transitions ainsi que leurs liaisons, de faire glisser les labels
(propositions) qui tiquettent les tats (sommet du graphe) sur les transitions incidentes vers lintrieur,
et les boucles seront tiquetes par la formule de ltat lui-mme. On obtient ainsi le graphe de Bchi
(automate de Bchi).

52

Exemple 5.15

Figure 5.7 : Transformation dune structure de Kripke en un automate de Bchi

5.4.1.1 Calcul de lintersection de deux Automates
Pour vrifier quune spcification est valide, on se ramne dterminer tous les -mots qui satisfont
lautomate obtenu partir de la composition de lautomate qui reprsente le systme (limplmentation)
et celui de la spcification (formule de la logique temporelle)[GPV+95, SB00]. La composition nest
autre que lintersection de deux automates.
Soit A = (S1, T1, S01, F1, ) et B = B = (S2, T2, S02, F2, ), alors L(A) L(B ) est lensemble des
mots reconnaissables par lautomate de Bchi P = A B = (S, S0,T,F,) o
S = S1 x S2 et S0 =
S01 x S02 et T tant la synchronisation de T1 et T2 sur les actions identiques et F = F1 x F2.

5.4.2

Implmentation de la Procdure du Model-checking

Pour implmenter une telle procdure, nous aurons besoin de deux choses: un moyen pour former la
composition parallle de deux automates, et un autre moyen pour vrifier si un automate contient des
excutions dacceptance [SB00, EH00].
Le premier moyen en principe est direct, il suffit de former la composition parallle P = A x B de
deux automates. Pour cela on calcule les lments suivants :
P = A B = (S1 x S2, S01 x S02,T, F1 x F2,)

[le produit synchrone]

a

s 2 s 2'

(s1,s2) p(s'1,s'2 ) s1s1' &

T est dfinit par :

Le deuxime moyen tant de vrifier que L(P) si et seulement sil existe des excutions
a1

a2

a1

a2

s10 s11s12,L et s02 s12 s22,L telle que pour chaque i {1,2}, s0i S0i et infiniment plusieurs des

s0i , s1i,s2i ,L sont dans Fi.

Ce point peut facilement tre prouv. Supposons, que L(P) . Alors il existe une excution
acceptante dans P qui a pour forme :
existe infiniment plusieurs des

a1

a2

(s01,s02) p(s11,s12) p (s12,s22)L , avec (s01,s02)S01 xS02 et tel quil

(s1j,s 2j ) dans F1 xF2 . Lexistence des deux excutions avec la

a

proprit dsire est maintenant immdiate cause de la dfinition de la transition p . De la mme

a

manire nous pouvons vrifier dans lautre sens que (s1,s2) p(s'1,s'2 ) s1s1'

&

s 2 s 2' .

aj +1

Comme

(s1j,s 2j ) p(s1j +1,s 2j +1) pour tout j 0, et (s01,s02)S01 xS02 . Il reste maintenant de montrer que

(s1j,s 2j ) dans F1 xF2 . Comme F1 = S1, alors (s1j,s 2j )F1 xF2 si et seulement si s 2j F2 , et ceci arrive
le plus souvent par supposition.
53

La deuxime partie de notre model-checking permet de dterminer si un automate A possde des

excutions dacceptations, ou, dune faon quivalente, si L(A) . Pour cela, il suffit dimaginer que
lautomate sera reprsent par un graphe orient et ou les sommets sont les tats et lexistence dune
transition suppose lexistence dun sommet initial et un sommet terminal relis par une transition (un
arc) qui est tiquet par une action a. Alors L(A) est vraie si et seulement il existe un chemin s0,
s1, , sk dans A tel que sk soit un tat dacceptation et quil existe un cycle de sk vers sk. Sil existe un
tel chemin et un tel cycle il est claire que L(A) , et que nous pouvons obtenir un cycle dacceptation
en suivant s0 sk et nous rptons ceci en suivant le cycle. Rciproquement, supposons L(A) , et il
X1

X2

existe une excution s0 s1 s2,L Par la dfinition de lexcution dacceptation et par le fait que F
est fini, il existe un cycle de sk vers lui-mme qui contient un tat dacceptation.
En utilisant ce fait, il serait plus judicieux par exemple de rechercher les composantes fortement
connexes. Pour cela, lun des meilleurs moyens qui permet de les dterminer tant celui qui utilise une
procdure base sur une procdure du type le depth-first search (une recherche en profondeur dabord
(dfs)) [HPY98] pour vrifier que sk satisfait les conditions cites plus haut. Cest--dire, en premier lieu,
cest de vrifier que sk est un tat dacceptation, en principe ceci est trivial. Par contre pour vrifier que
sk appartient un cycle, nous seront oblig dutiliser une deuxime procdure dfs qui seffectue dans le
pire des cas en une complexit temps de O(nm), avec n le nombre de sommets (tats) et m le nombre de
transitions. Mais en entrelaant deux dfss nous pouvons rduire cette complexit O(m). Les deux
procdures dfs rcursives qui utilisent une pile sont prsentes comme suit :

Figure 5.8 : LAlgorithme de Recherche des Etats Valides

5.4.3

Transformation dune formule LTL en Automate de Bchi

La procdure de traduction permet de transformer une formule LTL ou PLTL en un automate de

Bchi [GO01]. Une tape prliminaire est alors engage pour nautoriser quun certain type
doprateurs et procder ainsi une forme de simplification de la spcification. Pour cela il est
ncessaire dutiliser les quivalences (LTL) suivantes et de les convertir dans leur forme normale :

54

Fg=1Ug

G g = ( 1 U g)

(f g) = f g

(f g) = f g

f = f

X f = Xf

(f U g) = f R g

(f R g) = f U g

[]f = <>f.

<>f = [] f.

= ( )

<> = (T U ).

[] = (F ).

Transformation de ( []<>P ) ( []<>Q ) par limination de limplication ( []<>P )

( []<>Q )

Elimination de [] et <>

La ngation est pousse vers lintrieur: ( F ( T U P ) ) ( F ( T U Q ) ) devient

(T U (F U P ) ) ( F ( T U Q ) ).

Il est remarquer que les nouvelles formules construites par rcriture ne contiennent plus que les
oprateurs U, R, X, , , et les formules atomiques.
Durant toutes les tapes de construction du graphe (automate), une partie des nuds sera marque
done, qui est un terme anglais pour dire que tout sommet ainsi marqu ne sera ni modifi ni supprim,
la seule possibilit que les arcs partant de ce sommet peuvent tre modifis.
Pour commencer cette construction, nous crons tout dabord deux nuds, init et v0 relis par un
arc. Le champs du nuds init sera vide et v0 aura Old(v0) = Next(v0) = , New(v0) = f . Le nud init
est alors marqu par done.
Le reste de la construction du graphe sexcute en faisant appel la procdure rcursive expand(v0)
suivante :

Figure 5.9 : LAlgorithme EXPAND

La procdure process_formula() modifie les nuds u et fait des appels rcursifs la fonction
expand() qui prend en charge dautres formules. En outre, elle procde par une analyse par cas sur la
structure de g. Les diffrentes situations quelle peut traiter sont :

55

 g = p. Si p Old(u), alors p et p sont supposs tre vraies, ce qui est impossible comme nous
le savons, alors il ne sera pas possible datteindre ce nud ce qui nous oblige de supprimer u ainsi que
les arcs incidents intrieurement u. Dans lautre cas on appelle alors la procdure expand(u).
g = p. Ce cas est similaire au cas pass. Si p Old(u), alors on supprime u et tous les arcs
incidents intrieurement. Sinon on fait un appel expand(u).
g = g1 g2. g1 et g2 doivent tre vrais, on les rajoute alors New(u) et on appelle expand(u).
g = g1 g2. Si lexcution parallle considre u, alors g1 est vrais en u, ou bien g2 est vrais. On
clate alors le nud u pour reprsenter les deux cas. On cre alors deux nuds u1 et u2 avec le mme
champ que u, et on rajoute u1 New(u1) et g2 New(u2). On supprime alors le nud u et pour chaque
arc incident lintrieur, on le duplique pour avoir une copie pour u1 et une autre pour u2. Finalement
on appelle expand(u1) et aussi expand(u2).
g = X g. Ceci montre que X g doit tre vraie en tout tat suivant, alors on rajoute g Next(u).
g = g1 U g2. Nous savons que g1 U g2 = g2 (g1 X(g1 U g2)). Dans ce cas il nous sera possible
de dupliquer en mettant g2 dans New(u1) et (g1 X (g1 U g2)) in New(u2) et en faisant des appels
rcursifs.
g = g1 R g2. Nous avons g1 R g2 = g2 (g1 X(g1 U g2)) = (g2 g1) (g2 X(g1 R g2)). Puis
pour les autres parties nous procdons de la mme par la duplication de chaque sous formule.
5.4.3.1

Comment sy prendre pour appliquer cet algorithme

Pour se faire, on utilisera une table trois cases, quon nommera respectivement par, New, Old et
Next.Puis on procdera comme suit :
Pour les formules composes, on essayera chaque fois de sparer la formule en deux parties. La
premire partie sera tiquete dans ltat courant et la deuxime dans ltat suivant Next .
Prendre une formule de ltat New et la rajouter ltat Old.
Selon la formule, ou bien on fractionne le nud courant en deux nouveaux nuds ou bien une
nouvelle copie du nud sera mise en place.
Exemple 5.16
U est fractionne comme suit :
1. Add to New, add U to Next.
2. Add to New.
Comme U = ( X( U )).
, split (fractionner) :
1. Add , to New.
2. Add to New, to Next.
Comme = ( X( )).
, evolve (se transforme en):
1. Add , to New.
2. X, evolve:
3. Add to Next.

56

5.5 Modles Arborescents

5.5.1 La Logique arborescente CTL
Il est bien connu que cest Amir Pnueli [Pnu77], qui a introduit le premier la logique temporelle
temps linaire (LTL) aussi appele PLTL (Propositional LTL) pour la spcification est la vrification
des systmes ractifs. Comme nous lavons dj dit, la logique LTL est dite linaire compte tenu de la
notion du temps qui est qualitative et considre comme linaire, cest--dire qua chaque moment du
temps il y a seulement un seul tat successeur possible, et donc chaque moment admet un seul futur
possible. Techniquement parl, cette notion de temps linaire est rendue possible grce
linterprtation des formules, dfinie en termes de squences dtats. La logique linaire LTL quoi que
trs utile pour la vrification des systmes ractifs, ne permet pas de fournir les outils ncessaires pour
considrer des situations trs frquentes et plus compliques. A titre dexemple, le fait de dire pour
chaque excution il est toujours possible de retourner ltat initial , toute tentative dinterprter cette
proprit dans la logique LTL choue. Pour viter de tomber dans ce type de problme qui est
dailleurs multiple est trs frquent, Clarke et Emerson [CE81] aux dbuts des annes quatre-vingts
dvelopprent une autre logique temporelle quils ont appel CTL (Computationnal Tree Logic). La
smantique de cette logique nest pas du tout base sur la notion du temps linaire sur une squence
infinie dtats mais sur la notion du temps arborescent (de branchement), dfinie sur un arbre infini
dtats. La notion de temps arborescent fait rfrence qua chaque moment il peut y avoir plusieurs
futures possibles qui diffrent les uns des autres. Donc, chaque moment du temps est reparti en
plusieurs futures possibles, et chaque chemin (path) est suppos reprsenter une seule squence possible
dexcution et larbre qui prend racine en s0, reprsente toutes les excutions infinies possibles obtenues
par dpliage de la structure de Kripke (Figure 5.13).

Figure 5.10 : Une structure de Kripke et son arborescence infinie

5.5.1.1 Syntaxe de CTL

Nous reconduisons dans la logique CTL, presque les mmes lments de base cits dans la logique
linaire (LTL), plus certains nouveaux oprateurs.
Dfinition 5.17 (Syntaxe de CTL) Soit p une proposition atomique. Les formules dans la logique
CTL sont ou bien des formules dfinies sur les tats (state-formulae) ou bien sur les chemins (pathformulae). Les formules-tats satisfont les rgles suivantes :

57

p est une formule-tat.

Si est une formule-tat, alors est une formule-tat de CTL.

Si et sont des formules-tats, alors est une formule-tat.

Si est une formule-chemin, alors E et A sont des formules-tats.

Les formules-tats satisfont les rgles suivantes :

Si est une formule-tat, alors X est une formule-chemin.

Si et sont des formules-tats, alors U est une formule-chemin

Donc CTL fait une distinction entre les formules-tat et les formules-chemin. Intuitivement, les
formules-tat expriment des proprits sur les tats et les formules-chemin expriment leur tour des
proprits sur les chemins. Les oprateurs temporels X et U ont la mme signification que pour la
logique temporelle linaire. Les formules E quon prononce for some paths sont vraies dans un tat
s, sil existe des chemins qui satisfont partant de s. Les formules du type A quon prononce for all
paths) sont vraies dans un tat s si tous les chemins partant de s satisfont la formule . Nous pouvons
navement trouver une relation de dualit entre A et E, similaire la relation qui lie les
quantificateurs existentiels et universels de la logique de premier ordre. De ce fait, nous avons
A E .

5.5.1.2 Smantique de CTL

Exactement comme dans la logique linaire, linterprtation des formules CTL est dfinie en terme
de structure de Kripke. Il nest pas utile de reproduire la dfinition des structures de Kripke et celle des
chemins.
Dfinition 5.18 Pour une structure de Kripke donne M = (S, I, R, Label) et un tat s S, il y a un
arbre infini de racine s tel que (s, s) est un arc dans larbre si et seulement (s, s) R.
Cet arbre est obtenu par dpliage de la structure de Kripke partir du sommet s. Le nombre de degr
extrieur dun nud est calcul partir du nombre de transitions incidentes vers lextrieur de ce nud
dans la structure de Kripke.
Un exemple est donn dans la Figure 5.10. Nous avons gauche la structure de Kripke dun
problme quelconque et droite larborescence infinie de racine s0 (sommet initial). Par convenance,
chaque nud de cette arborescence, on lui adjoint un numro qui indiquera le niveau de dpliage. Les
chemins sont obtenus en traversant larborescence de haut en bas partir du sommet initial (racine). Les
squences suivantes sont des chemins pris dans larborescence du graphe,
s0s1s2s3, s0s1(s2s3) et s0s1(s3s2)*s3.
La smantique des formules CTL est dfinie laide de deux relations de satisfactions (toutes les
deux, seront dnotes par |=). Donc une relation sera utilise pour les formules-tat et lautre pour les
formules-chemin Dans la suite, on utilisera lcriture M, s |= au lieu de ((M, s), ) |=. La
signification dune telle criture est : M, s |= si et seulement si la formule (tat) est vraie dans ltat
s de la structure M. Pour lautre relation |= (sur les chemins), celle-ci est une relation entre la structure
de Kripke, lun de ces chemins et la formule-chemin . On crira dans ce cas M, |= si et seulement
si le chemin dans le model M satisfait la formule . Pour donner plus de clart dans ce qui suit, nous
omettrons chaque fois lcriture de M.
Dfinition 5.19 (Smantique de CTL) Soit p AP une proposition atomique, M = (S, I, R, L) une
structure de Kripke, un tat quelconque s S, et des formulestats de CTL, et une formulechemin de CTL. La relation de satisfaction |= est dfinie pour les formules-tats par ce qui suit :

58

s |= p

si et seulement si (not ssi) p Label(s)

s |=

ssi not (s |= )

s |=

ssi ( |= ) or ( |= )

s |= E

ssi |= pour un certain nombre de chemins Paths(s)

s |= A

ssi |= pour tous les chemins Paths(s).

Pour la relation sur les chemins, la relation de satisfaction |= pour les formules-chemin est dfinie
comme suit :
|= X

ssi

[1] |=

|= U

ssi

(j 0. ([j] (0k<j. [k] ))

Linterprtation en CTL des propositions atomiques, de la ngation et de la conjonction sont dfinies

comme dhabitude sur les tats et non sur les chemins, contrairement leurs interprtations dans la
logique LTL qui est sur les chemins.
La formule-tat E est valide dans ltat s si et seulement sil existe des chemins (pas forcement
tous les chemins) prenant naissance en s qui satisfont . De la mme manire on dfinit A , mais sur
tous les chemins.

5.5.2

Oprateurs Temporels Auxiliaires

Les oprateurs boolens true, , et sont dfinis comme dhabitude.

Soit F = true U , on dfinit alors ce qui suit :
EF E (true U )
AF A (true U )
EF est prononc holds potentially et AF est prononc is inevitable
Linterprtation des oprateurs temporels AX , EF , EG , AF et AG peuvent tre drivs
en utilisant la smantique de CTL.
Exemple de drivation : EG ,
S |= EG
{dfinition de EG}
s |= AF
{dfinition de F}
s |= A(true U ))
{smantique de }
(s |= A(true U ))
{smantique de A U }
( Paths(s). (j 0. ([j]) (0k<j. [k] |= true)))
{s |= true pour tout tat s ; calcul des prdicats}
Paths(s).(j 0. [j] |= )
Donc EG est valide dans ltat s si et seulement si un ensemble de chemins (pas forcement tous)
partant de ltat s tel que pour chaque tat de ces chemins est valide.
Exemple 5.20 Soit la structure de Kripke M (Figure 5.11). Essayons de donner un aperu informel
sur le comportement de chacune des formules suivantes sur chacun des tats et chemins du graphe de
Kripke.

59

Figure 5.11 : Graphe de Kripke de Dmonstration

La formule EX p est valide pour tous les tats du graphe, puisque chacun des tats possde au
moins un successeur qui satisfait p.
La formule AX p nest pas valide au niveau de ltat s0, puisquun chemin possible prenant
naissance en s0 et passant par s3 qui est le successeur immdiat de s0 alors que linvariant de s3 est {q}
qui est diffrent de {p}. Cependant tous les autres tats vrifient cette proprit
La formule EG p est valide dans les sommets s0, s1 et s3, puisque nous pouvons dterminer des
chemins partir de ces trois sommets pour lequel p est globalement valide. Il reste le sommet s2 auquel
Label(s2) est diffrent de p. Ce qui revient dire que EG p nest pas valide en s2.
La formule AG p est valide uniquement pour s3, puisque le seul chemin valide est s3 visitera ce
sommet linfinie. Pour les autres tats il est possible de trouver un chemin qui contiendra le sommet s2
qui ne vrifie pas la condition.
La formule EF(G p) est valide pour tous les tats puisque partir de nimporte quel sommet, un
autre sommet (s0, s1, s3) peut ventuellement tre atteint partir duquel des excutions peuvent prendre
naissance ou tout le long de ces excutions p est globalement valide.
A(p U q) nest pas valide en s3, puisque sa seule excution (s3) natteindra jamais un tat
tiquet par q. Pour ltat s0 le problme ne se pose pas puisque s0 est tiquet par p, donc la formule est
valide jusqu ce quun tat tiquet par q devienne actif, ceci dailleurs se ralise juste aprs avec ltat
successeur qui est s1. Les tats s1 et s2 valident la formule immdiatement puisquils sont tiquets par
q.
La formule E(P U( p A(p U q))) nest pas valide en s3, puisque qu partir de s3 on ne
pourra jamais atteindre un sommet tiquet par q. Pour les sommets s0 et s1, la formule est valide
puisque ltat s2 peut tre atteint partir dun p-path prenant naissance en ces deux sommets, p est
valide en s2 et partir de s2 tous les chemins satisfont p U q, puisque s2 est un q-state.

5.5.3

Axiomatisation de la logique CTL

Nous allons procder de la mme manire que pour la logique LTL, pour affirmer que CTL peut
aussi tre axiomatisable. Nous avons vu, que laxiome le plus important dans la logique LTL
est laxiome de lexpansion :
U ( X( U ))
Dans CTL, des axiomes de ce type existent aussi. Comme dans la logique LTL, nous pouvons
prfixer loprateur U par un quantificateur existentiel et un autre universel, cest--dire quon obtient
E( U ) et A( U ). Le tableau ci-dessous nous fournit un ensemble daxiomes correct sound et
peuvent tre prouvs en utilisant la logique CTL. Pour en tre plus prcis, nous invitons le lecteur
consulter les articles [Eme96, CES86] qui fournissent la base de dmonstration dun systme
axiomatisable de rgles de CTL qui soit correct et complet. Dans ce qui suit, nous allons fournir un
moyen simple pour vrifier quelques axiomes.

60

EF EX(EF )
AF AX(AF )
EG EX(EG )
AG AX(AG )
E( U ) ( EX E( U ))
A( U ) ( AX A( U ))
Table 5.12 : Quelques axiomes dexpansion pour CTL

5.5.3.1 Quelques exemples pour vrifier certains axiomes

1- AF AX(AF ) ?
AF {dfinition de AF}
A(true U ) {axiome pour A( U )}
(true AX A(true U ))) {calcul des prdicats, dfinition de AF}
AX(AF ).
2- EG EX(EG )
EG {dfinition de EG}
AF {rsultat aprs la drivation}
( AX(AF )) {calcul des prdicats}
AX((AF )) {dfinition de AX}
EX((AF )) {dfinition de EG}
EX((EG ).

5.6 Model-checking de CTL

Comme il a dj t introduit, A et E sont les quantificateurs duaux sur les chemins, et G et F sont les
quantificateurs duaux sur les tats. A partir de ces quantificateurs, il est simple de retrouver certaines
lois de De Morgan :
AF EG
EF AG
Aussi, il est vrai que pour un chemin particulier, chaque tat possde un successeur unique, alors X
est auto-dual :
AX EX
Nous savons aussi que
AF A[T U ]
EF E[T U ]
En plus de cela, nous considrons que toutes les quivalences valides de la logique propositionnelle
sont aussi valides pour CTL. En utilisant les quivalences ci-dessus et lquivalence suivante :
U ( U ( )) G

61

On peut r-crire toutes formules CTL en une formule quivalente qui ne contienne que les
connecteurs temporaux EX, EG et EU :
EF E[T U ()]
AX EX()
AG EF E[T U ]
AF A[T U ] EG()
A[ U ] E[ (( U ( ))]
Thorme 5.21 Toute formule CTL est transformable en une formule quivalente qui nutilise que
les connecteurs 0, , , EG, EU et EX.

5.6.1 Calcul des points fixes de fonctions monotones : une approche

pour CTL
Cette partie de notre expos soriente prsenter une autre approche pour mieux expliquer les
logiques modales et temporelles essentiellement, le mu-calcul et la logique CTL [Arn88, EC80, AN92].
Lessentiel des lments de base sera puis de la thorie des travaux de Kozen [Koz83, KP84].
Dfinition 5.22 (Ordre Partiel) Une relation binaire A x A est une relation dordre partiel si et
seulement si elle est rflexive, anti-symtrique et transitive. Soit, pour tout a, a, a 5 A :

a a (rflexivit)

(a a a a) a = a (anti-sysmtrie)

(a a a a) a a (transitvit).

La paire (A, ) est un ensemble dordre partiel (poset). Si non( a a) et non(a a) alors a et a sont
dits incomparables.
Dfinition 5.23 (Least upper bound) Soit (A, ) un ensemble dordre partiel et A A (une partie de
A).

aA est une borne suprieure de A si et seulement si aA : a a.

aA est la plus petite borne suprieure (least upper bound) de A, not A, si et

seulement si (1) a est une borne suprieure de A et (2) a A, a est une borne
suprieure de A a a.
Le concept de borne infrieure et de plus grande borne infrieur (greatest lower bound), not A,
peut tre dfinit de la mme manire que pour la borne suprieur et le plus ptite borne suprieur.
Soit (A, ) un ordre partiel.
Dfinition 5.24 (treillis complt)[Tar55] (A, ) est un treillis complt si pour tout A A, A et

A existent.

Un treillis complet possde un et un seul plus petit lment et un et un seul plus grand lment.
Dfinition 5.25 Soit S, un ensemble et g : 2S 2S. On dira que f est monotone si pour tout
X, X S on a, X X f(X) f(X).
Dfinition 5.26 Soit S, un ensemble et g : 2S 2S. On dira que X est un point fixe de f si f(X) = X.
Un point fixe est un plus petit (resp. plus grand) point fixe de f quon note (resp. ), si pour tout
point fixe de f, Y X (resp. X Y).
La monotonicit de S est suffisante pour assurer lexistence dun plus petit et dun plus grand point
fixe f :

62

Thorme 5.27 Toute fonction monotone dfinie sur une lattice complte possde une lattice
complte de points fixes.
Preuve : cest une consquence du thorme de Kleene qui est prsent juste aprs.
Thorme 5.28 (Knaster-Tarski). Si f : 2S 2S est monotone, alors :

f possde un plus petit point fixe donn par I{X S: f(X) X } ;

f possde un plus grand point fixe donn par U{X S:X f(X)}.

Dfinition 5.29 Une fonction f : 2S 2S est -continue (resp. -continue) si pour toute suite [Xi]
croissante (resp. dcroissante) pour linclusion, on a :

f'(U i X i)=U i f(X i)

respectivement

f'(I i X i)=I i f(X i)

Remarque 5.30 Toute fonction continue est monotone car
X X X = X X
f(X) = f(X) f(X)
f(X) f(X).
De la mme faon pour X = X X f(X) f(X).
Remarque 5.31 Si f est monotone on a toujours

f'(U i X i) U i f(X i)
et

f'(I i X i) I i f(X i)

Preuve : Nous savons que pour tout i on a

f(X i) f(U i X i) et donc,

f(I i X i) f(I i X i) .

U i f(X i)

X i U i X i alors par monotonocit pour tout i

f(U i X i) . De la mme manire on dfinit

Remarque 5.32 Si f et non seulement monotone mais continue alors le plus petit (resp. plus grand)
point fixe de f peut se reprsenter comme limite de ses itrations ime, f i dfinies comme suit pour tout
XS:
f0(X) = X et f i+1(X) = f(f i(X))
Thorme 5.33 (Kleene)[Kle52]. Si f est continue alors
i

Uf

f =

()

f =

If

(S)

Preuve : Puisque f est continue alors la suite {fi()}i0 est croissante et on aura aussi,
f(

Uf

()) =

Uf
i

i +1

() =

Uf

()

qui est un point fixe de f. Cest le plus petit point fixe de f car si X est un point fixe il vient alors :
= f0() X
Si f0() X alors fi+1() f(X) = X.

63

Thorme 5.34 Soit f : 2S 2S monotone o S est fini de cardinalit n alors f = fn() et f =

f (S).
n

Preuve : Soit ni la cardinalit de fi(), alors la suite {ni}i0 est majore par n et est croissante. Soit k
le plus petit entier tel que nk = nk+1 alors jk fk() = fj() car fi() = fi+1() fi+1() = fi+2(). En
particulier,

Uf

() = fk() = fn()

puisque k n (car nk n).

Lalgorithme suivant prsente le pseudo-code pour le calcul itratif du plus petit point fixe.

Ce deuxime algorithme calcul le plus grand point fixe :

Exemple 5.35 : Soit M une machine dtats finis reprsentant le comportement dun systme ractif.
Nous allons vrifier la validit de la formule temporelle AG(a \/ c). Pour cela nous utilisons la structure
de M (Figure 5.16) et lalgorithme qui calcule le plus petit point fixe.

Figure 5.13 : Structure dun FSM Relative Un Systme Ractif

Aprs plusieurs itrations et suite au calcul de H(AG( a c)) ={ 2, 3, 4}, nous concluons que les
tats tats S2, S3 et S4 vrifient la proprit AG(a \/ c).
On procdera de la mme manire pour le calcul du plus petit point fixe la seule diffrence que
lensemble X soit initialis lensemble S.

64

Dans ce qui suit, on sera intress par lintroduction des fonctions monotones dfinies sur les treillis
des formules de CTL.

5.6.2

Caractrisation des points fixe pour CTL

Nous venons de voir quil tait possible de calculer les points fixes dun treillis en utilisant une
procdure itrative trs simple. Dans ce qui suit deux procdures similaires seront utilises pour le
calcul des fonctions caractristiques de certains oprateurs de la logique CTL. Le principe est le mme,
en plus de cela on tiendra compte des points suivants :
Une lattice complte doit tout dabord tre dfinie sur les formules logiques de CTL telles que
lexistence (unicit) du plus petit et plus grand point fixe qui doit tre garantie. La base de cette lattice
est une relation dordre sur les formules CTL.
Les fonctions monotones sur les formules CTL doivent tre dtermines telles que les formules
E( U ) et A( U ) soient caractrises comme des plus petits (plus grands) points fixes de ces
fonctions. Pour se faire laximatisation de CTL est plutt ncessaire pour introduire ce qui suit.
5.6.2.1

Un Treillis Complt des formules-CTL

La relation dordre partiel sur les formules de CTL est dfinie en associant chaque formule
lensemble des tats s de S dans la structure de Kripke M pour lesquels Label(s) = . Cependant est
identifi comme lensemble :
[||] = {sS | M, s |= }.
On dfint lordre par :
si et seulement si [||] [||].
Nous pouvons remarquer, qu ce point de raisonnement la relation correspond dsormais la
relation dfinit sur les sous-ensembles. Notons que la notation de [||] [||] est quivalente
. De ce fait, (CTL, ) est dfinit comme tant une lattice complte. La limite infrieure (lower
bound) est la conjonction qui sera construite autour de :
[||] = [||].
et la borne suprieure correspond la disjonction :
[||] = [||].
Comme lensemble des formules CTL est ferm sous la conjonction et la disjonction, il sensuit que
pour tout et , leur borne infrieure et suprieure existent. Le plus petit lment de la lattice (CTL,
) est false, cependant [|false|] = . De faon similaire, le plus grand lment dans (CTL, ) est true,
donc [|false|] = S, lensemble des tats de M.
Rappelons un rsultat vu dans la section (CTL) matrialis par laxiome dexpansion existentiel,
savoir :
E( U ) ( EX E( U ))
La nature rcursive de cette rgle suggre de considrer la formule E( U ) comme le point fixe de
la fonction F dfinie comme suit :
F(Z) = ( EX Z)
aprs remplacement de E( U ) par Z juste pour donner une forme simple la formule.
De la mme manire, nous pouvons exprimer les autres oprateurs de CTL par cette notion de point
fixe. Par exemple loprateur Until scrira :
FEU(Z) = [||] ([||] {sS | R(s) Z }).

65

Le thorme suivant gnralise les rsultats de calcul des oprateurs CTL comme un calcul de point
fixe :
Thorme 5.36 Pour toutes formules et nous avons :
[|E( U )|] est le plus petit point fixe (lfp) de FEU(Z) = [||] ([||] {sS | R(s) Z })
[|A( U )|] est le plus petit point fixe de FAU(Z) = [||] ([||] {sS | R(s) Z})
[|E |] est le plus grand point fixe de FEG(Z) = ([||] {sS | R(s) Z })
[|AG )|] est le plus grand point fixe de FAG(Z) = ([||] {sS | R(s) Z})
[|EF )|] est le plus petit point fixe de FEF(Z) = ([||] {sS | R(s) Z})
[|AF )|] est le plus petit point fixe de FAF(Z) = ([||] {sS | R(s) Z}).
5.6.2.2 Algorithme du Model Checking Symbolique
Lalgorithme du Model Checking Symbolique procde comme suit :
Soit p un ensemble dtats (graphe dtats) et p sa reprsentation symbolique Boolenne sous
forme dun ROBDD , nus avons alors
p= (v 1 , v 2 ,..., v n ) p
Pour une relation R sur les tats, il existe une seule reprsentation R telle que
R= (v 1 , v 2 , ..., v n , v 1 ,v 2 , ..., v n ). R
Ces rsultants permettent de calculer la forme symbolique des oprateurs temporels de CTL, par
exemple :
Le calcule de EXp seffectue comme suit :
EXp= v. v(R( v, v) p( v)), ou v=( v 1 , v 2 , ..., v n ), v=( v 1 , v 2 , ..., v n )
R(v, v) (relation) = R
p(v) (expression logique) = p, ou p = p[ v i v i ]

EXp = v. v( R p).

Algorithme: Soit p la reprsentation boolenne de p;

Dbut;
p:= p[v i v i ];
S(v) := v (R p);
Check if initial state s 0 S(v).
Fin.
Exemple 5.37

Figure 5.14 : Circuit Analogique dun Compteur et son Graphe dEtat (FSM)

66

De la spcification du Compteur nous tirons les paramtres suivants :

State variables: v 0 , v 1 , {v = (v 0 , v 1 )}
Variables dEtats Next: v 0 , v 1 , {v = (v 0 , v 1 )}
Relation de Transition: R = (v 0 v 0 ) (v 1 (v 0 v 1 ))
Vrification de : EX( v 0 v 1 )
= v. (R p)
= (v 0 , v 1 ). (R (v 0 v 1 ))
= (v 0 , v 1 ). ( [( v 0 v 0 ) (v 1 (v 0 v 1 ))] (v 0 v 1 ) )
= v 0 . (( v 0 v 0 ) (v 0 v 1 ) v 0 )
= v 0 (v 0 v 1 )
= v 0 (( v 0 v 1 ) (v 0 v 1 ))
=v0v1
Ce rsultat signifie que ltat (0, 1) satisfait EX( v 0 v 1 )
Vrification de : EF( v 0 v 1 ) = y. (( v 0 v 1 ) EXy)
1 [0] = (v 0 v 1 ) EX0 = (v 0 v 1 )
2 [0] = (v 0 v 1 ) EX( v 0 v 1 )
= (v 0 v 1 ) ( v 0 v 1 ) {from the result of EX( v 0 v 1 )}
=v1
3 [0] = (v 0 v 1 ) EX( v 1 )
= (v 0 v 1 ) [ (v 0 , v 1 ). ( R v 1 ) ]
= (v 0 v 1 ) [ (v 0 , v 1 ). (( v 0 v 0 ) (v 1 (v 0 v 1 )) v 1 ) ]
= (v 0 v 1 ) [ v 0 . (( v 0 v 0 ) (v 0 v 1 )) ]
= (v 0 v 1 ) [( v 0 (v 0 v 1 )) ( v 0 (v 0 v 1 )]
= (v 0 v 1 ) (v 0 v 1 ) = (v 0 v 1 ) ( v 0 v 1 ) (v 0 v 1 ) = v 0 v 1
4 [0] = (v 0 v 1 ) EX( v 0 v 1 )
= (v 0 v 1 ) [ (v 0 , v 1 ). ( R (v 0 v 1 )) ]
= (v 0 v 1 ) v 0 (v 0 v 1 )
= (v 0 v 1 ) v 0 ( v 0 v 1 ) (v 0 v 1 ) =1
EF( v 0 v 1 ) ={( 0, 0), (0, 1), (1, 0), (1, 1)}. Ce rsultat signifie que tous les tats vrifient la
proprit en question.

5.6.3

La gnration de Contre-exemples

Tous les model-checker(s) et sans exception utilisent des mcanismes qui leur permettent de vrifier
la validit dune formule temporelle. Dans le cas affirmatif, un message simple et court est
communiqu lutilisateur disant que le programme en question est valide, cest--dire que la formule
est vrifie sur la structure de Kripke. Dans le cas contraire, le model-checker imprime un contre-

67

exemple qui montre clairement la non-validit de la formule. A partir de ce contre-exemple, le

concepteur revoit le modle et lui apporte les corrections ncessaires et ainsi de suite.
Dans ce qui suit, nous allons donner le concept mme de la notion trs importante dans les modelchecking de contre-example.
Un contre-example est suppos tre une squence finie ou infinie dtats qui indiquent clairement
pourquoi la formule en question nest pas valide (refuse). Par exemple, considrons la formule AG p
prise dans ltat initial (notre exemple test de la Figure 5.11). Cette formule est refuse et un contreexemple possible qui est le chemin s1s3s0s2 (Figure 5.11). Nous pouvons voir que label(s2) est diffrent
de p, ce qui revient dire que la formule AG p nest pas vrifie en s2, et donc elle ne lest pas sur le
chemin et par la mme occasion AG p est refuse sur tout le graphe de Kripke. Nous pouvons
remarquer que comme AG p est considr sur un tat initial qui est dailleurs le prfixe dun chemin
dexcution satisfaisant AG p, donc son quivalent EF p. Si nous voulons gnraliser ce rsultat,
nous pouvons dire que pour les formules du type AG , un contre-exemple est une squence qui
conduit un tat qui pour label . De faon similaire, le contre-exemple relatif la formule AX
est une squence satisfaisant EX . En gnral, un contre-exemple dune formule quantifie
universellement, serait un tmoin quantifi par loprateur existentiel et vice-versa. Notons, quil est
impossible de gnrer des squences de contre-exemple pour les formules du type E lorsque la
vrification choue, puisque E est refuse si et seulement si aucun chemin ne vrifie . En revanche,
en cas de succs, lexcution peut tre retourne

5.7 Vrification des Systmes Temps-rel

Dans la suite de ce chapitre nous tudions la logique TCTL [ACD90, Alu91, HNS+92] qui est
lextension de CTL permettant dexprimer des proprits temps-rel. Une faon simple dintroduire le
temps explicitement dans la syntaxe consiste borner la porte dans le temps des oprateurs temporels.
Pour bien comprendre lutilit dune telle logique, prenons le fait dcrire en CTL p qui exprime
quil est toujours possible datteindre un tat qui satisfait la proprit p. Cette proprit ne nous
renseigne gure sur le temps qui va scouler pour la ralisation dune telle proprit. Lextension de
CTL en TCTL permet justement de considrer ce type de proprits. Par exemple nous pouvons crire
< 3 p pour exprimer quil existe une excution o la proprit p est vraie avant 2 units de temps.
Dans la littrature plusieurs autres notations (approches) ont t introduites pour prendre en charge les
systmes temporiss, nous pouvons citer les travaux de Alur [Alu98], Henziger et al. [HHW97] Manna
et Pnueli [Hal93], de Sifakis et al [HNS+94]., Alur et Henzinger [AH90, AFH91], Bery et Al. [BB91].
Une autre possibilit pour la spcification des contraintes temporelles des systmes ractifs, nintroduit
aucun oprateur nouveau, mais au lieu de cela, on utilise une variable appele now juste pour
mmoriser le temps qui passe. Cette approche est appele Explicit-clock approach. La premire ide
dune telle approche fut introduite dans [Har88] puis amliore est appele Real-time Temporal Logic.
Pour bien comprendre ces deux approches et les comparer, prenons un exemple simple. Considrons la
rponse q un stimulis p qui doit seffectuer dans au plus 3 units de temps. Cette proprit sexprime
dans la premire approche par p 3 q .
Dans la deuxime approche, cette proprit scrit par :
(p now = t) (q now t + 3),
Linvariant t dans ce cas est associ ltat p.

5.7.1

Modlisation des systmes temps-rel

Nous dfinissons la smantique formelle des systmes tempsrel comme un ensemble de squences
dexcutions qui seffectuent en deux tapes. La premire tape, introduit la notion dabstraction des
systmes de transitions temporises et identifie les squences dexcutions dun systme quelconque
(temporis). Dans ltape 2, la notion de systme temps-rel concret est aborde pour montrer que les
68

systmes temps-rel peuvent tre modliss par les systmes abstraits. La prsentation de ces deux
notions sera explicite travers des exemples.
5.7.1.1

Automates Temporiss

Les logiques temporelles quon a cit auparavant, sont des logiques interprtes sur les graphes de
Kripke qui permettent de dcrire comment volue un systme ractif dun tat vers un autre tat. Les
aspects temporiss sont jusqu linstant non couverts, cest--dire quaucune information na t
prsente pour modliser en tant que quantit matriel prendre en compte. Si nous voulons par
exemple reprsenter le temps quun processus doive mettre pour rsider dans un tat, ceci pour le
moment est un petit peu impossible.
Les systmes ractifs qui dans leur ensemble sont caractristique temps-rel doivent ragir dans le
temps, ils sont de fait des systmes temps-rel critique. Le comportement de tels systmes est alors
soumit des contraintes temporelles. Pour mieux exprimer ce type de comportement, prenons le cas
dun train qui sapproche dun passage niveau. Il est par consquent essentiel quune fois le train soit
dtect une distance connue, la barrire du passage se refermera de suite pendant un certain temps qui
doit tre connu lavance de faon ce que les automobilistes sur lautre route soient empchs de
traverser le passage. Prenons un autre exemple, il est impratif que la dose qui doit tre injecte par un
dispositif de radiation (radio-thrapie) un patient cancreux ne dpassera jamais un laps de temps, ne
serait-ce trs petit, ce qui forcement peut causer la mort.
En dfinitive, comme le temps est dune importance vitale aux systmes ractifs, il est essentiel que
les contraintes temporelles du systme doivent tre absolument assures. Dans ce cas de figure, le
comportement du systme sujet de telles contraintes doit absolument tre vrifi. Cette vrification
utilise des algorithmes bien spcifiques dpendant de laspect temps. Un grand nombre dalgorithmes et
de systmes se trouvent de fait explor. Nous citons titre dexemple Uppaal [UPPAAL, LPY97], Step
[STEP], Lustre [Rat92], Kronos [KRONOS] etc.
Les ingrdients essentiels utiliss dans les model-checking temporiss sont (1) un langage de
description du modle, (2) un langage de spcification des proprits et (3) des algorithmes de
vrification.
Pour mieux situer notre prsentation des model-checking temps-rel quelques lments doivent tre
tout dabord introduits. Nous prsenterons un type particulier dautomate dit temporis, qui est un
automate tats finis dont les transitions sont tiquetes par des variables appeles horloges (clocks)
utilises pour mesurer le passage du temps.
5.7.1.1.1

Elments de Base des Automates Temporiss

Un automate temporis est utilis pour modliser un systme temps-rel critique. Par consquent, il
est essentiel de dfinir le temps gnr par une horloge (clock).
Dfinition 5.38 (Clock) Une horloge est une variable prenant ces valeurs dans IR+.
Dans la suite, les lettres x, y et z seront utilises pour reprsenter des variables de type clocks
(horloges). Un tat de cet automate dfinit ltat actuel de la location plus les valeurs courantes des
variables clocks.
Les horloges peuvent tre initialises zro quand le systme procde une transition. Une fois
initialises zro, les variables horloges incrmentent leurs valeurs implicitement dune unit de temps
et ceci simultanment pour toutes les horloges. La valeur dune horloge un moment prcis fournit le
temps pass depuis son initialisation. Informellement, ces horloges peuvent tre considres comme des
chronomtres qui voluent indpendamment les uns des autres. Le plus important dans tous ces
comportements cest le systme global qui possde quant lui sa propre horloge appele aussi lhorloge
globale laquelle toutes les autres horloges se rfrent.

69

Le systme volue donc en restant carrment dans une location (tat), sinon il peut se dplacer vers
une autre location empruntant une transition. Le passage sur une transition est instantan est suppos ne
pas prendre de temps (free of time). Les contraintes sur les horloges sont utilises pour permettre le
franchissement ou non des transitions, ce sont des gardes (guards or enabling conditions). Pour le
moment et par simplicit les conditions dautorisation (enabling conditions) sont supposes ne dpendre
que des horloges, mais en ralit le problme est autre, cest--dire que le passage peut dpendre aussi
dautres facteurs. Des invariants sur les horloges sont aussi utiliss pour limiter le temps quil faut
mettre pour rester dans une location. En dautres termes, les invariants et les conditions de passage
(guards) sont des conditions utilises sur les horloges.
Dfinition 5.39 (Clock constraints). Soit C un ensemble dhorloges, et soit x une horloge de C
(xC) et c un nombre naturel. Les contraintes sur les horloges satisfont les rgles suivantes :

x < c et x c sont des contraintes sur les horloges.

Si est une contrainte horloge alors est aussi une contrainte horloge.

Si et sont des contraintes horloges, alors est une contrainte horloge.

Toute autre formule nest pas une contrainte horloge.

Lensemble des contraintes sur les horloges est dnot Constraints(C).

Dans ce qui suit nous considrons les abrviations comme x c pour (x < c) and x = c for x c
x c. Le choix de contraintes lgales est trs important. Nous pouvons par exemple autoriser laddition
de contraintes (e.g x < c+d | d IN) sans causer de problme. Par contre laddition x+y 3, risque de
crer un problme et le model-checking devient indcidable. Aussi, si c est un nombre rel tel que x
2, alors le domaine ainsi utilis sera un domaine dense (continu) et le problme devient de fait
indcidable. Cependant c de prfrence doit tre un nombre naturel. La dcidabilit ne sera pas affecte
si c doit tre un nombre rationnel puisque c peut tre converti en un nombre naturel. Nous pouvons
aussi autoriser dautres variantes de c et chaque fois de choisir le bon multiplicateur.

70

Figure 5.15 : Trois automates pourvus dune seule horloge et diffrentes contraintes sur les
transitions
Dfinition 5.40 (Automate temporis) Un automate temporis A est un sixtuplet (L, I, C, , Label,
inv) avec :

L, un ensemble non-vide et fini de location.

I L, lensemble de locations initiales.

C, un ensemble fini dhorloges.

L x (Constraints(C) x 2c) x L, la relation de transition

L a b e l : L 2 AP, une fonction dinterprtation sur L

inv : L Constraints(C), une fonction dassignation des invariants.

Un automate temporis peut tre assimil une structure de Kripke quipe dun ensemble C
dhorloge. Les transitions sont tiquetes par de couple (, C) ou est une contrainte sur les horloges
,C
et C C est un ensemble dhorloges. Par la suite, on adoptera lcriture l
l ' au lieu de (1, , C,
l') . Linterprtation intuitive de cette criture est que lautomate peut voluer de la location l vers
la location l lorsque la contrainte devient vraie. Aussi le dplacement dune location l vers la
location l rinitialise toute horloge de C zro. La fonction Label possde la mme fonction que
pour les structures de Kripke telle que vu auparavant. Finalement, la fonction inv affecte un invariant
toute location du systme. Pour toute location l, inv(l) dfinie la dure du temps qui doit passer dans la
location l. Une fois que inv(l) devienne invalide la location l doit tre libre immdiatement. Si une

71

telle situation nest plus possible peut tre quil ny a plus une transition qui doit tre emprunte et
comme le temps passe inluctablement, alors une telle situation est dite timelock.
Pour mieux reprsenter graphiquement les automates temporiss, nous adopterons les conventions
suivantes. Les cercles dnoteront les locations (tats) et les transitions sont reprsentes par des flches.
Les invariants sont crits lintrieur des locations sinon sur le cot, sauf si aucune criture nest
prsente, dans ce cas la location est true dans toutes les situations. Les transitions (flches) sont
quipes dtiquettes qui consistent dune contrainte sur les horloges (optionnelle) et dune autre qui
reprsente la variable horloge qui doit tre rinitialise (optionnelle), spares par une ligne droite. Si la
contrainte sur lhorloge est gale true et quaucune variable horloge ne doit tre initialise alors la
transition est libre de toute indication.
Exemple 5.41 La Figure 5.15-(a) reprsente un automate temporis trs simple pourvu dune seule
horloge x est dune location quipe dune boucle. La transition peut tre traverse si la valeur de x
est au moins gale 2, et quand ceci est possible lhorloge x est r-initialise 0. La Figure 5.15-(b)
prsente un exemple dexcution de cet automate en donnant les valeurs du temps selon x. Chaque
fois que la valeur de x est au zro, lautomate procde un dplacement de la location l vers ellemme. Aussi compte tenu que la valeur de linvariant qui est true sur l, ceci permet au temps de
progresser sans restriction aucune.
Procdons un petit changement en incorporant un invariant x 3 dans la location l, ceci conduit
au fait que x ne pourra plus voluer librement. Si x 2 (enabling constraint) et x 3 (invariant) la
transition dans ce cas doit tre traverse (Figure 5.1(c) et (d)).
Observons que le mme effet ne peut pas survenir en changeant la contrainte sur lhorloge
2 x 3 et en gardant linvariant true. Dans ce cas la transition de sortie ne peut tre traverse que
pour le cas 2 x 3, mais ceci peut ne pas se faire en laissant passer le temps (figure 5.15-c et f).
De cet exemple, il est clair que les horloges prennent des valeurs relles continues par morceaux
et la discontinuit du temps peut survenir lorsquune transition est traverse.
Les horloges peuvent tre initialises des temps divers, ce qui en fait, exclu toute limite de
leur diffrence. Ceci nest pas possible pour le cas dun systme temps discret puisque les
valeurs des horloges sont des multiples de un click (une unit).
Example 5.42. Figure 5.16 reprsente lautomate temporis dun interrupteur. Deux locations sont
tout fait distinctes l1 = {off} et l2 = {on}, et deux variables dhorloge x et y. Au dbut, toutes les
horloges sont initialises zro.

Figure 5.16 : L automate temporis dun interrupteur

Linterrupteur peut tout instant rester dans la position (location) on pourvu quil reste sur le on.
Comme les deux horloges voluent au mme temps et avec le mme taux, lautomate passe de la
position on la position off exactement 9 units de temps aprs que linterrupteur sera pass de off
on. Lhorloge x retient le temps depuis la dernire fois que linterrupteur est pass on. La transition
portant la contrainte sur lhorloge x 2 modlise la condition de passage vers la location on. La
variable horloge y est utilise pour compter le temps depuis la derrire fois que linterrupteur est
pass de off vers le on, donc, il contrle aussi lextinction de la lumire.

72

5.7.1.1.2

Smantique des Automates Temporiss

Lexemple de la figure 5.16 dmontre que lautomate temporis est dtermin par :

Sa position actuelle (location)

La valeur courante de ces horloges

En fait, lautomate temporis est assimil un systme transitions tiquetes, pourvu dun
nombre infini dtats (possiblement) et dun nombre de transitions branchement infini
(possiblement).
Dfinition 5.43 (Clock valuation) Une valuation dhorloge v pour un ensemble C dhorloges
est la fonction v : C IR+, affectant chaque horloge xC sa valeur courante v(x).
Supposons que Val(C) dnote lensemble de toutes les valuations dhorloge sur C. Un tat de
A est la paire (l, v), ou l est une location dans A et v une valuation sur C, lensemble des
horloges de A.
Exemple 5.44 Considrons lautomate de la Figure 5.16. Quelques tats de cet automate sont les
paires (off, v) telles quavec v(x) = v(y) = 0 et ltat (off, v') avec v '(x) = 4 et v'(y) = 13 et ltat
(on, v") avec v" (x) = 2.7 and v" (y) = 13.
Nous remarquons que le dernier tat nest pas accessible.
Soit v une valuation dhorloge de C. Pour un nombre positif d, la valuation de lhorloge v+d
dnote que toutes les horloges ont augment de d units. Ceci est dfinit par (v+d)(x) = v(x)+d
pour toutes les horloges x C. La valuation de lhorloge re-initialise x, et la valuation v avec
lhorloge x, est dfinie par :

(reset x in v) = v(y) if
if
0

y x
y= x

Exemple 5.45 Reprenons notre exemple et considrons les valuations v and v'. La valuation
v+9 est dfinie par (v+9) (x) = (v+9) (y) = 9. Dans la valuation reset x in (v+9), lhorloge x
reois la valeur 0 et lhorloge y la valeur 9. La valuation v' sera gale (reset x in (v+9)) + 4.
Nous pouvons maintenant donner un sens la notion de validit pour une contrainte horloge.
Ceci seffectue exactement de la mme manire que pour la logique temporelle simple en
dfinissant une certaine relation de satisfaction |= qui est une relation entre les valuations
horloges et les contraintes horloges.
Dfinition 5.46 (Evaluation of Block constraints) Pour tout x C, v Val(C), et soient c
un nombre naturel et , Constraints(C) nous avons:
-

v |= x c

iff v(x) c

v |= x < c

iff v(x) < c

v |=

i f f (v |= )

v |=

i f f ( v |= ) ( v |= )

Pour la ngation et la conjonction, les rgles sont identiques celles de la logique

propositionnelle. Pour vrifier que x c est valide dans v, il serait alors simple de vrifier que
v(x) c. Il en est de mme pour x < c.
Exemple 5.47 Considrons la valuation v, v+9 et reset x in (v + 9) de lexemple 5.42.
Supposons que nous voudrions vrifier la validit de = x 5. Il sensuit que v |=, et v(x) =
v(y) = 0. Nous avons (v+9|= ), comme (v+9)(x) = 9 >5, il sensuit alors que reset x in (v+9)
|= .

73

5.7.2

Systmes de Transitions Temporises

Linterprtation des automates temporiss [AD90, Alu98, AH92] est dfinie en terme de
systme de transitions infinies (S, ), avec S, le nombre des tats (paires de location et de
valuation dhorloge) et tant la relation de transition qui dfinie que le systme sera en mesure
dvoluer dun tat un autre. Cette relation de transition est tout fait diffrente que celle
dfinie pour les automates temporiss. Nous savons dj que lautomate temporis se dplace
dun tat un autre uniquement sous les deux conditions, savoir (1) en traversant une transition
de lautomate ou bien (2) en laissant le temps passer en restant dans la mme location. On
rencontre alors deux types de transitions; lune valeurs discrtes et lautre valeurs continues
prenant ses valeurs dans lensemble des nombres rels positifs.
Dfinition 5.48 S o i t A = (L, I, C, , Label, inv) un automate temporis. Le systme de
transitions tiquetes associ lautomate A quon dnote par [A], est dfinie par (S, I', ) ou
- S = { (1, v) L x Val(C) | v |= inv(1) }
- P = { ( l o , v o ) | l o I } e t v o ( x ) = 0 pour tout x C
La relation de transition S x (IR + {*}) x S est la plus petite relation dfinie par les rgles :
*

1. (1, v) (l', reset C' in v) si les conditions suivantes sont respectes :

,C'

(a)

l l

(b)

v |= , et

(c)

(reset C in v) |= (inv(l)
d

2. (l, v) (l, v + d) , pour les valeurs de d positif et la condition suivante soit

vraie: d d. v+d |= inv(1).
a0

a1

Dfinition 5.49 (Chemin) Un chemin de A est une squence infinie s 0 s 1 s 2 . Telle

ai

que s i s i+l pour tout i 0 .

a0

a1

Dfinition 5.50 (Elapsed time on a path) Pour un chemin = s0 s1 s2 et i un nombre naturel,

on dfinie le temps coul entre s0 et si dnot (, i), le temps accumul depuis s0 jusqu ce que le si
eut t atteint (continu ou discret).
Exemple 5.51 Rappelons lexemple de linterrupteur de courant.
3

= ( O f f , v 0 ) ( O f f , v 1 ) ( o n , v 2 ) ( o n , v 3 ) ( o n , v4) (on, v 5 )
2

(o n , v 6 ) (on, v 7 ) ( O f f , v 8 ) . . .
avec vo(x) = v o (y) = 0, v l = vo+3, v2 = reset x, y in v l , v3 = v2 +4, v 4 = reset x in v 3 , v 5 = v 4 +1,
v 6 = v 5 +2, v 7 = v 6 +2 and v 8 = reset x in v 7 .
v0 v1

v2 v3 v4 v5 v6 v7 v8

Table 5.17 : Calcul du Comportement dune excution

74

La transition (off, vl) (on, v 2) est par exemple possible puisquil existe une transition
de la location off vers la location on, aussi comme v 1 |= x 2, et puisque v 1(x) = 3, et v2
|= in v(On). Nous avons aussi par exemple que (Q, 3) = 7 and (Q, 6) = 12.
Une autre possibilit du comportement de linterrupteur, cest de rester dans la location off
infiniment longtemps lorsque lhorloge prend ses valeurs dans IR+. De faon similaire, il peut
rester dans la position on infiniment longtemps. Ce comportement est caus par le fait que
inv(of) = inv(on) = true.
Dfinition 5.52 (Time-divergent)[ACH+95] Un chemin est dit divergent si la limite

(, i) = .

limi

Lensemble des chemins divergents prenant naissance en s sont dnots Paths'(s). Un

exemple dun chemin non time-divergent est un chemin qui visite un nombre infini dtats
pendant un temps born. Par exemple, le chemin
2 1

2 k +1

2 2

= s 0 s 1 s 2 s k s k+1
nest pas divergent, puisquun nombre infinie dtats est visit pendant un intervalle de temps
[1/2, 1]. L'automate temporis est exclu totalement de tel chemin (zenoness paths).
Dfinition 5.53 (Non-Zeno timed automaton) [AH92] Un automate temporis A est dit nonzeno si partir de nimporte quel tat de cet automate un nombre de chemins divergents
peuvent prendre naissance.

5.7.3

Composition dAutomates Temporiss

Pour pouvoir raliser la composition de deux automates temporiss, nous devons adopter
quelques conventions. Nous supposerons que sur les transitions on aura une condition qui
autorisera le passage plus un ensemble dhorloge qui peuvent tre r-initialiss pouvant tiqueter
les transitions. Les actions sont supposes prendre leurs valeurs dans un ensemble E dalphabet.
Maintenant les transitions sont tiquetes par le triplet (a, , C ) ou a est une action, la
condition de passage et lensemble dhorloges C . Laddition des actions nous aide
spcifier les systmes temporiss comme une composition de ces derniers.
'

'

Dfinition 5.54 (Composition dautomates temporiss) Soient A i un ensemble dautomates

temporiss (S i , Li , Ii , Ci , i , Labeli , i n v i ) . Pour i = 1, 2 et C l C 2 = . L a composition de
A l et A 2 , dnot A l A 2 , est lautomate temporis ( l 2 , L 1 x L 2 , I l x I 2 , C l C 2 , , Label,
inv) ou :
est la plus petite relation de transition dfinie par les rgles suivantes :

Pour a 1 2 ,
a1,1,C1

a1, 2,C 2

l1 1l'1, l2 2 l'2
a1,1 2,C1UC2
(l1,l2) (l'1,l'2 )
a1,1,C1

Pour a l \ 2 :

Pour a 2 \ 1 :

l1 1l'1
a1,1,C1

(l1,l2) (l'1,l2)

75

a 2, 2,C 2

l'
(l ,l ) (l ,l' )
l2
2

2
a 2, 2,C 2

Label( 1 1 ,1 2 ) = Label l (1 1 ) Labe1 2 (1 2 )

5.7.4

inv(ll ,12 ) = invl(l1) inv2(l2)

La Logique Temporelle Temporelle (TCTL)

5.7.4.1 Syntaxe et smantique de TCTL

Les formules de TCTL [AD90, ACD90] sont construites partir des propositions et de contraintes
sur les horloges au moyen doprateurs logiques, dun oprateur dinitialisation dHorloge not z., et de
deux oprateurs temporels nots AU et EU.
Intuitivement, un tat q satisfait la formule E[1 U 2] sil existe une squence partir de q pour
laquelle la formule 1 est continuellement vraie jusqu un tat qui satisfait 2.
Un tat q satisfait A[1 U 2] si pour toute squence partir de q, 1 est continuellement vraie
jusqu un tat o 2 est vraie.
Loprateur dinitialisation z. sert introduire une horloge auxiliaire z C qui permet de mesurer le
temps coul partir de ltat prsent. Dans la formule z., les occurrences de z dans sont lies par
loprateur z. Lorsque la formule z. est interprte sur un systme temporis T, nous exigeons que z ne
soit pas une horloge de T, cest--dire, si T est le modle dun graphe temporis G dont lensemble
dhorloges est C C, alors z C.
Dfinition 5.55 Les formules de TCTL son dfinies par la syntaxe suivante :

::= p | | | | z. | E[ U ] | A[ U ]
o p est une formule propositionnelle, x,y,z C, cZ et {<,}.
Les formules de TCTL sont interprtes sur les tats dun systme temporis.
Les formules E[ U ] et A[ U ] sont dfinies exactement comme en CTL.
Dfinition 5.56 Pour un systme temporis T = (Q,,qI), un ensemble de squences T, un
tat qQ et une formule de TCTL, la relation s, |= est dfinie par induction sur de la faon
suivante :

s, |= p

ssi pLabel(s)

s, |=

ssi v w|=

s, |=

ssi (s, |= )

s, |= 1 2

ssi (s, |= 1) ou (s, |= 2)0

s, |= z.

ssi s, reset z in |=

s, |= E(1 U 2] ssi PM(s).(i,d)Pos(). ((i,d), +(,i) |= 2 ((j,d) =

(i,d). (j,d), +(,j) |= 1 2))
s, |= A(1 U 2] ssi PM(s).(i,d)Pos(). ((i,d), +(,i) |= 2 ((j,d) =
(i,d). (j,d), +(,j) |= 1 2))

(i,d) (i,d) ssi (i<j) ou ((i=j) et (d<d)).

Avec s : une location, : la valuation dune formule horloge, PM ensemble des chemins de sommet s
initial, Pos() position dans le lexcution, (,i) : temps coul depuis la dernire fois.
Exemple 5.57

AG [send(m) AF<5 receive(m)]

La rception du message m se fera juste avant 5 units de temps aprs son envoie.
5.7.4.2 Oprateurs drivs
A[1 U7 2]
76

z in A[(1 z 7) U 2]

EF<5

z in EF[ z < 5].

Lensemble caractristique dune formule relativement lensemble de squences , not [||],

est :
[||] = {qQ| q|=}
i.e., lensemble des tats qui satisfont relativement .
Dans ce qui suit il est ncessaire daprs la dfinition de la relation de satisfaction pour les formules
1u2 et 1u2, que la formule 12 soit vrifie le long de la squence, au lieu dexiger que
seulement 1 soit vrifie comme dans le cas de CTL pour viter des anomalies dues la densit du
temps.
Exemple 5.58 Considrons la formule z.((z < 2 p1)u(z = 5 p2)).
En appliquant la dfinition ci-dessus, q satisfait la formule sil existe une squence (q[z :=0])
telle que :
Il existe i 0 et (q,i)(), tels que q(z) = 5 et q(p2) = true, q(z) est le temps t coul depuis le
dbut de la squence. Par consquent, la proposition p2 est satisfaite exactement 5 units de temps aprs
le dbut de la squence.
De plus, tout tat (q,j) qui procde (q,i), satisfait q(z) < 2 ou q(p1) = true ou q(z) = 5 et
q(p2) = true, q(z) est le temps t coul depuis le dbut de la squence. De plus t t, par
consquent, la proposition p1 est vraie pour 2 t 5. En effet, puisque les transitions temporelles ne
changent pas les valeurs des propositions, la proposition p1 doit tre satisfaite aussi linstant 5.
Donc la formule exprime la proprit suivante : il existe une squence o la proposition p2 est vraie
linstant 5 et la proposition p1 est continuellement satisfaite dans lintervalle de temps [2,5].
Les oprateurs temporels additionnels comme , , et sont dfinis comme des abrviations
partir des oprateurs temporels u et u de la faon suivante :

pour trueu

pour trueu

pour

pour

5.8

Conclusion

Nous venons de traiter dans ce chapitre deux points importants qui se rsument en des modles de
vrification des systmes ractifs, les premiers indpendamment de laspect implicite du temps et les
deuximes sont les systmes ractifs temps-rel. Dans la premire catgorie de model-checking, nous
avons abord les modles linaires bass sur une procdure simple qui procde tout dabord par
simplification syntaxique sur les termes puis par rduction axiomatique sur les quations. La deuxime
catgorie dfinie le systme comme une structure de Kripke, la transforme (cette dernire) en automate
gnralis qui sont tour est transform en automate de Buchi. La vrification seffectue sur le graphe
de la composition de limplmentation avec celui de la spcification.
La deuxime catgorie procdait sur les modles arborescents en utilisant la logique CTL sur les
modles de Kripke.
Enfin, nous avons prsent une technique de pointe pour reprsenter les automates temporiss et les
graphes de transitions tiquetes par des contraintes sur les arcs et des invariants sur les tats. Le
modle de vrification tant bien entendu TCTL.

77

CHAPITRE 6

La Logique de Rcriture, Maude et Fullmaude

78

6.1 Introduction
Nous abordons dans cette section un modle de calcul bas sur la rcriture comme modle de
base des machines squentielles et parallles. A lorigine, la rcriture est apparue et utilise comme
une technique de preuve en logique quationnelle et aussi comme un outil dexcution de
spcifications. Durant le dbut des annes quatre-vingts, plusieurs ides sur limplmentation de la
rcriture ont apparu dans plusieurs crits, essentiellement dans [ODo77, ODo85] qui est la base
de plusieurs implmentations tels OBJ [GW88]. Rcemment, plusieurs systmes bass sur la logique
de rcriture ont pris naissance, constituant des outils trs puissants utiliss pour les calculs de
spcification mais aussi de vrification. Maude [CDS+99], [CDS+00a], ELAN [BKK96] et CafeObj [FD98] sont les trois systmes les plus performants, certes ils sont diffrents dans leur style de
programmation, mais ils se basent sur le mme principe, cest--dire quils utilisent la logique de
rcriture en tant que model de calcul plus des stratgies. Naturellement dautres aspects thoriques
sont venus se greffer sur le noyau (rewrites core), telles que la rflexion, lorient objet, la rcriture
conditionnelle, Membership equational etc. Nous verrons, tous ces lments un peu plus tard quand
on prsentera le systme MAUDE.
Cette section prsente un aperu gnral de la logique de rcriture ([Mes00, Mes98, Mes92,
MM96, CDE+00, CDE+99, CDM+00, GM88] pour une introduction la logique de rcriture et ces
applications), le langage Maude [CDE +99, CDE+00a, CDE+00b], le langage Full-Maude et son
systme [CDE+99, Dur99]. Nous supposons que le lecteur est familier avec les concepts de base
des spcifications algbriques dont une partie sera introduite juste aprs. Pour mieux apprhender
cette notion, le lecteur est invit consulter louvrage de Wirsing [Wir90], les travaux de
Kosiuczenko [SK00, KW00, KW97a, KW97b, OKW96, KW96] et lexcellent travail de
Harman [FH98, HT96, Har00]. Nous attirons aussi lattention du lecteur pour bien comprendre
cette section, certaines notions sur la thorie de rcriture des termes (term rewriting) sont
ncessaires. Un travail colossal dans ce sens t ralis par Klop dans [Klo92] sans oublier les
travaux de Huet et Dershowitz [DJ87, DJ90, HO80,HH80, Hue80] sur la rcriture. Aussi pour
que les lecteurs se sentent laise en lisant cette section, quelques lments fondamentaux seront
introduits, essentiellement la rcriture, les systmes algbriques, la logique de rcriture et
naturellement certaines dfinitions et thormes trs importants seront prsents.

6.2 La rcriture
6.2.1 Quelques concepts fondamentaux
Le concept des systmes de rcriture TRS (Termes Rewriting System) est en gnral, paradigmatique,
surtout quand il s'agit des problmes lis aux procdures de calcul (computationnal). Depuis pratiquement
un sicle le TRS le plus connu ft le -calcul. Il a t trs utilis dans la logique mathmatique. Un peu
plus tard, les mmes modles ont figur dans les travaux de Plotkin [Plo77] pour dcrire les smantiques
dnotationnelles dans les langages de programmation. Plus rcemment, la logique combinatoire
catgorielle mergea conduisant une connexion entre la thorie des catgories et la spcification des
tapes lmentaires dans les calculs des machines.
Les TRSs sont des systmes attractifs du fait d'une reprsentation simple des syntaxes et des
smantiques. Cette simplicit facilite l'expression de la notion de satisfaction dans l'analyse mathmatique
ainsi que la conception des machines parallles. Ils jouent un rle trs important dans l'analyse et
l'implmentation des types de donnes abstraits pour mettre en place les moyens de vrification des
proprits de consistance, de calculabilit, de dcidabilit ainsi que la dmonstration de thormes.
Dans ce qui suit nous allons introduire quelques notions pour dfinir les TRS 's en tant quoutils pour la
reprsentation (spcification) des systmes parallles et concurrents. Tous ces lments constituent une

79

approche importante pour mieux apprhender la logique de rcriture. Nous dmontrons aussi, que la
logique de rcriture est lassemblage des systmes de rcriture et des spcifications algbriques.
6.2.1.1

Dfinitions de base

Dfinition 6.1 (Oprateurs) F est un ensemble doprateurs (symboles de fonctions) muni de la

fonction arit : F N qui associe un symbole de fonction f darit du symbole f. Fn d signe le sousensemble de fonction darit n.
Nous dfinissons les termes qui sont construits sur des oprateurs plus un ensemble de variables.
Ayant un ensemble doprateurs F et un ensemble de variables X, nous pouvons dfinir des expressions
construites sur des oprateurs dfinis.
Dfinition 6.2 (Termes) Les termes sur F sont dfinis comme un ensemble Ter(F,X), par les rgles :

Chaque variable xX est un terme de Ter(F,X),

Si t1, ,tn sont des termes de Ter(F,X), respectivement, et si fFn, alors f(t1, ,tn) est un terme
de T(F,X).
Lensemble des variables dun terme t est not par Var(t). Lensemble de terme clos (termes sans
variables) est not T(F). Un terme peut tre vu comme un arbre o les feuilles sont des constantes
(oprateurs darit 0) ou des variables et les nuds internes vus comme des oprateurs darit strictement
positive. Afin de dcrire la position dun nud dans cet arbre, nous dfinissons la notion doccurrence ou
de position.
Dfinition 6.3 (Occurrence) Une occurrence ou position dans un terme t est une suite p dentiers
positifs dcrivant le chemin de la racine du terme t ou sous terme cette position dentiers positifs
dcrivant le chemin de la racine du terme ou du sous terme cette position not t|p.
Dfinition 6.4 (F-Algbre) Une F-Algbre A est un ensemble non vide de valeurs A et une
interprtation de F est note (A,(F)), (F) est not FA et linterprtation du symbole f est note fA.
Dfinition 6.5 (Identit) Une identit (galit) est un couple (t, t) avec t, t ter(F, X), not t = t.
Dfinition 6.6 Soit un ensemble dgalits de E et lensemble des termes Ter(F,X), la thorie
quationnelle de E, not TH(E) est lensemble dgalits obtenues par application des rgles dinfrence
dcrites dans le systme.
Dfinition 6.7 (Algbre-quotient des termes) Soit F, X un ensemble de variables et E la plus petite
congruence contenant lensemble dgalit E. Alors lensemble quotient des termes T(F,X)/E est
lensemble TE(F,X) = {<u>E | u T(F,X)} telle que <u>E tant la classe dquivalence dfinie par
<u>E = {v | v T(F,X), v E u}.
Dfinition 6.8 Une algbre A est un modle de laxiome s = t, si pour toutes les interprtations des
variables de s et t, on a (s) = (t). Une algbre A est un modle de E si elle est un modle de tous les
axiomes de E. A |= s = t si s = t est valide dans A. Lensemble des modles de E est not MOD(E).
Dfinition 6.9 (Systme Abstrait de rduction) Un systme de rduction abstrait ARS (Abstract
Rduction System) est une structure A = <A, ()I > ou A est un ensemble (pour le moment
quelconque) et est une squence de relations binaires dfinies sur A, appeles rductions dites aussi
relations de rcriture.
Par la suite une rduction une seule tape note est remplace par .
Un ARS avec une seule rduction (rgle) est dit systme de remplacement ou bien systme de
rduction, si (a, b) , on crit a b et nous disons que b est one-step (-)reduct de a.
Dfinition 6.10 (Fermeture rflexo-transitive) La fermeture reflexo-transitive de s'crit a , b et
est dfinie s' il existe une squence de rduction finie (possiblement vide) a a o , a l ,. ... , a n b
(la relation dfinie lidentit des lments de A) et b est dit -rduit de A.

80

A partir de l, on dfini la relation d'quivalence qui s'crit = appele aussi relation de convertibilit
(convertibility relation). Il nous est aussi possible maintenant d'crire certaines proprits dfinies par:

La fermeture rflexive de est not

La fermeture transitive de ,, est note +

La relation inverse de est note

L'union de est note .

La composition de o o si il existe a,b, et c de A tel que a c b.

Si et sont des relations de rduction sur A, on dit que commute faiblement avec si
a,b,cA dA (c a b c, d + b).
La relation est dite confluente ou de Church-Rosser (CR) si elle vrifie a,b,cA dA
(c+ a , b c, d + b).
Dfinition 6.11 (Ordre partiel) Un ordre partiel (RPO) not f sur un ensemble S est une relation
binaire et irreflexive sur S. Lensemble S est dit partiellement ordonn. Lordre f est total si pour deux
lments distincts t1, t2 de S, t1 f t2 ou bien t2 f t1.
Dfinition 6.12 (Ordre lexicographique sur les mots) soit p un ordre sur un ensemble E. Lordre
lexicographique plex sur E* est dfini e1 en plex l1 lm ssi e1 p l1 ou bien e1 = l1 et
e2 en p l2 lm, ou bien n = 0 et m > 0.
Dfinitions 6.13 Soit A = <A , > un ARS. Nous disons que a A est une forme normale s'il
n'existe aucun b A telle que a b.

A (ou ) est inductive si pour toute squence de rduction (possible infinie) a0a1, il existe un
a A tel que an , a pour tout n.
A (ou ) est branchement finit (FB) si pour tout aA lensemble des rduction one-step de a,
{ bA | a b}, est fini,

Si la relation inverse de est FB, on dit que A (ou ) est FB-1.

Un ARS qui est confluent et qui se termine ( CR et SN ) est dit complet ou bien canonique.

6.3 Notions de base des systmes de rcriture

6.3.1 Syntaxe des systmes de rcriture
Dfinition 6.14 On dfini un systme de rcriture par un TRS, c'est--dire la paire ( , R ) forme d'un alphabet
( signature ) est d'un ensemble de rgles de rduction ( rgles de rcriture ) R.. Cette signature est dfinie par :

Un ensemble infini dnombrable de variable xl, x2, .... aussi dnots par x, y, z, x', y'...

Un ensemble de symboles de fonctions non vide (symbole d'opration) dnots F, G, , ou

chaque symbole d'opration est quip d'une arit (nombre naturel) qui peut tre 1-aire, binaire,
n-aire, mais aussi 0-aire (symbole de constante).
Dfinition 6.15
inductivement par:

81

On dfini aussi l'ensemble des termes (ou expressions) de par Ter( ) qui est dfini

x, y, z Ter ( )

Si F est un symbole d'oprations est tl,,tn Ter (E) ( n > 0) alors F(tl, .. ,tn) Ter( ) et
t i ( i = 1,,n) sont les arguments du dernier terme.

Dfinitions 6.16

Termes clos : Les termes qui ne contiennent pas de variables sont dits termes clos (Ground
Terms) et TerG(E) est dit l'ensemble des termes clos (Ground Termes).

Termes linaires : Ce sont les termes qui contiennent une seule variable.

Contexte : Se sont les termes qui contiennent une occurrence d'un symbole spcial [] dnotant
une place vide. Un contexte est gnralement dnot par C[]. Si t Ter() est t est substitu
dans [], le rsultat C[ t] Ter( ) ; t est dit sous terme de C[t] (ou symbole dans le terme).

Exemple 6.17 Soit = {A,M,S,O}, les arits sont 2,2,1,0 respectivement. Alors A(M(x,y),y) est un
terme non-linaire, A(M(x,y),z) est un terme linaire, A(M(S(0),0),S(0)) est un terme clos,
A(M([],0),S(0)) est un contexte, S(0) est un sous-terme de A(M(S(0),0),S(0)) possdant deux
occurrences : A(M(S(0),0),S(0)).
Dfinition 6.18 (Substitution) Une substitution est une application de Ter( ) vers Ter( )
satisfaisant: s. On crit alors t au lieu de (t).
Dfinition 6.19 (Rgle de rcriture) C'est la paire (t, s) de termes Ter(). Elle peut aussi tre
crite comme t s et recevra si ncessaire un nom r: t s .
Nanmoins deux conditions doivent tre imposes:
1. La partie gauche ne doit pas tre une variable; on dit partie gauche ou bien LHS (left-hand-side).
2. Les variables dans la partie droite RHS (Right-hand-ride) doivent tre contenues dans t.
Une rgle de rduction r: t s dtermine un ensemble de rcriture t r s pour toutes les
substitutions . Le cot gauche (LHS) t est appel le Redex (Reducible expression) est plus
prcisment r-redex. Un redex t peut tre remplac par son contractum s l'intrieur d'un contexte
C[]. Et cette opration est dite tape de rduction ou bien rcriture en une seule tape (one step
rewriting) C[t ] r C[s].
Thorme 6.20 Soient R1 et R2 deux TRS. R1 R2 (ou est la relation de disjonction) est
confluent si et seulement si R1 et R2 sont confluents.
Termes clos ( GROUNDS) (t s ou t et s sont tous deux des termes clos) + confluence implique la
dcidabilit.
Thorme 6.21 (Toyama, Klop et Barendrest)[TKB89]. Soient R1 et R2 deux TRSs linaires
gauche, alors R1 R2 est complet si et seulement si RI et R2 le soient tous les deux.
Dfinitions 6.22
Une rgle de rcriture est une rgle `collapsing' (rduction) si s est une variable.

Une rgle de rcriture t s est une rgle duplique si certaines variables ont plus
d'occurrences dans s que dans t.

6.4 Spcification quationnelle (syntaxe-smantique)

6.4.1 Notions Gnrales
Dfinition 6.23 Une spcification quationnelle est juste un TRS sans orientation.
Plus prcisment une spcification quationnelle est la paire (, E) ou est une signature (alphabet)
et E est l'ensemble des quations de la forme s = t entre les termes s, t Ter(E).
Si une quation s = t est drivable partir des quations dans E, on crit:
(, E) |-- s = t

82

ou

s = E t.

Formellement la drivabilit est dfinie par application des rgles dinfrence du systme suivant
(Table 6.1).

(, E) |-- s = t

(,E ) s=t
(,E ) s =t

(,E ) s=t1,K,(,E ) sn =tn

(,E ) F(s1,K,sn)= F(t1,K,tn)

(,E)

t =t )

(,E )

t1 =t2 , (,E ) t2 =t3

(,E ) t1=t3

(,E )
(,E )

s =t
t =s

si s = t E
pour toute substitution
pour tout n-aire F

Table 6.1 : Systme d'Infrence

Dfinition 6.24 Si est une signature, une -algbre A est un ensemble A munit dune fonction
FA : An A pour tout symbole de fonction F, (si F est dpourvue dargument, alors F est une
constante, donc FAA.). Les variables contenues dans les termes s et t sont universellement
quantifiables et si s et t appartiennent Ter() et s'ils sont valides dans A, on crit : A |= s = t pour
dire que s = t est valide dans A.
Dfinition 6.25 A est dit model dun ensemble E dquations, si toute spcification quationnelle
(,E) quon notera par Alg(,E) est la classe de toutes les -algbres A telles que A |= E, au lieu
dcrire A Alg(,E), A |= F, ou F est un ensemble dquations dfinit entre les -termes on
crira (,E) |= F.
Le thorme suivant d Birkoff [Bir35] est un thorme trs connu qui nonce la compltude
dune spcification quationnelle.
Thorme 6.26 Soit (,E) une spcification quationnelle . Alors pour tous s, t Ter() :
(, E) |-- s = t

(,E) |= s = t .

Le fait davoir un systme dquations qui soit complet, donc qui soit SN + CR est trs important
dans la thorie quationnelle, ceci tmoigne bel est bien de la finitude des transformations que
subiront les quations. En vrit, un algorithme simple peut tre trouv pour vrifier cela, il sera
construit autour des points suivants :
Rduire s et t en vue dobtenir leurs formes normales s et t
Comparer s et t : s =R t si et seulement si s t.

6.4.2 La dduction dans les Systmes de rcriture

La rcriture est lorigine une mthode de preuve en logique quationnelle. Dans cette logique
les axiomes sont des quations et les thormes sont dduits des axiomes par une rgle dinfrence
trs simple qui est le remplacement dgaux par des gaux. Un exemple simple peut tre introduit,

83

cest celui des fonctions sur les entiers sexprimant alors sous forme dquations entre termes (avec
variables) :
x+0=x

(I)

x + s(y) = s(x + y)

(II)

qui sont deux axiomes quationnels dfinissant laddition sur les entiers. Un thorme lmentaire de
ce systme daxiomes est le suivant :
s(x) + 0 = x + s(0).
En effet, s(x) + 0 = s(0) daprs laxiome (I) utilis de gauche droite, s(x) = s(x + 0) toujours
daprs laxiome (I) utilis de droite gauche cette fois-ci, enfin s(x + 0) = x + s(0) daprs laxiome
(II) utilis de droite gauche.
Ce type de thorme est appel thorme quationnel. Malheusement lobtention de tels thormes
nest pas toujours aise, il va falloir chaque fois, choisir les bons axiomes et aussi de bien les
ordonner.
Le remplacement des gaux sappelle rcriture, et la mthode qui consiste choisir un sens
dutilisation des axiomes, de gauche droite ou de droite gauche tant la base de la rcriture. Une
fois le choix fix, laxiome en question devient une quation oriente et sera appele rgle de
rcriture. Un terme qui ne peut tre rcrit est dit terme irrductible ou en forme normale. La
rcriture en elle-mme est un processus indterministe et ce qui fait quun terme pourra donc avoir
plusieurs formes normales. En gnral, la proprit la plus intressante tant la confluence qui stipule
que le calcul du rsultat ne dpend aucunement du choix de la rgle de dpart, cest--dire que
nimporte quelle rgle nous conduit directement vers la mme forme normale. En gnral daprs le
thorme de Church-Rosser, un systme de rcriture qui possde la proprit de terminaison (qui est
en gnrale indcidable) et celle de confluence est dite convergente. Il est donc clair que dans ce cas
on est ramen remplacer lide de preuve par celle de calcul des formes normales des termes dune
quation.
Comme nous venons de noter que la confluence est une proprit indispensable, mme si le
systme ne lest pas, alors on essaie en utilisant une procdure trs connue appele la procdure de
compltude de Knuth et Bendix [KB70], qui ajoute les paires critiques non convergentes au systme
de rcriture initial en les orientant de manire conserver la proprit de terminaison.

6.5 La logique de rcriture

6.5.1 Introduction
La logique de rcriture est dfinie comme une logique de changement dans laquelle sa partie
dynamique est spcifie par des rgles de rcriture conditionnes et tiquetes [Mes00, Mes98,
Mes92, MM96]. Par contre la partie statique est spcifie par des quations. Une signature dans la
logique de rcriture est une thorie quationnelle (,E), ou est une signature quationnelle
(alphabet) et E un ensemble de -quations. La rcriture opre sur les classes dquivalence de termes
modulo E.
Soit une signature (,E), les squents en logique de rcriture sont de la forme
[t] E [t] E ,
ou t et t sont des -termes qui peuvent contenir des variables, et [t]E dfinie une classe
dquivalence du terme t modulo le systme dquations E. Une thorie de rcriture R est un
quadruplet R = (,E, L , R) ou une signature (ranked alphabet) de symboles de fonctions, E est
lensemble des -quations, L est lensemble des tiquettes et R tant lensemble des paires
R L x T , E (X) 2 ou X = { x 1, . . . , x n , . . . } est un ensemble dnombrable, possible infinie de

84

variables. Les lments de R sont appels les rgles de rcriture. Une rgle ( l , ( [ t ], [ t ]) ) est
alors considre comme un squent tiquet qui prend la forme l : [t] [t].
Pour indiquer que {x1, ... , xn} est lensemble de variables composant les termes t ou t ', en crit
alors
l : [t(x 1, . . . , x n) ] [ t ' (x 1, . . . , x n)],
ou de manire abrge on utilise la notation l : [ t ( x ) ] [ t ' ( x ) ] .
Soit une thorie de rcriture R, on dit que [t][ t ' ] e s t u n (concurrent) R rewrite, et on
crit R |- [t] [t'] si et seulement si [t] [t'] peut tre obtenu par application des rgles de dduction de
la figure 6.2 ( nous supposerons que tous les termes sont bien-forms et que t ( w i /x i ) dnote la
substitution simultane de w i pour x i dans le terme t):

Figure 6.2 : Systme de rgles de Rcriture de Base

La logique quationnelle (modulo un ensemble daxiome E) peut tre obtenue partir de la
logique de rcriture en rajoutant la rgle suivante,
5. Symtrie
Nous pouvons remarquer que si lon rajoute cette nouvelle rgle au sous-systme des
rgles 1-4, les squents drivables dans la logique quationnelle deviennent toujours bidirectionnels, dans ce cas prcis nous pouvons adopter la notation [t] [t].
6. Substitution

[t(xi1,L, xin)] [t'(xi1,Lxin)] [w1] [w'1]L[wn] [w'n ]

[t(w1 / xi1,L,wn / xn)] [t'(w'1 / xi1,L,w'n / xin)]
Dfinition 6.27. Etant donn une thorie R = ( ,E,L,R), un ( ,E)-squent [t] [t] est
dit :
Un 0-step concurrent R-rewrite si et seulement sil peut tre driv de R par application
(finie) des rgles 1 et 2 des rgles de dduction
Un one-step rewrite si et seulement sil peut tre driv (dduit) de R par application
des rgles (1) - (3) un nombre fini de fois, avec au moins une application de la rgle
(3). Si la rgle (3) est applique une seule fois alors le squent est dit " one-step
squentiel rewrite".

85

 Un "concurrent R-rewrite" (ou juste rewrite) si et seulement sil peut tre driv de R
par application finie des rgles 1-4.
Lemme 6.28 Pour chaque R-rewrite concurrent [t] [t], ou bien [t] = [t] ou il existe un
nombre n N est une chane de rcriture de "one-step"
[t 1 ] [t 2 ] [t n ] [t]
Nous appelons une chane une "step squence" pour [t] [t]. Par consquent nous pouvons
choisir toutes les tapes pour quelles soient squentielles, dans ce cas on appellera une telle
squence, squence d'entrelacement (interleaving ou firing squence).
Les dfinitions de terminaison, de forme normale, de Church-Rosser (confluence) sont
exactement similaires celles dj dfinies dans les systmes de rcriture.
Thorme 6.29 Si R est un systme de rgles de rcriture qui vrifie la confluence, alors une
quation [t] [t] est prouvable partir de R par dduction quatorienne, c'est--dire par application
des rgles 1-4 et la rgle 6, si et seulement sil existe un terme [t"] et les rgles de rcriture [t] [t"],
[t] [t"]. Et si en plus R possde la proprit de terminaison alors tout terme [t] possde une forme
normale unique, appele forme canonique et dnote canR[t]; sous ces conditions, une quation
[t] [t] est prouvable partir de R par dduction quationnelle si canR[t] = canR[t].
Exemple 6.30 Considrons la thorie de rcriture R = (,R) avec = (F, E, X)
F0 = {zero} , F1 = {s}, F2 = {plus} ; F = F0 F1 F2 ;
E = {plus(x,y) = plus(y,x)}, X = {x,y}, l = {l0,l1} ;

l0(x): plus(zero, x) x
Soit R =

l1(x, y): plus(s(x), y)s(plus(x, y))

Cette thorie de rcriture implique le squent :

(s(zero)) E: plus(zero,s(zero)) E (s(zero)) E

qui explique une application de la rgle l0 en appliquant les rgles de dduction.
Une preuve de la mme formule est donne par le squent :

l1(< zero> E,< zero> E );s(l0(< zero> E:< plus(zero,s(zero))> E <s(plus(zero), zero)> E ,
les deux termes de preuve :

<l0(s< zero>)> E: et <l1(< zero>)> E,< zero> E );s(l0(< zero> E )):

sont deux preuves diffrentes de < plus(zero,s(zero))> E < s(plus(zero), zero)> E

6.5.2 Expression de la Logique de Rcriture dans La Thorie des

Catgories
La logique de rcriture est une logique utilise pour modliser les systmes concurrents. Le
raisonnement dynamique dune telle logique utilise la notion dtat et de transitions. La signature de la
thorie de rcriture dcrit une structure particulire pour les tats du systme (e.g, les multisets, arbres
binaires etc.). Les rgles de rcriture dans cette thorie dcrivent quelles transitions lmentaires
peuvent tre distribues compte tenu de cette structure. Toute cette dynamique se traduit par le fait que
l'tape de rcriture est une transition locale et parallle dans un systme concurrent. Alternativement
cela, nous pouvons considrer les rgles de la logique de rcriture comme des meta-rgles pour une
bonne dduction dans le systme logique. Logiquement, chaque tape de rcriture (rewriting step)
dfinie un comportement logique dans le systme formel.
Un model initial dune thorie de rcriture est une catgorie TR ou les objets sont les
classes dquivalences [t] des termes clos modulo les quations dans E, et ou les flches

86

(transitions) sont les preuves r : [t][t'] dans la logique de rcriture. Les rgles de dduction de la
logique de rcriture dfinies dans la thorie des catgories sont comme suit :
1. Identits. Pour chaque [t] T , E ( X ) ,

[t] : [t][t']

2. -structure. P o u r c h a q u e f n, , n N ,

1 : [t ] [t'] L n : [tn ] [t'n ]

f(1,K, n) :

[ f (t1,L,tn )]

[ f (t1',L,tn' )]

3 . R e m p l a c e m e n t . Pour chaque rgle de rcriture

r:[t(x)] [t'(x)] if [u1(x)] [v1(x)]K[uk (x)] [vk (x)]

1 : [w1][w'1] K n : [wn][w'n ]
1 : [u1(w/ x)][v1(w/ x)] K k : [uk (w/ x)][vk (w/ x)]
n
k
r( , ) : [t(w/ x)][t'(w'/ x)]
4. Composition.

: [t1 ][t2 ] : [t2 ][t3 ]

; : [t1 ][t3 ]
5. Inversion.

: [t1 ][t2 ]
1 : [t2 ][t1]
Les preuves sont gales modulo la notion dquivalence qui en terme dexcution correspond
au vrai paralllisme.
1. Catgorie
(a) Associativit. P o u r t o u s , , ,

(;); = ;(;).

(b) Identits. Pour chaque : [t] [ t ' ] , ; [ t ' ] =

et [t]; = .

2. Fonctorialit de la structure -algbrique. P o u r c h a q u e f n ,

(a) Prservation de la composition. Pour tous les l , ... , n, 1, ... , n,
f ( 1 ; 1 , , n ; n ) = f ( l , ... , n); ( 1, ... , n)
(b) Prservation des identits. f ( [ t l ] , . . . , [t n ]) = [f ( t l , . . . , t n)].
1. Axiomes dans E. Pour t ( x 1 , . . . , x n) = t ' ( x 1 , . . . , x n ) u n a x i o m e d f i n i e d a n s E
p o u r t o u s l e s t ( l , ... , n) = t'( l , ... , n).
2. Echange. P o u r c h a q u e r g l e r : [ t ( x l , . . . , x n)] [ t ' ( x l , . . . , x n ) ] d a n s R,

1: [w1 ] [w1']L n: [wn ] [w'n ]

r()=r([w] ; t'( )=t( ) ; r([w'])

6.6 Diffrents
Rcriture

87

Types

dAlgbres

Engendres

par

la

6.6.1 Many Sorted Algebra

Dfinition 6.31 Soit S un ensemble quelconque, un ensemble S-sorted est une collection densembles
As indexs par les lements s S.
Une fonction S-sorted f : A B est une collection de fonctions indxes par S telle que fs : As
Bs pour chaque sS. De faon similaire, une relation S-sorted R de A vers B est une collection de
relations indexes par S et telle que Rs est dfinie de As vers Bs pour chaque sS.
Dfinition 6.32 Une signature many sorted tant la paire (S, ), ou S est lensemble des sortes et
est un ensemble (S* x S)-sorted de noms doprations. Si * et s alors ,s est lensemble de
noms doprations. Lcriture [ ],s dfinit les symboles constantes de sort s.
Dfinition 6.33 Pour une signature many sorted , une -algbre A sera dfinie par :

Un ensemble S-sorted dnot A, est appel le carrier de lalgbre

Un lment A As pour chaque sS et [ ],s

Pour chaque liste non vide S*, et pour chaque sS et w,s, une opration
A : A As, ou = s1 sn alors A = As1 x x Asn.

Soit A et B deux -algbres, on dfinit un -homomorphisme h : A B une fonction S-sorted

A B telle que :

Soit un symbole de constante ,s, hs(A) = B ;

Soit une liste non-vide = s1 sn et ,s et ai VA si pour i = 1,,n, alors

Hs(A(a1, ,an)) = B(hs1(a1), , hsn(an)).

Une algbre pour une signature interprte les noms des sortes comme des ensembles et les noms
doprateurs comme des oprations, cependant lhomomorphisme prserve la structure de lalgbre par
distribution sur les oprations de lalgbre.
Nous crivons T pour lalgbre des termes construit partir des oprations dans , et T(X) pour la
-algbre des termes contenant les variables dun ensemble S-sorted.
Dfinition 6.34 Une -quation est le triplet (X,l,r) ou X tant un ensemble S-sorted et l et r sont
des termes dfinis dans T(X) de mme sorte. Nous crivons (X) l = r.
Une spcification est le triplet (S,,E) ou (S,) tant une signature et E est lensemble des quations.
Exemple 6.35 Considrons la spcification suivante crite dans le langage Obj :
Obj FLAG is
protecting BOOL .
sort Flag .
op new : Flag .
op up_ : Flag Flag .
op up?_ : Flag Flag .
var F : Flag .
eq up ? new = false .
eq up? Up F = true .
eq up ? rev F = not(up ? F) .
endo

88

Ce programme spcifie une classe de cellules prenant des valeurs boolennes; leur tat est reprsent
par la sorte Flag, et la valeur donne dans un tat quelconque par lopration up? Cette valeur est mise
true par lopration up et elle change de valeur par lopration rev.

Dfinition 6.36 . Une -algbre A satisfait une -quation (X) l = r si et seulement si (l)= (r)
pour tout : X A. Nous crivons A |= e pour indiquer que A satisfait lquation e. Pour un ensemble
E dquations, nous dnotons par A |= E si et seulement si eE, et aussi nous dnotons par E|=e si et
seulement A |= E implique A|=e pour toutes les -algbres.
Dfinition 6.37 Soit (,E), un (,E)-model est une -algbre A telle que A|=E. Une algbre
satisfait une quation donne si et seulement si la partie droite et la partie gauche de lquation sont
gales sous toutes les interprtations des variables.

6.6.2 Order-Sorted Algebra.

L'algbre order-sorted (OSA) [GM88, Gna92], est forme d'une structure d'ordre partiel sur les
ensembles des sortes, la relation en question impose une restriction sur une algbre A (S-sorted) telle
que : s s est dfinie dans S alors As As avec As qui dnote l'ensemble des lments de sortes S.
La motivation d'une telle algbre tant de trouver des solutions certains problmes telles que les
expressions insignifiantes. Nous pouvons citer titre d'exemple certaines situations incongrues du type
Top d'une pile, pile vide, division par zro qui ne pouvaient pas tre formaliss par les algbres des
annes quatre-vingts. Donc, c'taient des problmes parmi tant d'autres qui il fallait apporter des
solutions.
Donc le concept thorique OSA est venu rpondre une foule de proccupations en ADT. Ce
formalisme qui n'est qu'une approche supporte ce qui suit:

Plusieurs formes de polymorphismes et de surcharge (overloading)

La dfinition des erreurs (dtection et correction)

Lhritage multiple, notion de slecteurs (cas de constructeurs multiples)

Retracts (inversion gauche de linclusion des oprations partielles qui rendent les sous-sortes
dfinies quationnellement

Des smantiques oprationnelles qui supportent les quations (rgles de rcriture)

Des smantiques de modles thoriques rigoureux.

La signature de OSA consiste en une famille de sortes ordonnes par une relation d'ordre partiel
d'hritage, plus une famille de symbole d'oprations. L'importance de l'OSA rside dans le fait que
d'un cot elle permet de combiner diffrents types de sortes (naturels et rationnels, entiers et
rationnels ect...) on appelle ceci l'overloading. Ce qui fait que cette situation est interprte pour dire
que les sous-sortes sont polymorphiques.

6.7 Le Langage Maude

6.7.1 Gnralits
MAUDE [CDE+99, CDE+00a, CDE+00b] est un langage et un systme en mme temps, dvelopp
au CSL SRI International (Stanford University). Llment de base du langage MAUDE tant la thorie
qui est dclare sous forme de module. Il existe naturellement plusieurs types de modules et le plus
gnral tant le module "system". Chaque module system se prsente syntaxiquement sous la forme de
mod R endm ou R tant une thorie de rcriture (le lecteur est invit consulter le papier [Mes00]
pour une description dtaille de la syntaxe des modules). Le systme dquations E dans la thorie
quationnelle (,E) se prsente comme l'union E = E' A, ou A tant l'ensemble d'axiomes

89

quationnels introduits comme des attributs de certains oprateurs, par exemple l'oprateur + peut tre
dclar associatif et commutatif par le mot cl assoc et comm, et ou E' est l'ensemble d'quations
supposes respectant la proprit de Church-Rosser et celle de terminaison modulo les axiomes de A.
De plus, la thorie R est suppose tre cohrente (ground) [Vir94]. Le langage MAUDE supporte
aussi la rcriture modulo diffrentes combinaisons des attributs de A. Les oprateurs dans MAUDE
peuvent tre dclars avec certaines combinaisons de certaines proprits telles que l'associativit, la
commutativit et avec des attributs didentits gauche, droite ou bien des deux cots.
Une thorie quationnelle peut tre vue comme une thorie de rcriture supportant l'ensemble L et
R des labels et de rgles vides. MAUDE possde un sous-langage dit module fonctionnel de la forme
fmod (,E) endfm, qui possde les mme proprits nonces auparavant, c'est--dire la confluence et
la terminaison. La logique quationnelle des modules fonctionnels et de la partie quation des modules
systme est une logique equationnelle de Membership [BJM00, Mes98], les expressions dans cette
logique sont les quations t = t' et les prdicats Membership scrivent t : s avec s une sorte. La
logique quationnelle Membership supporte aussi les sortes, les sous-sortes et les oprateurs de
surcharge (overloaded).
MAUDE supporte aussi un troisime type de module, appel object-oriented module qui spcifie les
systmes concurrents orient-objets, sa syntaxe tant omod R endom. Au moment de l'excution ces
modules (orient-objet) sont traduits en modules "system" ordinaires. MAUDE met en place tous les
moyens pour reprsenter certains concepts de l'orient-objets tels que l'objet lui-mme, les messages,
les classes, le polymorphisme et la notion d'hritage multiple.
Les modules dans MAUDE possdent une smantique initiale. Le module systme tel qu'il est
prsent (mod R endm) spcifie le model initial TR de la thorie de rcriture R . De faon
similaire un module fonctionnel fmod (,E) endfm spcifie une algbre initiale T,E de la thorie
quationnelle (,E).
En plus de cela, MAUDE supporte un autre type de module appel module algebra avec des modules
: parametrized modules, parameter theories views et des modules expressions. Dans MAUDE cette
algbre de module (model algebra), appele Full-Maude, est dfinie l'intrieur mme du langage par
rflection ce qui lui donne une facilit d'extension et d'enrichissement. Full-Maude constitue un moyen
pour prendre en charge la notion mme de meta-programmation travers les modules programmables
META-LEVEL modules [CM96, CDEM00]. Cette notion de rflection met en place des fondements
thoriques trs puissants pour prendre en charge et mettre en application ce qu'on appelle les stratgies
afin de guider de l'intrieur mme lexcution des thories de rcritures sous forme de rgles de
rcriture au niveau metalevel.
Donc, le systme MAUDE et son langage spcifient et excutent des spcifications bases sur la
logique de rcriture. Une forme simple de MAUDE comme langage pour lexpression des systmes
dynamiques et concurrents spcifie une configuration (tat) comme une collection et des messages
utilisant loprateur A.C.I (Additive, Commutative et Identit) et llment neutre .
L'expression d'une configuration c'est--dire de l'objet et des messages qui l'accompagnent (input &
output) sont reprsents par la rgle suivante :
M1, ... , Mn <O: C |a1: : v1 .... an:: vn> Mn1, ... , Mnm
qui signifie que l'objet est un terme <O: C |a1: : v1 .... an:: vn> ou O tant le nom de l'objet, C la
classe auquel appartient l'objet, ai le nom de l'attribut numro i et vi la valeur de l'attribut i. Le systme
volue selon des rgles de rcriture conditionnelles qui prennent la forme suivante :
crl [r] : M1, ... , Mn<O1:C1| atts1> ... <Om :Cm| attsn>
=>
<Oi1:Ci1| attsi1> ... <Oik:Cik| attsik><Q1:D1| atts1> ... <Qp : Dp| attsp> M1, ... , Mq

90

if Cond.

Donc, cette rgle exprime l'occurrence d'un vnement de communication dans laquelle n messages
et m objets distincts sont impliqus. Dans une phase donne les messages M1, ... , Mn sont consomms
(disparaissent) et de nouveaux messages M1, ... , Mq sont alors cres par le systme et mis aux objets
ou modules qui leur font rfrence. Les objets O1,Om qui n'apparaissent que dans la partie gauche de
la rgle sont supprims, par contre ceux de la partie droite Q1 ... Qp sont cres et ceux qui se trouvent
sur les deux cots changent uniquement leurs tats locaux. L'option conditionnelle Cond restricte la
rgle des situations particulires, donc c'est aussi un invariant contrlant l'application de la rgle.
Quand plusieurs objets ou messages apparaissent sur la partie gauche de la rgle, ils ont besoin de se
synchroniser. Ce type de rgles est dit synchrone. Par contre celles qui possdent un seul objet et un
seul message dans leur partie gauche sont des rgles asynchrones.
Comme dans la philosophie orient-objet, l'hritage dans une classe est directement support par la
notion de structure de type order-sorted [MM96, GM88]. La dclaration d'une sous-classe s'exprime par
C < C qui est un cas particulier par lequel tous les attributs, les messages et les rgles des superclasses
caractrisent sa structure et son comportement.
A titre d'exemple le module fonctionnel suivant dfinit les dclarations des types de donnes des
transactions bancaires.
fmod bank_operation is
protecting Int .
sort Int, Nat, Account, Msg .
subsort Nat < Int .
class Account .
att solde : Account Nat .
msgs credit, debit : Account Nat Msg .
msg transfer_from_ to _ :Nat Account Account Msg
vars C1 C2 : Account, var mont : Nat .
endfm
Cet exemple, prsente les oprations simples quune banque pourrait excuter, dfinies par la
balance, le dbit et le crdit de deux comptes C1 et C2. Les informations contenues dans ces deux
comptes pourraient tre manipul par deux types de rgles l'une synchrone et l'autre asynchrone ou
(transfer Mont From C1 to C2) , credit(C1, Mont) and debit(C2, Mont) sont les messages de transfert et
de manipulation des comptes. Ces deux rgles sont quivalentes.

6.7.2

Expression des Communications Synchrones et Asynchrones

Les deux rgles suivantes nous donnent une reprsentation approximative de la possibilit qu'offre la
logique de rcriture supporte par le langage MAUDE, afin d'identifier et de mettre en place tous les
mcanismes pour exprimer d'une manire gnrale le paralllisme et l'change synchrone et asynchrone
d'information entre des processus communicants et concurrents.
1er cas: Rgle synchrone:
crl [rule1] (transfer Mont From C1 to C2) < C1: Account | solde: S1> < C2: Account | solde: S2>
=> <C1: Account | solde: S1-Mont> < C2: Account | solde: S2 + Mont> if ( S1 Mont >= 0 )
2me cas:

91

Rgle asynchrone:

crl [rule2] credit(C1, Mont) < C1: Account | solde: S1 > => < C1: Account | solde: S1-Mont> if
(S1 Mont >= 0)
rl

[rule3] debit(C2, Mont)

< C2: Account | solde: S2> => <C2: Account | solde: S2 + Mont> .

Dans la rgle synchrone (cas 1), les objets C1 (< C1: Account | solde: S1 >) et C2 (< C2:
Account | solde: S2>) interagissent en parallel (concurrently). Influencs par le message (transfer
Mont From C1 to C2), ils changent la valeur Mont et le systme la retranche de solde: S1 et rajoute
cette quantit solde: S2. Le rsultat de la rgle ( < C1: Account | solde: S1-Mont> < C2: Account |
solde: S2 + Mont>) nous fournit une nouvelle configuration ou le message (transfer Mont From C1 to
C2) est supprim.
Nous pouvons imaginer partir de la structure de ces oprations que pour les rgles asynchrones,
aucune interaction entre objets n'est possible puisquils s'excutent squentiellement. Le premier objet
perdra de fait la quantit Mont dduite de solde : S1, et rajoute au solde : S2 du deuxime objet.
6.7.2.1

Rgles de Fonctionnement Interne

Ce type de rgles est crit selon la forme suivante :

Oi Oi Om On Mq Mr [T] .
Ces rgles permettent d'exprimer les changements d'tats, non pas une excitation externe, mais
plutt une logique interne qui n'est pas visible ce niveau. Elle concerne donc un objet complexe
actif, qui peut voluer dans le temps suite une activit interne. Cela permet de spcifier, entre autres,
le comportement de certains objets qui obissent des lois internes plus ou moins complexes. Par
l'intermdiaire de [T], ces lois peuvent tre alatoires quelconques, on introduit l'indterminisme dans le
comportement.

6.7.3

Caractristique du Module META-LEVEL et de la Rflection

Clavel et Meseguer ont dmontr que la logique de rcriture tant rflective [CM96, Dur99,
CDE+00]. Ce qui fait, qu'il existe une thorie de rcriture U qui est universelle dans le sens ou il nous
est possible de reprsenter toute thorie de rcriture (finitely) R (incluant U elle-mme) et tous
termes t, t' dans R comme des termes et t, t' dans U, de faon avoir l'quivalence suivante :

t t' U < R,t > < R,t'> .

La thorie U peut tre vue comme un interprteur universel pour la logique de rcriture qui peut
simuler les rcritures d'une thorie de rcriture R. Cependant, il serait vraiment trs coteux de
simuler les R-rewrites dune implmentation nave de U, puisque la simulation d'une seule tape de
rcriture dans R peut engendrer plusieurs Utapes. La thorie universelle peut cependant tre
excute avec des fonctions (descent functions) qui simulent des oprations (rewrite step), sur les
paramtres t et R par un chemin efficace de descente (going down) en un seul niveau de rflection et
utilise le moteur de rcriture pour calculer dans R le rsultat t' de l'application de la rcriture t. Le
terme rsultant t' et alors transform dans sa reprsentation en t' .
Dans le langage Maude, les modules pr-dfinis META-LEVEL sont supposs modliser une thorie
universelle U. Dans le module META-LEVEL, les termes sont rifis comme des lments d'un type de
donnes Term, possdant la signature suivante:
subsort Qid < Term .
subsort Term < TermList .
op {_}_ : Qid Qid Term .

92

op _[ _ ] : Qid TermList Term .

op _,_ : TermList TermList TermList [assoc] .
op error* : Term .
Dans cet exemple, "subsort Qid < Term . " dclare la sorte Qid comme une sous-sorte de Term,
utilise pour reprsenter les variables dans un terme par les identificateurs correspondants (quoted
identifiers). Cependant si nous voulons reprsenter une variable, par exemple N, elle sera reprsente
par 'N. L'oprateur "{ _ }_" est utilis pour reprsenter les constantes comme des paires, avec le premier
argument la constante dans une forme quotte et le deuxime argument la sorte de la constante toujours
dans une forme quotte. Par exemple, la constante zero de sorte Time est reprsente par {'zero}'Time.
L'oprateur _[ _ ] correspond une construction rcursive de termes hors des sous-termes, ou la
concatnation d'une liste est dnote par " _,_". Par exemple, le terme f(a,b) (pour a et b deux
constantes de sorte s) est reprsent dans la description META-LEVEL par 'f[{'a}'s, {'b}'s] et le terme
{f(a,b)} (pour {_} un oprateur infix) est reprsent comme ''{_'}[f[{'a}'s, {'b}'s]].
La syntaxe des modules system et functional est exactement la mme que leur syntaxe originale.
C'est--dire :
sorts Fmodule Module .
subsort Fmodule < Module .
op fmod_is_ _ _ _ _ _ _endfm : Qid ImportList SortDecl SubsortDeclSet OpDeclSet VarDeclSet
MembAxSet EquationSet Fmodule .
op mod_is_ _ _ _ _ _ _ _ endf : Qid ImportList SortDecl SubsortDeclSet OpDeclSet VarDeclSet
MemAxSet EquationSet RuleSet Module .
A titre d'exemple l'ensemble de regle dans un module seront reprsents comme suit:
sort Rule RuleSet .
subsort Rule < RuleSet .
op rl[ _ ] : _=>_. : Qid Term Term Rule .
op crl[ _ ] : _=>_if_=_. : Qid Term Term Term Term Rule .
op none RuleSet .
op _ _ : RuleSet RuleSet RuleSet [assoc comm id: none] .
Le module META-LEVEL fournit des fonctionnalits sous forme de fonctions. Par exemple le
processus de rduction d'un terme vers sa forme normale peut tre rifi par la fonction :
Op meta-reduce : Module Term Term [special ] .
Ou meta-reduce( M, t ) retourne la meta-reprsentation u de la forme normale u du terme t dans
le module M. Le processus de l'application dune rgle est aussi rifi par la fonction :
op meta-apply : Module Term Qid Substitution MachineInt ResultPair [special ],
Meta-apply( M ,t,l, ,n ) retourne le rsultat de l'application de la rgle l, instancie partiellement par
, dans M vers la forme normale du terme t, utilisant (n+1)ime galits (application). Le rsultat est

{ }

retourn sous forme d'un terme t',' ou t' tant la forme normale du terme rsultant, et ' est le pas
utilis par la rgle d'application. Le rsultat {error*, none} est aussi retourne si moins de (n+1) pas de
rduction sont utiliss. MAUDE est rifi par la fonction meta-rewrite. L'analyse syntaxique est ralise
par la fonction :

93

op meta-parse : Module QidList Term [special ] .

6.7.4

Full-Maude

Les modules MAUDE constituent des objets de premire classe, il est relativement ais de dfinir en
MAUDE (META-LEVEL), diffrentes oprations sur les modules. Le systme plutt sous-systme
Full-Maude crit par Duran et Meseguer [Dur99, DCE+98, CDE+04], tant une spcification crite en
totalit dans MAUDE (core), dfinie un langage mais aussi un outil pour la spcification et lexcution
des modules crits en MAUDE. Les modules de Full-Maude sont constitus d'un ensemble de modules
spcialiss tels que le module-algebra avec module-hierarchies, module-parametrization, views,
theories et un module expressions. Il supporte aussi la spcification de modules "orient-objet" utilisant
une syntaxe mettant en place tous les lments de dclaration dans le paradigme de lorient objets tels
que la notion de classe, d'objet, de message, d'hritage, de polymorphisme etc. Full-Maude utilise
LOOP-MODE pour lire les modules et "system commands" pour que la base de donnes des modules
soit prsents d'une faon persistante ainsi que pour mettre la disposition de l'utilisateur les rsultats
des commandes en les plaant dans un buffer en sortie.

6.8 Conclusion
Dans ce chapitre nous avons prsent le fondement mme de la logique de rcriture qui est base
sur deux concepts thoriques trs connus depuis bien longtemps : les systmes de rcriture et les
spcifications quationnelles.
Nous avons aussi montr que comme la logique de rcriture est universelle, cest donc quelle
possde un pouvoir dabstraction et de description de tout type de systme. Nous avons explicitement
dfinit lexistence dun isomorphisme fonctionnel permettant le passage dun modle vers sa
description formelle en logique de rcriture qui son tour permet la projection de ce modle dans la
thorie des catgories qui est un puissant formalisme mathmatique de reprsentation et de
dmonstration. Le chemin inverse est aussi ais que le premier.
Le mcanisme de la logique de rcriture et de son langage porteur qui est Maude t dcrit
montrant la facilit avec lequel Maude permet de dcrire les programmes sous forme de module
fonctionnel, de module objet mais aussi de module systme. La reflction, la logique de Membership, la
notion dalgbre Many-sorted et de Order -sorted confortent la puissance de Maude.

94

CHAPITRE 7

Spcification des Systmes Temps-Rel

dans le Cadre de la Logique de Rcriture

95

7.1 Introduction
Nous avons montr dans le chapitre prcdent que la logique de rcriture est un modle formel trs
expressif travers duquel diffrents types de modles concurrents peuvent tre exprims et spcifis de
faon naturelle. Son aspect thorique lui permet de mettre en place des mcanismes (des rcritures)
pour la spcification et l'intgration de caractristiques temporises des systmes temps-rel qui
s'expriment aisment travers une syntaxe ordinaire et une smantique oprationnelle faisant ressortir
le temps comme une variable de type (sorte) Time.
La premire contribution en matire de recherche pour l'application de la logique de rcriture dans
la spcification du facteur temps rel fut le travail de Kosiuczenko et Wirsing dans le cadre des TRL
(Timed Rewriting Logic) [KW96] et de [OM01a, OM01b, Olv02, Reb00]. Dans ce qui suit, nous allons
montrer comment la logique de rcriture permet de spcifier les systmes temps rels. Ceci se fera
travers l'introduction d'un paramtre explicite du temps satisfaisant des axiomes gnraux de
passage du temps. L'aptitude d'exprimer le temps dans la logique de rcriture est ralise par des
thories de rcriture temporise qui seront traduites vers des thories de rcriture ordinaire
non-temporises en considrant une ou un ensemble d'horloges explicites.
Nous abordons dans ce chapitre les systmes temps rel dun point de vue purement formel
dans une approche oriente vers la logique de rcriture. La notion de temps est alors introduite
en utilisant une certaine axiomatisation dfinie dans des domaines varis (entiers, rels, etc)
selon le type. Ces dfinitions sont crites sous forme de thories fonctionnelles de la logique de
rcriture (modules fonctionnels et objets Maude). Le systme abstrait temps rel est ensuite
dfinit moyennant une structure statique interprte laide dun type de donnes abstrait (ADT :
Abstract Data-type), plus une structure dynamique dfinie par un ensemble de rgles de
rcriture.
Le modle objet temps rel est alors introduit travers un exemple pour montrer la puissance
de la logique de rcriture prendre en charge le modle formel orient-objet ractif. Par la suite
un modle dune importance capitale est introduit, montrant la simplicit naturelle pour dclarer
le comportement sous forme de rgles tiquetes par le paramtre temps . Ces dclarations
sont ffectues par une smantique oprationnelle la Plotkin.
Toutes ces dfinitions mettent en place des mcanismes thoriques trs puissants pour
formaliser, spcifier et vrifier les systmes ratifs temps rels.
Le but de cette section est de montrer que la logique de rcriture est une plate forme
thorique universelle qui permet dexprimer les systmes concurrents travers leurs structures,
leurs comportements et surtout de dtailler le modle de communications.

7.1.1 Spcification des systmes temps rels

Nous utilisons les symboles r, r', rl,.... pour dnoter les valeurs du temps; xr, yr, zr ..., pour
dnoter les variables d'une sorte Time et tr, t'r, pour dnoter des termes de sorte Time.
7.1.1.1

Domaines Temporels

Le temps est considr dans cette partie comme une entit abstraite utilise pour exprimer les
contraintes temporelles sur des actions temporelles.
Dfinition 7.1. Un domaine temporel peut tre considr comme un monode commutatif (D,+,0)
qui satisfait les besoins suivants :

96

d + d = d d = 0

left-cancellative: d + d = d + d d = d

anti-symetrie: (d + d = 0) d = d

le preorder dfini par d d d / d+ d = dest un ordre total.

Les proprits suivantes peuvent aisment tre prouves savoir-- (i) 0 est le plus petit lment de
D, (ii) pour tous d, d D, si d < d, alors il existe un lment d D tel que d + d = d et qui soit
unique, il sera dnot par (d d). Nous dnotons D {0} par D *. Nous crirons d < dau lieu de d
d d d. D est dit dense si d, d : d < d d: d<d<d, D est dit discret si d, d: d<d
d: d < d d < d. Comme la relation d'ordre est totale entre les lments de D, tout lment de D
peut tre obtenu partir de zro en additionnant le successeur de ce dernier. Exemple de domaines
temporiss: Les nombres naturels (domain discret), Q+ et + (dense) ou bien le singleton {0}.
7.1.1.1.1 Dterminisme du Temps
Il est admit que lorsqu'un processus P par exemple est inactif (n'excute aucune action) pendant une
dure d, le comportement rsultant est compltement dtermin par le processus lui-mme P et la dure
d'excution. La progression du temps peut tre exprime par : [Reb03, Olv00]
P, P, P, d : P

P, P P

P = P

ou = tant l'galit syntactique. P, P, et P sont des processus et d tant la quantit de temps que
prenne un processus pour passer dun tat un autre.
7.1.1.1.2 Additivit du Temps
Afin d'assurer la ncessit en terme mathmatique de la notion de temps, il est demand de respecter
(i)

un processus qui peut devenir inactif pendant d + dunits de temps, doit rester inactif
pendant d units de temps, puis pendant dunits de temps, et vice-versa.

(ii)

(ii) dans les deux cas le rsultat doit tre le mme.

La proprit d'additivit du temps est formellement dfinie par :

P, P, d, ,d : (P: PdP, PdP) Pd+dP
Nous pouvons remarquer un peu plus tard que la proprit d'additivit est exprime naturellement
dans la logique de rcriture temporise par l'axiome de transitivit

7.2 Modle temporis

Le temps est modlis par un monode commutatif (Time, +, 0) muni d'oprateurs additionnels
<, - ( Monus ) crits dans le langage Maude (donc il satisfait la thorie Maude).
fth TIME is
Protecting Bool
sort Time .
op

0 : Time .

op _ + _ : Time Time [assoc c o m m id : 0] .

o p _ < _ , _ < = _ : T i m e Time Bool .
op

97

_ - _ : Time Time Time .

vars xr, y r, zr, wr : Time .

ceq yr = zr if x r + yr == xr + zr .
eq (xr + y r) - y r = xr .
ceq (xr < y r ) = true if ( x r < y r ) and y r < zr .
eq (xr < xr) = false .
eq 0 <= xr = true .
eq ( x r < = y r ) = ( x r < y r ) or ( x r = = y r ) .
ceq x r + y r <= zr + wr = true if x r <= zr and y r <= wr .
eq x r <= (xr y r) + y r = true .
ceq (x r - y r) + y r = xr if y r <= xr .
ceq x r zr <= y r zr = true if xr < y r .
endft
Nous remarquons que la relation - - est une relation d'ordre partiel telle que pour tout : x r, y r:
Time, xr = true, et y r< = x r si et seulement sil existe zr unique tel que xr = y r + zr.
Pour la simulation et l'excution de la spcification propose, nous seront plutt intresss par
les modles calculables de la thorie Time en question. Cela signifie que toutes les oprations
sont calculables. Ce type de modles est finitely spcifiable comme une algbre initiale pour
un ensemble E de Church-Rosser et d'quations terminant terminating [OM01b].
Sil nous arrive de rajouter une valeur additionnelle TG (Trs Grand qui tend vers linfinie) de
type temps (Time), celle-ci peut tre spcifie dans le langage Maude par ce qui suit.
fth TIME TG is
including TIME .
sort TimeTG .
subsort Time < TimeTG .
op

TG : TimeTG .

op

_<=_ : TimeTG TimeTG o Bool .

op

_ - _ : TimeTG, Time TimeTG .

op

_ + - : TimeTG TimeTG Time TG [assoc comm id : 0 ] .

var

xr : Time .

var

yr : TimeTG .

eq

yr <= TG = true .

eq

TG <= xr = true .

eq

xr < TG = true .

eq

TG < yr = false .

eq

TG xr = TG .

eq

TG + yr = TG .

endft

98

Dans le cas ou le temps peut tre suppos linaire, il peut tre spcifi dans la thorie suivante:
fth LTIME is
including Time .
op min : Time Time Time [comm] .
vars xr, yr, : Time .
ceq xr = yr if not(xr < yr) and not(yr < xr ) .
ceq min (xr, yr) = yr if yr <= xr .
endft
Nous pouvons aussi tendre cette thorie avec le caractre TG du temps trs grand comme suit :
fth LTIMETG is
extending LTIME TIMETG .
op min : TimeTG TimeTG TimeTG [comm] .
var xr : TimeTG .
eq min (TG, xr) = xr .
endft

7.3 Expression du temps comme une action

Le passage du temps peut tre exprim par une action qui aura un effet sur chaque composante du
systme. Dans ce cas, et comme il a dj t dit, le temps est modlis par un monode commutatif
muni d'une structure additionnelle. L'action dans ce cas est alors axiomatise par la fonction f de type
f : State Time State satisfaisant les axiomes usuels suivants:
f(x,0) = x
f(f(x,yr),zr) = f(x,yr + zr) .
La fonction f permet d'exprimer l'effet du passage du temps dans le systme.
L'effet du passage du temps est matrialis par des rgles du type tick, donc un tick correspond une
unit de temps. Ce type de rgle s'exprime par :
crl [tick] : {t}

{f(t,r)}

= if C .

Exemple: La spcification suivante suppose modliser un temps discret "clock", ou Time est une
sorte prenant ses valeurs dans N (nombres naturels), qui est rinitialise quand elle atteint la valeur 24.
sorts State System .
op clock : Nat State .
op f : State Nat State .
op {-} : State System .
vars xr, yr : Nat .
var z : state .

99

eq f(clock(xr),yr) = clock(xr + yr) .

rl [reset] : clock(24) clock(0) .
rl [tick] : {z}

xr

{f(z,x )} .
r

Supposons aussi que le temps agit sur un terme a pour deux units de temps. Dans ce cas le terme a
se rcrit en b, qui peut alors son tour se rcrire en c, si le temps ne peut agir sur lui. Les quations
dun tel systme se rcrivent :
{f(a,2) b, bc, f(c,2)d}

7.4 Logique de rcriture en tant que smantique pour les

systmes temps rels.
7.4.1 Application aux automates temporiss
Nous pouvons omettre les dtails sur les tats initiaux et les conditions d'acceptation. Donc nous
pouvons d'ores et dj dfinir un automate par ce suit et qui consiste-en :
Rappelons la dfinition d'un automate temporis telle que dfinie auparavant. Donc, nous supposons
que l'automate temporis A = (,S,C,E) peut tre reprsent d'une faon naturelle dans la logique de
rcriture par la thorie de rcriture temps-rel TA(A) = ((A,EA,LA,RA),A,TA) comme suit :
(A,EA) contient une axiomatisation quationnelle du domaine temporis R+. De plus, la
signature A content une sorte TAState avec une constante s : TAState pour chaque sorte sS, une
sorte State munie d'un oprateur (n+1)-aire _, _ ,_ , , _ : TAState TIME Time State, et un
oprateur {-} : State System .
L'ensemble LA des labels est {tick}.
L'ensemble des rgles RA et son affectation (duration) contient une rgle instantane,
[a] : {s,x1, , xn} {s',t1, , tn} if (x1, , xn)
pour chaque transition (s,s',ai,, ) E, telles que les variables xi sont de type sort Time et les termes ti
sont nuls si ci et ti = xi sinon, et (x1, , xn) est obtenu partir de par substitution de chaque
horloge ci avec la valeur xi et en remplaant les oprateurs et par "and" et le "not". En plus de cela
une rgle du type :
yr

[tick] : {z,x1, .. ,xn}

{z,x

= yr, .. ,xn + yr}

(ou z, yr, x1, , xn sont des variables) est rajoute au model du passage de temps.
L'automate temporis de la figure 7.1 sera reprsent par la thorie de rcriture temporise qui
contient les rgles suivantes :
rl [a] : {s0,x,y} {s1,0,0} .
crl [b] : {s1,x,y} {s2,0,y} if 5 x 10
crl [a] : {s2,x,y} {s1,0,0} if y 15 and 4 x 8
yr

rl [tick] : {z,x,y}

{z, x + yr, y + yr}

pour x, y, et yr des variables de sorte Time, et z une variable de type TAState.

100

Figure 7.1 : Graphe dun Automate

7.4.2

Systmes temps-rel orient-objets

Dans un systme concurrent orient-objet [Olv00, Reb00], l'tat qui est appel configuration possde
la structure d'un multi-ensemble constitu d'objets et de messages. La dclaration en MAUDE d'une telle
configuration s'crit selon la syntaxe suivante :
op _ _ : Configuration Configuration Configuration [assoc comm id : none] .
Ou l'oprateur de l'union (multi-ensemble) est dclar pour satisfaire les lois structurelles de l'associativit,
de la commutativit et de lidentit none. La dclaration du sous-sorte (subsort)
Object Msg Configuraton
qui dclare les objets et les messages comme un singleton (multi-ensemble) de configurations partir
duquel des configurations plus complexes peuvent tre gnres par l'union de multi-ensembles.
Object ObjConfiguration Configuration
et l'oprateur
_ _ : ObjConfiguration ObjConfiguration ObjConfiguration [assoc comm id : none].
Les objets sont des termes de type Object de la forme dclare de la mme manire quauparavant,
c'est--dire < O : C | att1 : val1, , attn : valn > dnotant un objet O, ou O est de sorte Oid (identificateur
d'objets).
Le comportement dynamique d'un systme concurrent orient-objet sera axiomatis en spcifiant
chacune de ces transitions courantes par une rgle de rcriture. Par exemple la rgle suivante dfinie une
transition temporise :
rl [l] : m(O,w) < O : C |att1 : x, att2 : y, att3 : z >

< O : C |att1 : x + w, att2 : y,att3 : z > m'(y, x + w)

En rsum, un systme orient objet peut tre spcifi l'aide de thories de rcriture temps-rel
comme c'est dj fait, plus une extension l'aide de l'oprateur suivant :
{_} Configuration System .
Nous illustrons cette partie de notre prsentation des systmes temps-rel dans le cadre de la logique de
rcriture par l'exemple suivant [Reb02a].

7.4.3

101

Exemple d'application

Sensor 2

Sensor 1
Safe

Approaching

Crossing

Figure 7.2 : Un passage niveau et son automate correspondant

7.4.3.1

Spcification d'un croisement au niveau d'un passage niveau

Un systme concurrent grant le croisement au niveau d'un passage niveau est un dispositif
compos formellement d'un ou de plusieurs trains, d'un contrleur et d'une barrire automatique. La
partie la plus intressante dans ce systme tant de grer ce passage pour qu'il n'y ait pas d'accidents
entre trains et automobilistes passant en sens crois. Ce systme peut tre reprsent par trois processus
qui voluent tout fait en parallle, disons Train pour le train, Controller pour le contrleur et Gate
pour la barrire. Relatif au passage niveau tout train peut se trouver dans lun des trois modes
suivants : safe, approaching ou crossing. Tout train passe d'un tat safe lorsqu'il se trouve trs loin de
l'intersection, puis arriv une distance connue, il passe l'tat approaching, et finalement l'tat
crossing et lorsquil quitte le passage niveau il devient safe (Figure 7.2).
Quand le train pntre dans la surface approaching, un objet de sorte Timer est forc avec la valeur
d1 qui est le temps ncessaire avant que le systme dclenche le signal lower. Lorsque d1 units de
temps auraient t consommes le Timer dclenche une opration interne de Time-out et le signal
Approach_Signal est transmis au systme de contrle. Quand le Contrleur reoit ce message, il
positionne son tat interne ''lower'' et envoie le signal lower_signal au systme qui contrle la
barrire qui lui donne lordre de se mettre la position ''lowered'' qui doit se faire dans un dlai de d2
units de temps qui est lintervalle de temps prvu entre le dernier time-out laire de croisement
''crossing area'' et la position de la barrire ''gate position''. Lorsque la barrire se met baisser, le
contrleur de cette dernire rinitialise son Timer d3 units de temps qui correspond exactement au
temps quil faut pour un train de dpasser l aire de croisement. Quand le quantit de temps d3 est
consomme le Timer time-out, le signal Exit_Signal est alors envoy au contrleur qui son tour
repositionne son tat interne la position ''raising'' (remonter) et transmet le signal raising_signal au
contrleur de la barrire pour quelle se remette la position ''raised'' pour librer la route. Lun des
critres les plus importants tant de sassurer que lorsque le train se trouve sur laire dintersection la
barrire doit tre ferme (critre de sret). Pour assurer une telle spcification nous devons supposer
que le train passe de ltat safe ltat crossing pendant un temps gale d1 + d2 units de temps.
Nous nous arrtons ce point de dfinition et nous redirigeons le lecteur sur dautres dtails de la
spcification et de la vrification dans le langage MAUDE du systme global et de certaines proprits
qui sont consignes (voir les articles [Reb00, Reb02a]). Nous informons aussi le lecteur quune autre
approche similaire pour dfinir ce systme (critique temps rel) se trouve introduite dans le chapitre 8.

7.5 Conclusion
Dans ce chapitre, nous avons montr les possibilits quoffrent la logique de rcriture et le langage
MAUDE pour spcifier les systmes temps-rel ordinaires mais aussi ceux caractristiques objets
ainsi que les automates temporiss. Nous avons vu, quavant dentamer la description du systme
structurellement, il faut tout dabord dfinir mticuleusement le ou les types de temps quil faut au
pralable mettre en place. Ces dfinitions sont simplistes puisque nous utilisons des thories (modules
fonctionnels) lmentaires qui sont ensuite sont gnralises.

102

CHAPITRE 8

Proposition dun Environnement pour la

Modlisation des Systmes Ractifs

103

8.1 Introduction
Le dveloppement des systmes temps rel revt une importance qui ne cesse de grandir. En effet,
l'essor croissant des technologies permet de dfinir des systmes informatiques sophistiqus et d'une
complexit difficilement matrisable.
Dans cette partie de notre travail, nous nous intressons la modlisation et la conception des
systmes ractifs et plus spcialement ceux qui sont temps rels. Cette modlisation certes passera par
plusieurs tapes, mais, nous ne retiendrons quune approche plutt graphique qui sera communique au
systme (le noyau), et qui a son tour ferra en sorte de lui faire subir certaines transformations pour la
faire passer du mode graphique vers un mode textuel, donc, qui sera rcrite en programmes qui
fourniront diffrents codes et machines dtats.
Lobjectif le plus important de toutes ces transformations tant de ramener la forme graphique dun
programme qui est de surcrot formel vers une version condense, formelle (langages algbriques) est
minimale (quivalence de bisimulation). En effet, pour des critres essentiellement conomiques, le
systme doit tre modlis laide de langages dit formels trs tt dans le cycle de vie, cela, permet
dassurer sa cohrence et sa faisabilit. Le surcot indniable entran par lutilisation de ce type de
langages reste largement infrieur limpact dun dysfonctionnement lors de lexcution du systme ou
dune correction tardive au cours du dveloppement.
Malheureusement, les langages formels se rvlent tre dune grande complexit, leur
comprhension reste rserve des spcialistes de la modlisation formelle. Or, le dveloppement de
systmes temps rel fait appel diffrentes spcialits, que ce soit en informatique (sret de
fonctionnement, protocole, temps rel, base de donnes), en automatique, en lectronique Les
langages formels sont alors peu adapts aux changes pour lesquels il est ncessaire de favoriser la
communication entre les diffrentes spcialits. De plus, ils obligent gnralement lanalysteconcepteur entrer rapidement dans des niveaux de dtails qui ne facilitent pas une comprhension
globale du systme en construction.
Pour palier ce type de perturbation dans la conception des systmes, l'utilisation conjointe de
notations semi-formelles et de langages formels (approches dites mixtes) est de plus en plus utilise.
Les notations semi-formelles simplifient la capture des besoins, le dialogue entre les diffrents
spcialistes intervenant dans le dveloppement, le passage des fosss smantiques (semantic gap) que
reprsentent les transitions entre les phases d'analyse des besoins (requirements), de spcification du
systme (analysis), de conception prliminaire (global design) et surtout, la validation du modle qui
sort de son carcan traditionnel pour pouser un aspect purement formel pour la vrification de
proprits (dsirs) qui sont au pralables mises la disposition du concepteur.
Avec lapparition de la notation UML (Unified Modelling Language)[OMG99a, OMG01], la
question du choix dune reprsentation semi-formelle ne se pose plus. Son statut de standard de facto,
sa richesse d'expression, ses capacits d'extension, son large spectre de couverture des phases du cycle
de vie, le nombre d'outils informatiques l'implmentant et son adoption par la plupart des universitaires
et des industriels la rend accessible un large public.
Dans un contexte ou un nombre important de mthodes et de langages prolifrent (Plus de 50
mthodes objet sont apparues durant la priode 1990-95, mais aucune ne sest impose (SA, SA-RT,
Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) [RBP91], lide de
standardiser un langage rassembleur pour modliser dun ct les systmes dans des contextes divers,
puis de les coupler avec un langage rsonance formelle est devenue la priorit en matire de
recherche de plusieurs quipes universitaires et concepteurs industriels.
Dans ce cadre dide, nous joignons notre effort pour promouvoir cet axe de recherche et ainsi
apporter un plus, donc nous nous sommes intresss faire coupler UML et Maude [Reb04a, Reb04b,
ATH00] travers naturellement la logique de rcriture. Pourquoi un tel choix ? Nous avons deux
rponses qui vont tayer le fondement dune telle approche. Lune a t moiti lucide dans le
chapitre 6, elle se base sur le fondement thorique du langage Maude savoir la logique de rcriture et
les spcifications algbriques, contexte thorique prouv certes mais qui se trouve de mme tre un
104

puissant outil pratique, mais aussi qui modlise de faon remarquable tous les processus et leur
comportement fonctionnel et dynamique, sans oublier le fait que Maude incorpore en son sein (core =
noyau) cette notion dalgbre universelle et de rflection lui permet dengendrer, mais plutt de gnrer
une multitude de thories mais aussi de langages. Une preuve tangible est consigne dans les travaux de
Meseguer et al., mais aussi ceux dautres auteurs [OM01a , OM01, MM96, DCE+98, Mes98, FH98,
HR00, VMO03, EMS02, Cla01]. A titre dexemple, la Figure 8.1 prsente un exemple de modlisation
par rseaux de Ptri et sa spcification en Maude. Nous pouvons continuer ainsi et dcrire des
problmes de diffrents types dans des langages ou des formalismes, quils soient formels, semiformels ou naturel et leur trouver une description quivalente en Maude. En plus de cela, cest laisance
mme quoffre le langage Maude rendre la spcification excutable et fournir ainsi des rsultats quils
soient cibls ou bien selon un jeu de simulation. La deuxime rponse tant que la syntaxe et la
smantique du langage Maude permettent de donner une reprsentation trs prcise de tous les lments
descriptifs de la notation UML [DV01, ATH00, AT00, FT99, Reb03, Reb04].

Figure 8.1 : Reprsentation de diffrents Modles dans le Langage Maude

8.2 Choix dune mthodologie de modlisation

Lors de limplmentation dun systme temps rel, le logiciel est crit d'une part dans un langage de
programmation comme le langage "C" ou ADA, et d'autre part il sappuie sur les services dun noyau
temps rel qui fournit au concepteur tous les outils pour contrler l'environnement logiciel des tches.
Lutilisation de la programmation multitche base sur les algorithmes dordonnancement temps rel

105

permet de mieux respecter les exigences temps rel (respect des contraintes temporises, dlais et
autres).
Les contraintes temporelles qui sont essentielles lors de la construction de larchitecture permettent
justement de valider le comportement temps rel du systme.

8.2.1 Choix dun langage pour la mthodologie

Il est bien connu que SA-RT (Structured Development for Real-Time System) [MW85] est un
langage fonctionnel qui permet de spcifier un systme embarqu temps rel tant du point de vue
logiciel que matriel (architecture). Contrairement la mthode S.A qui reprsente seulement un rseau
de processus transformant des donnes, SA-RT a le mrite dtre une mthode bien adapte pour le
temps rel. Elle prend en compte la notion dvnement et de squencement de lactivation des
diffrents processus ainsi que leur synchronisation. A partir dune spcification SA-RT, CODARTS
dfinit des principes de mise en place dun modle dexcution multi-tches temps rel. SA-RT et
CODARTS proposent des principes intressants mais restent dans le cadre des approches informelles
non validables. Son modle de contrle permet de modliser la dynamique du systme et son
comportement vis vis des stimulations externes. Laspect graphique et la nature hirarchique font que
SA-RT soit une mthode convie pour dfinir la spcification de larchitecture temps rel. Afin de
bnficier des atouts de lapproche objet, UML-RT (UML Real-Time) [SGW94, SR98] est utilise pour
la description des systmes embarqus temps rel. Malheusement, bien que la mthode SA-RT offre un
formalisme plus complet, elle comporte nanmoins certaines lacunes qui la rende moins frquente,
nous citons titre dexemple une syntaxe pas du tout conforme certaines tches, une mauvaise
interprtation des rgles de connexion, et la circulation des donnes entre processus ne sont pas toujours
clairement tablies. Le dictionnaire de donnes et les mini-spcifications peuvent tre dcrites en
langage naturel ce qui en gnral, est un handicap latent causant des interprtations tout fait ambigus.
Devant de telles problmatiques des mthodes structures qui engendrent en gnral une lourdeur
dans linterprtation des modles, mais aussi une complexit de plus en plus difficile matriser, les
mthodes orientes objets se sont tout de suite illustres, assurant par la mme occasion, une efficacit
dinterprtation, une reprsentation des plus exigus et une rutilisation raffine mais aussi la
gnration de code pousant par la mme occasion les concepts des diffrents langages de
programmation orients objets. A titre dexemple, nous pouvons passer trs facilement de la description
UML vers les langages Java, C++ ou autres Comme les approches objets permettent justement une
reprsentation proche du naturel, une adquation permet de les diffrencier [You91, Hil93] des autres
techniques savoir :
Approche Oriente Objet = Classes et Objets + Hritage + Communication par Messages
Plusieurs mthodes se sont imposes, les unes pour le temps rel telle que la mthode HOOD
[Hei87], dautres pour les systmes dinformation et de gestion telles que la mthode OOA Object
Oriented Analysis) de Grady BOOCH lun des concepteurs de UML, Mrise Objet, mais dautres aussi
qui se veulent tre plus gnral telle que la mthode OMT (Object Modeling Technique) [Hil93], et
finalement celle qui a eu un consensus trs large appele UML. Cette dernire (UML) apporte un
langage de modlisation qui se veut universel pour les systmes dinformation mais ne propose pas de
mthodologie ou de cadre formel au dveloppement de logiciel. De plus, lapproche objet, avec son
modle de communication par message, induit une architecture qui peut ne pas tre performante du
point de vue temporel. Des corrections sont alors ncessaires sur le modle dexcution gnr pour
introduire des politiques temps rel. Enfin, la smantique dUML nest pas prcise du fait de son
caractre universel et de la mise en place des diffrentes variations. De nombreuses tudes utilisent
UML comme langage danalyse et lors de la phase de conception, utilisent un langage formel spcifique
pour limplmentation des modles [Sel98, OMG99a, OMG99b, OMG01, Jar98, Har87, Har88,
ABD98, Sch04]. Ceci permet de prciser la smantique du modle et de raliser des preuves. Il est aussi
possible de dcrire directement le systme laide dun langage formel. Il existe de nombreux langages
formels pour la modlisation des systmes concurrents.

106

Toutes les tudes prsentes jusque l, apportent des principes, des solutions ou des modles pour la
mise en place du modle dexcution multitches. Le but de notre tude est de proposer un cadre formel
au dveloppement de systme temps rel, cest dire de formaliser les principes et les solutions
exprimes partir de modles formels. On sintresse plus particulirement la formalisation de la
phase du dveloppement qui aboutit la dfinition du modle dexcution de lapplication. Nous
utiliserons le langage UML et nous prsentons maintenant les diverses phases de lapproche propose.

8.3 La notation UML (Unified Modelling Language)

8.3.1 Les bnfices dUML
Le principal argument en faveur d'UML est son statut de standard de facto. Parmi la multitude de
mthodes OO (et les notations qui leur sont associes), disposer d'un consensus dans leur reprsentation
est un avantage certain.
Bien qu'issu des notations OMT et OOD, UML possde un plus grand pouvoir d'expression que ses
anes et couvre une plus grande partie du cycle de dveloppement. Dans la description des aspects
statiques du systme, la richesse de description est grande et rien ne semble avoir t oubli. La
question de la reprsentation d'un objet ou d'une classe et de ses relations statiques ne se pose plus.
Cet tat de fait nous permet d'esprer un meilleur dialogue avec les clients, qui n'ont plus qu'un seul
formalisme connatre (puisque UML est un standard). De plus, les diagrammes UML sont assez
intuitifs et aiss comprendre, car ils sont une reprise de formalismes prouvs et utiliss depuis une
dcennie. Par ailleurs, les possibilits d'extension [Gue00, TG00, WTB+00] de cette notation la rendent
extrmement adaptable. Ces mcanismes dextension sont multiples et trs intressants. En effet, UML
repose sur une description en 4 couches afin d'tre compatible avec le standard MOF (Meta-Object
Facility) de l'OMG. Chaque couche est une instance de sa couche suprieure, la plus haute couche tant
une instance delle-mme. Ces quatre couches sont :
Le mta-mta-modle : Il dfinit la structure du mta-modle et le langage ncessaire la
dfinition du mta-modle. Il est dfini de manire rflexive.
Le mta-modle : C'est une instance du mta-mta-modle. Il dfinit le langage de la couche
"modle", en loccurrence ici les diagrammes et les lments UML.
Le modle : Il reprsente l'ensemble des modles permettant de dcrire un domaine d'information.
Ce sont, par exemple, les classes dfinies pour le systme en construction.
Les objets utilisateur : C'est une instance du modle. Ce sont les objets du systme excut.
Il est ainsi possible de dfinir des extensions au niveau du modle ou au niveau du mta-modle.
Cela se fait, par exemple, en spcialisant certains lments UML (par utilisation des strotypes et
des valeurs tiquetes). Les extensions du mta-modle pouvant tre regroupes dans un profil UML,
elles peuvent tre alors directement employes dans des modles UML adapts un domaine dtude
particulier.
UML est un langage conu pour spcifier, visualiser et documenter les systmes en gnral et
industriels en particulier. Il est le rsultat d'un large consensus (industriels, mthodologiques...)
d'experts reconnus, donc il est issu directement du terrain et couvre toutes les phases d'un cycle de
dveloppement.
Comme la complexit des systmes (industriels) augmente, lutilisation de techniques de
modlisation efficaces devient aussi important que le projet lui-mme. Donc, la meilleure faon de
choisir le bon modle cest den choisir un standard qui soit visuel pour toucher un maximum
dutilisateurs de diffrentes catgories et de surcrot conception orient objets. Donc, il doit prendre
en charge dans ce sens ce qui suit :

107

Elments du model concepts et smantique de modlisation fondamentale.

Notation description visuelle des lments du modle.

Guidelines idiomes dutilit.

Le choix du type de modle et du type de diagrammes une fois cre permet davoir une influence
profonde sur la faon de prendre en charge le problme, ce qui fournira ncessairement une bonne ou
une mauvaise solution selon ce choix. Un autre point aussi important tant de faire en sorte dutiliser
labstraction comme une cl non des moindres cause de :

Chaque systme aussi complexe soit-il, est mieux prit en charge une fois dcompos en de
petits ensembles de vues indpendantes mais trs proches, ce qui fait quune seule vue est totalement
absurde pour donner un modle trs fiable et reprsentatif.

Chaque modle peut tre exprim des niveaux diffrents de fidlit, mais aussi dabstraction.

Les meilleurs modles sont en relation intrinsques avec la ralit.

En dautres termes, UML permet de dfinir et de visualiser un modle, l'aide de diagrammes. Un

diagramme UML est une reprsentation graphique, qui s'intresse un aspect prcis du modle ; c'est
une perspective du modle, pas le modle lui-mme. Chaque type de diagramme UML possde une
structure (les types des lments de modlisation qui le composent sont prdfinis). Combins, les
diffrents types de diagrammes UML offrent une vue complte des aspects statiques et dynamiques d'un
systme.
En terme de vues dun modle, UML dfinie les diagrammes qui se prsentent sous forme graphique
et qui sont : use case diagram; class diagram; behavior diagrams; statechart diagram; activity
diagram; interaction diagrams; sequence diagram; collaboration diagram etc
Ces diagrammes constituent une plate-forme de modlisation pour mettre en place toutes les facettes
et prendre en charge aussi toutes les perspectives de lanalyse du systme en question mais aussi sa
construction et son dveloppement. Ces diagrammes si on leur rajoute un moyen de documentation
deviennent les premires tapes quun concepteur verra.
Le langage UML se prsente sous des vues diffrentes statiques et dynamiques et qui sont :

8.3.2 Les Classes

Une classe est une description dun ensemble dobjets qui partagent les mme attributs, oprations,
mthodes, relations et smantique. Une classe utilise un ensemble dinterfaces pour spcifier des
collections doprations mises la disposition de son environnement. Elle dfinie la structure de
donne des objets. Les classes peuvent tre abstraites, cest--dire ne possdant pas les moyens de crer
directement leurs propres objets. Tout Objet instanti partir de sa classe contient son propre ensemble
de valeurs correspondant aux caractristiques structurelles (BehavioralFeatures) et tous les objets dune
classe partagent la dfinition de la BehavioralFeature partir de la classe, et tous, ont accs la seule
valeur pour chaque attribut. Cest un classifieur qui permet justement de dclarer ces caractristiques,
ce qui fait quil possde un nom, donc cest une metaclasse.

Classe : smantique et notation

Une classe est un type abstrait caractris par des proprits (attributs et mthodes) communes un
ensemble dobjets et permettent de crer des objets :

Classe = attributs + mthodes + instantiation

La figure suivante nous donne une ide comment une classe doit tre dclare graphiquement. Donc,
nous voyons clairement que la classe possde un nom (voiture), des attributs (marque, immatriculation
) qui peuvent tre public, protg ou priv. De la mme manire, les mthodes dclares peuvent tre
public, priv ou bien protg.

108

Figure 8.2 : Caractristiques dune Classe

8.3.3 Diagramme de Classes

Un diagramme de classes est une collection dlments utiliss pour la modlisation statique dun
ensemble dobjets. En dautres termes, le diagramme de classes fait abstraction des aspects dynamiques
et temporels dun modle. Naturellement au cas o le modle est complexe et fastidieux tablir, la
ncessit dutiliser des diagrammes de classes complmentaires simpose. En gnral, lors de lcriture
du modle, le concepteur se focalise plutt sur les classes qui participent un cas dutilisation (use
case), celles qui sont associes la ralisation dun scnario prcis, celles qui composent un
paquetage et dune faon globale, une attention particulire sera donne en premier lieu la structure
hirarchique dun ensemble de classes.
Si lon considre deux classes appartenant au mme diagramme, ces deux classes peuvent tre relies
par une connexion smantique bidirectionnelle qui est lassociation. Cette association (Figure 8.3) peut
tre instanciable sous forme de liens. Dans le mme sens, on dfinit ce que lon appelle le ou les
rles qui spcifient la fonction d'une classe pour une association donne (indispensable pour les
associations rflexives).

Figure 8.3 : Association entre deux objets

8.3.4 Diagramme de Squence

8.3.4.1 Diagramme de squence : smantique
Les diagrammes de squences permettent de reprsenter des collaborations entre objets selon un
point de vue temporel, on y met l'accent sur la chronologie des envois de messages. Contrairement au
diagramme de collaboration, on n'y dcrit pas le contexte ou ltat des objets, mais la reprsentation se
concentre sur l'expression des interactions. Les diagrammes de squences peuvent servir illustrer un

109

cas dutilisation (use case). Par contre lordre d'envoi d'un message dans une collaboration est
dtermin par sa position sur l'axe vertical du diagramme ce qui permet que le temps s'coule "de haut
en bas" de cet axe. Nous remarquons que les diagrammes de squences et les diagrammes dtatstransitions (statecharts) sont les vues dynamiques les plus importantes d'UML
Dans un diagramme de squence, plusieurs types de messages peuvent tre considrs et qui se
prsentent dans un diagramme comme des strotypes graphiques. Bien entendu, nous avons les
messages simples dpourvus des caractristiques denvoie et de rception. Les messages minuts
(timeout), quon connat bien, cest une sorte de contrainte temporise impose lexpditeur pendant
un certain laps de temps jusqu ce que le destinataire du message se manifeste pendant cet espace de
temps. Pass ce dlai lexpditeur est libr. Les messages synchroniss bloquent l'expditeur jusqu'
prise en compte du message par le destinataire. Le flot de contrle passe de l'metteur au rcepteur
(l'metteur devient passif et le rcepteur actif) la prise en compte du message. Les messages
asynchrones n'interrompent pas l'excution de l'expditeur. Le message envoy peut tre pris en
compte par le rcepteur tout moment ou laiss pour compte (jamais trait).
Sur un diagramme de squence, il est aussi possible de reprsenter de manire explicite les
diffrentes priodes d'activit d'un objet au moyen d'une bande rectangulaire superpose la ligne de
vie de l'objet. On peut aussi reprsenter des messages rcursifs, en ddoublant la bande d'activation de
l'objet concern. Pour reprsenter de manire graphique une excution conditionnelle d'un message, on
peut documenter un diagramme de squence avec du pseudo-code et reprsenter des bandes d'activation
conditionnelles.
8.3.4.2

Envoie de Messages

Lenvoie de messages entre les diagrammes dtats peut tre reprsent par une flche pleine (noir)
de lobjet metteur vers le rcepteur. Les messages doivent tre envoys entre objets, cest dire que le
diagramme doit contenir des objets (non des classes). La flche est libelle du nom dun vnement et
les arguments qui indiquent clairement la rception de lvnement. Chaque diagramme dtats doit
apparatre avec un symbole dobjet reprsentant un objet de collaboration. Les diagrammes dtats
reprsentent les tats de la collaboration des objets.
Lmetteur (du message) peut tre :
Une transition. Le message est envoy suite une action de dclenchement de la transition.
Un objet. Le message est envoy par un objet dune classe des points du diagramme. Le
message est reu par lobjet et peut dclencher une transition sur lvnement correspondant. Il peut y
avoir plusieurs transitions impliquant lvnement en question. Cette notation ne doit pas tre utilise
quand lobjet rcepteur est dtermin dynamiquement, mais dans ce cas une expression (commentaire
textuel) doit tre utilise.
Une transition. La transition doit tre lunique transition de lobjet qui implique un vnement
donn, ou du moins lunique transition qui peut tre dclenche par le message. Cette notation ne doit
pas tre utilise quant une transition choisie dpend aussi de ltat de lobjet recevant est pas
uniquement de lmetteur.

110

Figure 8.4 : Cration et destruction dobjets

La dsignation de classe. Cette notation pourrait tre utilise pour modliser les invocations des
oprations des classes, comme par exemple la cration dune nouvelle instance. La rception dun tel
message peut tre utilis pour dclencher le passage dune transition, ce qui constitue un moyen pour
faire passer les informations du crateur vers le nouvel objet ainsi obtenu.
8.3.5 Diagrammes de Collaboration
Un diagramme de collaboration (Figure 8.5) montre clairement une interaction organise autour des
objets et leurs liens. Comme dans un diagramme de squence, le diagramme de collaboration permet de
tisser les relations entre objets, sans tenir compte du temps comme une dimension les sparant,
cependant les squences de messages et les threads concurrents doivent tre dtermins en utilisant une
squence de nombres.
Le comportement dun diagramme de collaboration est implment grce des ensembles dobjets
changeant des messages qui interagissant pour accomplir un but. Pour comprendre les mcanismes de
fonctionnement des diagrammes de collaboration, il est important de ne voir que les objets et les
messages qui sassocient pour accomplir un objectif trac par le systme dans lequel ils sont partie
prenante.
Une collaboration tant un ensemble de participants et des relations ayant une signification pour
accomplir un objectif, ce qui fait que lidentification des participants na pas une grande importance.
Une collaboration doit tre lie une opration ou un use case pour dcrire le contexte dans lequel
leur comportement survient. Le comportement actuel peut tre spcifi par des interactions, tels les
diagrammes de squences ou les diagrammes de collaboration. Une collaboration peut aussi tre relie
une classe pour dfinir la structure statique de celle-ci.
Une collaboration paramtre reprsente un design qui peut tre utilis de manire itrative dans
diffrentes architectures. Les participants dans une collaboration hormis les classes et leurs relations,
mais aussi les paramtres dune collaboration gnrique. Une collaboration peut tre exprime des
niveaux diffrents de granularit. Une collaboration au sens large peut tre raffine pour produire une
autre collaboration granularit plus fine.
La description du comportement dune collaboration conduit considrer deux aspects : la
description structurelle de ces participants et la description de comportement de ses excutions. Les
deux aspects sont souvent dcrits ensemble dans un mme diagramme mais des priodes utiles leur
description spare. La structure des objets jouant un rle dans ce comportement et leurs relations est
appele collaboration, et cette collaboration montre clairement le contexte dans lequel cette interaction
se produit. Le comportement dynamique des squences de messages changs par les objets est appel
interaction.

111

Cependant, un diagramme de collaboration peut aussi tre dfini comme un graphe qui fait rfrence
aux objets et leurs liens avec les flots de messages. La collaboration est utilise pour dcrire une
opration associant ses arguments et les variables locales cres durant une excution aussi bien que les
associations ordinaires.
Les objets cres durant une excution (Figure 8.4) sont dsigns par {new}; les objets dtruits durant
cette excution sont dsigns par {detroyed}. Par contre ceux cres puis dtruits durant une excution
portent dsormais le label {transient}. Ces changements dans un cycle sont drivables partir des
messages envoys par les objets.
Le diagramme montre aussi les liens entre les objets, incluant les liens reprsentant les arguments,
les variables locales, et les self links.
Les valeurs des attributs individuels ne sont en gnral pas montr explicitement. Si les messages
doivent tre envoys des valeurs dattributs, les attributs doivent tre dans ce sens modliss en
utilisant des associations.
Un diagramme de collaboration dpourvu de messages doit montrer clairement le contexte dans
lequel les interactions surviennent.

Figure 8.5 : diagramme de Collaboration

8.3.6 Diagramme de Statechart (Diagramme de transitions)
Un diagramme statechart [Har87, Har88, ABD98] (Figure 8.6) reprsente une machine dtats. Les
tats sont reprsents par des symboles dtats et les transitions sont reprsentes par des flches,
faisant la connexion des tats. Les tats peuvent contenir des sous diagrammes.
8.3.6.1

Etats

Un tat dans ce sens est une condition tablie durant le cycle de vie dun objet, mais aussi, il peut
tre considr comme une interaction durant lequel il (ltat) satisfait certaines conditions, excute une
action ou bien il attend un vnement. Un objet par convention ne doit rester dans un tat que pendant
un temps fini (non-instantan).
Les actions sont atomiques. Un tat peut correspondre une activit qui se met en route. Cette
activit est reprsente par une paire dactions, lune qui dclenche lactivit sur ltat et lautre qui
termine lactivit en sortie de ltat.
Chacune des sous rgions dun tat peut contenir des tats initiaux et des tats finaux. Une transition
incidente lintrieur dun tat est considre comme une transition qui concoure vers un tat initial.
Une transition vers un tat final reprsente lachvement de lactivit dans une rgion enferme,
lachvement de lactivit dans toutes les rgions concurrentes reprsente lachvement de lactivit
112

par ltat enferm et provoque un vnement particulier qui est achvement de lactivit dans cet
tat (enferm). Lachvement dun tat qui se trouve lextrieur constitue le signe que lobjet en
question est mort.

Figure 8.6 : Un Statechart correspondant un Systme dappel Tlphonoque tir de la litrature.

Un tat est matrialis graphiquement par un rectangle aux coins arrondis. Il peut contenir un ou
plusieurs compartiments qui sont dailleurs optionnels. Chaque compartiment doit possder :
Un nom de compartiment. Une chane de caractres. Les tats dpourvus de nom sont considrs
comme quelconques anonymous et doivent tre distincts. Il est indsirable de rencontrer le mme
nom deux fois et plus, ceci risque de causer la confusion.
Transition interne un compartiment. Tiens dans une liste dactions internes ou dactivits
excutes en rponse aux rponses reus, le moment ou lobjet tait dans ltat en question, sans
changement dtat. Cette transition est dclare dans le format suivant :
event-name argument-list [ guard-condition ]/ action-expression.
Chaque nom dvnement ou de pseudo-vnement peut apparatre au plus une seule fois dans un
tat singulier.
Les actions spciales suivantes possdent la mme forme mais reprsentent les mots rservs qui ne
peuvent pas tre utiliss comme noms dvnements :

entry / expression daction Une action atomique qui sexcute lentre de l tat

exit / expression daction Une action atomique qui sexcute en sortie de ltat

Les actions entry et exit ne doivent pas contenir dans leur corps des arguments ni des conditions
guard (tout simplement parce quils sont invoqus implicitement et non explicitement). Cependant,
laction entry au top niveau de la machine dtats doit avoir des paramtres qui reprsentent les
arguments quelle reoit au moment de sa cration.
Les expressions de type action, peuvent utiliser les attributs et les liens de lobjet et des paramtres
quils possdent des transitions incidentes intrieurement (sils apparaissent dans toutes les transitions
incidentes intrieurement).
Le mot-cl suivant reprsente linvocation dune machine dtats (incorpore)
do / machine-name (argument-list)
Exemple 8.1

113

Figure 8.7 : Sous-tats Squentiels

Figure 8.8 : Sous-tats Concurrents dans un Statechart

8.3.6.2

Etats concurrents et barre de synchronisation

Pour reprsenter des tats concurrents sur un mme diagramme d'tats-transitions, on utilise la
notation un symbole spcial : "la barre de synchronisation". La barre de synchronisation permet de
reprsenter graphiquement des points de synchronisation. Les transitions automatiques qui partent d'une
barre de synchronisation ont lieu en mme temps. On ne franchit une barre de synchronisation quaprs
ralisation de toutes les transitions qui s'y rattachent
Exemple 8.2

Figure 8.9 : Expression des Barres de Synchronisations dans un Statechart

8.3.7 Diagramme dActivit
Un diagramme dactivit (Figure 8.10) est un cas spcial dun diagramme dtats dans lequel tous les
tats (ou du moins un certain nombre) du systme sont des tats-actions et dans lequel toutes les
transitions (ou du moins un certain nombre) peuvent tre tires par compltude des actions dans les
tats sources. Le diagramme dactivit est dans ce cas attach une classe ou limplmentation dune

114

opration ou dun cas dutilisation (use case). La proposition dun tel diagramme tant de se focaliser
sur les flux (flows) internes. Lexemple suivant nous donne une ide sur la possibilit dcrire des
diagrammes dactivits qui soient trs expressifs.

Figure 8.10 : Un Diagramme dActivit

8.4 Vue Gnrale Sur le Langage OCL

Dans cette partie, nous introduisons Object Constraint Language (OCL) [WK99, OMG01, JAR98,
RG00] un langage formel utilis pour spcifier les contraintes ainsi que dautres expressions associes
aux modles UML.
Pour tre plus prcis, OCL est utilis pour exprimer les rgles bien-formes du metamodel UML.
Chaque rgle bien-forme contient une expression OCL, qui est en ralit un invariant. Naturellement
OCL possde une grammaire consigne dans les manuels de lOMG.

8.4.1 POURQUOI OCL?

Dans la modlisation oriente-objet, un model graphique, orient classe nest pas assez prcis pour
dcrire tous les lments qui lui sont rattachs. Dans ce cas, nous avons besoin de concepts pour dcrire
les contraintes additionnelles qui sont en gnral, dcrites dans le langage naturel (l Anglais dans la
plus part des cas). Devant une multitude de cas (modlisation), lexprience a montr quun tel procd
gnre en gnral des spcifications ambigus.
Le langage OCL a t dvelopp depuis la version 1.3 de lML est utilis comme un langage de
modlisation des processus adapts au business (affaires) par IBM Insurance division justement pour
viter les problmes lis linconsistance et lambigut des modles dvelopps. Cest un langage
qui scrit dans une syntaxe formelle tout fait simple. Une expression crite dans le langage OCL ne
peut en aucun cas influencer le systme (changement dtat), mais elle peut tre utilise expressment
pour un changement de ltat du systme, mais dans ce cas en utilisant une primitive de post-condition.
Quand une expression OCL est value, elle dlivre tout simplement une valeur. Nous notons quOCL
nest pas du tout un langage de programmation dans le sens ou aucune logique ne ferra suite une
succession de directive dans le sens dobtenir des rponses logiques pour matrialiser le fonctionnement
dun processus. Dailleurs OCL nest mme pas adapt pour le contrle des flux de donnes. OCL est

115

un langage typ dans la mesure ou toute expression possde un type et donc chaque expression est par
consquent conceptuellement atomique.

8.4.2 Dans quel cas utiliser OCL

OCL peut tre utilis pour les besoins suivants :

Pour spcifier les invariants sur les classes et sur les types dans une classe.

Pour spcifier les invariants typs sur les strotypes.

Pour dcrire les pr- et post-conditions sur les oprations et sur les mthodes.

Pour dcrire les Gardes.

Comme un langage de navigation

Pour spcifier les contraintes sur les oprations:

8.4.3 Invariants
Lexpression OCL peut tre considre comme un invariant lorsque cest une contrainte strotype
avec invariant. Cette expression dans ce cas doit tre vraie pour toutes les instances du type concern
et tout moment.
Dans lexpression,
self.numberOfEmployees

self est une instance de type compagnie. Nous pouvons voir que self se comporte comme un objet
partir duquel nous pouvons commencer lexpression.
Dans ce document, le type de linstance contextuelle de lexpression OCL qui fait partie de
linvariant, est crite avec le nom du tuple soulign comme suit :
Company
self.numberOfEmployees

Dans la plupart des cas lcriture de self peut tre remplace par un nom de variable. Dans lexemple
suivant, il est remplac par le nom c.
c : Company
c.numberOfEmployees

Ces deux expression sont tout fait quivalentes.

8.4.3.1

PRE- et POSTCONDITIONS

Une expression OCL peut aussi exprimer une Pr ou Post-condition, qui nest dautre quune
contrainte strotype par les expressions prcondition et postcondition. La notation de lcriture
dune telle expression OCL seffectue en posant les labels pre et post des Prcondion et
Postcondition comme suit :
PostconditionsTypename::operationName(parameter1 : Type1, ... ): ReturnType
pre : parameter1 >
post: result = ...

Exemple :
Person::income(d : Date) : Integer
post: result = ...some function of self and parameter1 ...

116

8.4.4 Expressions Gnrales

Certaines expressions OCL peuvent tre utilises comme des valeurs des attributs de classes ou lun
de ces sous-types.
8.4.4.1

Valeurs de Base et Types

Le langage OCL admet les types de valeurs et des oprateurs selon ce qui suit :
type

values (example)

Boolean

true, false

Integer

1, 2, 34, 26524, ...

Real

1.5, 3.14, ...

String To be or not to be...

type

operations

Integer

*, +, -, /, abs

Real

*, +, -, /, floor

Boolean

and, or, xor, not, implies, if-then-else

String

toUpper, concat

Chaque expression OCL est crite dans le contexte du model UML, un nombre de types/classes leurs
caractristiques et leurs gnralisations. Toutes les types/classes dans UML sont considrs comme des
types dans OCL.

8.4.4.2

Types et Enumration

Les types numration peuvent tre dfinis en utilisant len tte enum comme :
enum{value1, value2, value3}

Les valeurs de lnumration (value1, ...) peuvent tre utilises avec des expressions. Lutilisation
dune valeur de type numration doit tre prfixe par le symbole # . Exemple :
#value1

Le type dun attribut numration est Enumration, avec restriction sur les valeurs de lattribut.
8.4.4.3

Conformation

OCL est un langage typ ce qui fait que les types de bases sont organiss selon une hirarchie, ce qui
assure une certaine conformation des diffrents type vis--vis les uns des autres. Par exemple, il nest
pas possible de comparer un integer avec un boolen ou avec les string. Les rgles qui assurent cette
conformation sont trs simples selon :

Chaque type doit tre conforme son supertype.

Le type de conformation est transitive: if type1 est conforme au type2, and type2 est conforme
au type3, alors type1 est conforme au type3.
Example :
OCL expression
1 + 2 * 34

117

valid?
yes

error

1 + motorcycle

no

type Integer nest pas conforme au type String

23 * false

no

type Integer nest pas conforme au type Boolean

12 + 13.5

yes

8.4.4.4

Proprits: Attributs

Exemple, lage dune Personne est crit comme,

Person
self.age

La valeur de cette expression est la valeur de lattribut age Person self. Le type de cette expression
est le type de lattribut age qui est un type de base Integer .
Donc, avec les attributs et les oprations dfinies sur des valeurs de type de base, nous pouvons ainsi
raliser des calculs. Par exemple the age of a Person is always greater or equal to zero. Ceci scrira
comme un invariant :
Person
self.age >= 0

8.4.4.5

Proprits : Oprations

Dans le langage OCL, les oprations peuvent avoir des paramtres. Par exemple, un objet Person
possde un revenu, ceci sexprime par la fonction (date) :
aPerson.income(aDate)

Lopration elle-mme peut tre dfinie par une contrainte post-condition. Lobjet retourn par
lopration est refer par le label result. Il prend la forme suivante :
Person::income (d: Date) : Integer
post: result = -- some function of d and other properties of person

Une opration ou une mthode qui ne prend pas dargument peut simplement tre dclare avec des
parenthses vide.
Exemple :
Company
self.stockPrice()

8.4.4.6

Proprits : Fins dAssociation

A partir dun objet spcifique, nous pouvons adjoindre une association sur le diagramme des classes
pour se rfrer dautres objets et leurs proprits. Dans ce cas, considrons lassociation en utilisant
lassociation oppose (association-end) :
object.rolename

La valeur de cette expression est lensemble des objets sur lautre cot de lassociation rolename. Si
la multiplicit de lassociation possde un maximum de 1 (0..1 or 1), alors la valeur de cette
expression est un objet. Par exemple (i.e. self est une instance de Company), nous pouvons crire :
Company

118

self.manager -- is of type Person

self.employee -- is of type Set(Person)

Lvaluation de la premire expression rsultera dans un objet de type person, parce que
lassociation de la multiplicit est un. Lvaluation de la deuxime expression, rsultera dans
lensemble des personnes.
Les collections de type ensemble, Bags et Squences sont tous prdfinis Type dans le langage OCL.
Une proprit de collection elle-mme est accessible en utilisant la flche . Exemple :
person:
Person
self.employer->size

Cette criture dfinit la taille de la proprit sur lensemble self.employer, qui est le nombre des
employs de Person self.
Person
self.employer->isEmpty

Lvaluation de cette expression est true si lensemble des employs est vide (empty), sinon
false
8.4.4.7

Combinaison de Proprits

Les proprits peuvent tre combines les unes aux autres pour construire des expressions plus
compliques.
Les expressions suivantes dfinissent des invariants qui utilisent des proprits combines :
[1] Married people are of age >= 18
self.wife->notEmpty implies self.wife.age >= 18 and
self.husband->notEmpty implies self.husband.age >= 18

[2] a company has at most 50 employees

self.employee->size <= 50

[3] A marriage is between a female (wife) and male (husband)

self.wife.sex = #female and
self.husband.sex = #male

[4] A person can not both have a wife and a husband

not ((self.wife->size = 1) and (self.husband->size = 1))

8.4.5 Caractristiques Prdfinies sur Tous les Objets

Il existe plusieurs caractristiques appliques tous les objets et qui sont prdfinies dans OCL,
savoir :
oclType : OclType
oclIsTypeOf(t : OclType) : boolean
oclIsKindOf(t : OclType) : boolean

L oclType redclare le type dun objet. Par exemple, lexpression

Person
self.oclType

119

Lopration isTypeOf fournie true si le type de self if the type of self et t sont quivalent. Par
exemple:
Person
self.oclIsTypeOf( Person ) -- is true
self.oclIsTypeOf( Company) -- is false

8.4.6 Collections
Dans le langage OCL, il est possible de dfinir des Collections qui est un type abstrait de donnes,
partit duquel nous pouvons dfinir un sous type qui est du type collection mais concret. OCL fait la
distinction entre trois types de collections qui sont :

set : ensemble au sens mathmatique, mais ne doit pas contenir des lments dupliqus,

sequence (squences = chaine) et

bag (sac) : cest exactement la mme dfinition que bag seulement les lments doivent tre
ordonns.

Exemple 8.3
Ensembles
Set { 1 , 2 , 5 , 88 }
Set { apple , orange, strawberry }

Sequence
Sequence { 1, 3, 45, 2, 3 }
Sequence { ape, nut }

Les squences suivantes dfinissent une squence de nombres entiers compris entre llment devant
et aprs les deux points successifs .. . Ce qui veut dire que les deux expressions suivantes ont mme
valeurs :
Sequence{ 1..(6 + 4) }
Sequence{ 1..10 }

et ils sont identiques lexpression : Sequence{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 }

Bag
Bag {1 , 3 , 4, 3, 5 }

Exemple 8.4
Company
self.employee
collection1->union(collection2)

Il est aussi admis dimbriquer les collections entre elles, par exemple :
Set{ Set{1, 2}, Set{3, 4}, Set{5, 6} }
Set{ 1, 2, 3, 4, 5, 6 }

Donc ces deux expressions sont quivalentes.

Nous admettons dune faon gnrale que :
Tout type de Collection (X) est un sous-type de OclAny. Les types Set (X), Bag (X) and
Sequence (X) sont tous des sous-type de Collection (X).
Les rgles de conformation des types sont dfinies comme suit :

120

 Type1 est conforme avec Type2 lorsquils sont identiques (rule standard pour tous les types).
Type1 est conforme avec Type2 lorsque cest un sous-type de Type2 (rule standard pour tous les
types).
Collection (Type1) est conforme Collection(Type2), lorsque Type1 est conforme avec Type2.
La conformation des Types est transitive: if Type1 conforms to Type2, and Type2 conforms to
Type3, then Type1 conforms to Type3 (rule standard pour tous les types).
Par exemple, si Bicycle et Car sont deux sous-type diffrents de Transport, nous pouvons dfinir :
Set(Bicycle) est conforme Set(Transport)
Set(Bicycle) est conforme Collection(Bicycle)
Set(Bicycle) est conforme Collection(Transport)
Notons que Set(Bicycle) nest pas conforme Bag(Bicycle).Ils sont tous les deux des sous-types de
Collection(Bicycle) au mme niveau de hirarchie.
8.4.7 Valeurs Prcdentes dans Les Postconditions
Nous savons quil est possible de spcifier pre- et post-conditions sur les oprations et les mthodes
en UML/OCL. Dans une postcondition, lexpression peut se rfrera deux ensembles de valeurs pour
chaque proprit dun objet:
La valeur d'une proprit au dbut dune opration ou dune mthode.
La valeur dune proprit aprs lachvement de lexcution dune opration ou dune mthode.
Pour se referez la valeur dune proprit dans au dbut dune opration, il suffit de postfixer le
nom de la proprit avec le signe commercial @, suivit du mot cl pre:
Person::birthdayHappens()
post: age = age@pre + 1

Dans cet exemple, la proprit age fait rfrence la proprit de linstance de Person sur laquelle
on effectue lexcution. La proprit age@pre fait rfrence la valeur de la proprit age de Person
qui excute opration au dbut de lopration.
Si la proprit possde des paramtres, @pre est postfix propertyname, avant les paramtres.
Company::hireEmployee(p : Person)
post: employees = employees@pre->including(p) and
stockprice() = stockprice@pre() + 10

Lopration prcdente peut aussi tre spcifie par une post- et pre-condition crite ensemble :
Company::hireEmployee(p : Person)
pre : not employee->includes(p)
post: employees->includes(p) and
stockprice() = stockprice@pre() + 10

Quand une pr-value est une proprit qui value un objet, toutes les proprits qui accdent cet
objet sont les nouvelles valeurs la fin de lexcution de lopration de cet objet, alors :
a.b@pre.c -- prend lancienne valeur de la proprit b de a, disons x, puis la
nouvelle valeur de c de x.
a.b@pre.c@pre -- prend lancienne valeur de la proprit b de a, disons x et puis
lancienne valeur de c de x.

121

Nous avons dfini jusque l une partie trs importante du langage OCL, sans pour cela introduire
toutes les oprations admissibles qui nous auraient permis de manipuler titre dexemple les
Collections. Nous invitons le lecteur consulter des ouvrages spcialiss, entre autres la version 1999
de UML/OCL syntaxe et smantique [OMG99a] et la version 2001 [OMG01].
Dans la suite de notre expos, nous allons nous atteler concrtiser notre point de vue sur
lutilisation du langage UML/OCL travers un exemple de systme ractif que nous avons dj cit
auparavant. Il sagit du systme Train-gate-controller (passage niveau).

8.5

Modlisation
UML/OCL

du

systme

Train-Gate-Controller

en

La description des proprits du systme, est une activit dcisive pour assurer quun produit sera
correct dans le future. La consistance du systme dpend de lhabilit des concepteurs pour mettre en
place toutes les proprits qui dfinissent le comportement du systme avec un risque zro.
Cependant, une description dtaille du systme TGC est donne dans [EN97, JS00, Be96]. Cette
description inclus la connaissance du domaine comme un lment trs important pour la spcification
formelle du systme. Le systme TGC, considre comme une application rpartie en trois soussystmes : le train qui est un systme qui se dplace sur des rails dun point (disons) de dpart vers un
autre point (disons) darrive de faon continue. Donc, nous considrons que le train contient en son
sein un dispositif de communication qui peut envoyer des messages renseignant sur sa position sur un
tronon de rail. Un contrleur automatique utilis pour manipuler une barrire automatique lui donnant
des ordres de mouvement dune position prcise (position de repos) vers le haut, et dans le cas oppos
un ordre de mouvement vers le bas lui est intim vers la position de repos. Le systme contrleurbarrire se trouve proximit de toute intersection dune route usage pour vhicule et une autre (rails)
pour les trains. La zone dintersection est appele la zone dangereuse, quon appellera aussi la zone de
passage. Le troisime sous-systme tant un systme de contrle centralis.

8.5.1

Lapproche de modlisation par le langage UML

Donc, selon ce qui vient dtre cit, le systme tant constitu de trois sous-systmes qui
communiquent entre eux. Le systme complet est dcrit par le diagramme de classe de la Figure 8.12.
Pour ne pas trop tergiverser sur le fonctionnement du systme complet qui est form de trois soussystmes, une attention particulire est donne dans la Figure 8.11 et 8.12. Le lecteur ne trouvera aucun
difficult comprendre larchitecture mais aussi le fonctionnement cest--dire son comportement.
Nous comprendrons mieux tous les aboutissants travers les rgles OCL

Figure 8.11 : Diagramme dtat du TGC

122

8.5.2 Spcification de Contraintes en OCL

Lutilisation dun langage unifi et standardis permet doutre passer toutes les divergences au sein
dun groupe de concepteurs qui en gnral possde des connaissances diverses touchant pratiquement
plusieurs disciplines. Comme nous lavons vu, lide de lutilisation du langage OCL, permet dassocier
des contraintes aux objets dun systme pour quil soit spcifi formellement, prservant toutes les
caractristiques structurelles et dynamiques du systme. Cette manire de reprsentation permet ainsi
dassocier le formel avec le graphique, ce qui coup sr permet dviter lincomprhension,
lambigut et ainsi assur lexactitude de la spcification, et de traiter des problmes trs complexes
sans risque majeur. Nous avons vu, quOCL met en place des mcanismes dcriture assurant la
rfrence aux lments des classes, la notion de typage, la reprsentation de contraintes sous forme
de pre et post-conditions, lexpression de caractristiques du temps etc.
Dans ce qui suit, nous montrons certaines recommandations du langage OCL, pour spcifier un
certain nombre de proprits de notre systme, savoir le TGC (train-gate_controller). Nous
commencerons par exemple par les proprits qui expriment la sret du systme du moins certains
comportements du systme (Safety).
Comme la proprit la plus importante du systme tant de prserver le trafic routier dun ct et de
permettre au train de passer sur la zone dangereuse (lintersection) sans encombre, cependant un
niveau dabstraction (lev) de la spcification de control, il est tout fait suffisant de modliser la zone
du passage niveau et la barrire automatique et ceci tout instant.
Les contraintes OCL suivantes (invariants) spcifient ce qui suit (voir Figure 8.15) :
1. Sil existe un train traversant la zone dintersection alors la barrire doit tre ferme :
context CrossingArea inv:
not(self.train ->isEmpty()) implies self.barrier.state=Closed
2. Si la barrire automatique est ouverte alors aucun train ne sest approch de la zone dangereuse :
context Barrier inv:
self.state=Opened implies self.guards.train ->isEmpty()
3. La barrire automatique doit tre ferme lorsquun train passe sur la zone dangereuse :
context PhysicalTrain inv:
self.crosses.barrier=Closed
Ces contraintes doivent tre respectes (vraie). Pour le moment il nest pas ncessaire dexpliquer
physiquement comment lavant des trains et leurs queues sont dtectes pour connatre les positions de
certaines variables du modle de spcification soient vrais. Ceci n' a pas une trs grande importance
pour le moment, il suffit pour le moment que le train sapproche de la zone, quil soit dans la zone ou
bien quil soit sorti de la zone.
La spcification des positions (tats) de la barrire peut tre dcrite par les contraintes OCL
suivantes (Figure 8.12):
4. Le feu rouge est allum (switched on) chaque fois que la barrire est ferme et que le feu jaune
soit allum lorsque la barrire se ferme. Si le feu rouge et le feu jaune sont teints alors la barrire est
ouverte:
context TGC System inv:
self.theBarrier.state=Closed implies self.redLight.state=On
and
self.theBarrier.state=Closing implies
self.yellowLight.state=On and
self.yellowLight.state=Off and self.redLight.state=Off
123

implies self.theBarrier.state=Opened

Figure 8.12 : Diagramme de Class du TGC

5. Lorquil reste encore un train dans la zone dangereuse, ltat level crossing est en position
activated state. La variable activated state est compose de trois sous-tats (WaitingAck, Closing,
Closed, Opening) :
context TGC System inv:
not(self.train ->isEmpty()) implies self.state=Activated
and
Set(Activated)=Set(WaitingAck->Union(Closing)->Union(Closed)->
Union(Opening))
6. Lorsque le systme TGC est position activated state et la barrire soit ouverte alors ltat level
crossing est en mode unsafe :
context TGC System inv:
self.state=Activated and self.bSensor.state=Opened
implies self.mode=Unsafe
7. Si la barrire est ferme alors que le sensor indique que la barrire est ouverte alors ltat the level
crossing est dans le mode unsafe. Ceci, ne se fait que si la barrire soit dans ltat entrain de se
fermer , dans ce cas le systme reste unsafe jusqu ce que la barrire soit compltement ferme. :
context TGC System inv:
self.bSensor.state=Opened and self.theBarrier.state=Closed)
implies self.mode=Unsafe
Les oprations de la classe TGC sont spcifies avec les pr- et post-conditions de lOCL.
OCL est aussi utilis pour la spcification des contraintes dans le diagramme de squences pour
lcriture des pre-conditions et des invariants sur les oprations (diagramme de squence train
approaching). Par contre le diagramme des tats est utilis pour driver une premire spcification de
chaque opration. Dans ce cas les contraintes OCL sont dune importance capitale pour donner plus de
prcisions aux informations qui ne peuvent pas figures sur le diagramme dtat.

124

Figure 8.13 : Diagramme de Squence du Sous-systme Train

Considrons titre dexemple, la fermeture de la barrire actionne par lvnement timeOut 1. La
pr-condition de lopration closeBarrier doit vrifier que le feu jaune soit allum avant denvoyer
lordre de fermeture la barrire. Elle a aussi vrifier que la barrire nest pas encore ferme. La postcondition assure que le feu jaune soit teint, le feu rouge soit allum et que la barrire soit ferme. Cette
opration est spcifie par :
context TGC System::closeBarrier
pre:
self.yellowLight.state=On and self.theBarrier.state=Opened
post:
self.yellowLight.state=Off and self.redLight.state=On and
self.theBarrier.state=Closed
La pr-condition de lopration openBarrier qui est active par lvnement trainDetectionRear
vrifie que la barrire soit ferme et le systme TGC est en mode safe.
La post-condition assure que la barrire est dans ltat ouvert opened state:
context LCC System::openBarrier
pre: self.theBarrier.state=Closed and self.mode=Safe
post: self.theBarrier.state=Opened

Figure 8.14 : Diagramme de Squence : Scnario dun train qui approche

125

Figure 8.15 : Contraintes pour spcifier le passage Niveau

8.6

Labstraction des contraintes temporelles en UML/OCL

Plusieurs auteurs ont dmontr [Ste03, GO03,RW99,GOO03, RKT+00] quOCL nadmet pas ou
nest pas capable dans sa version actuelle de modliser les contraintes temporelles, sauf qu un degr
moindre les outils mis la disposition du concepteur ne traitent quune partie infime du langage UML,
savoir les messages. Les contraintes temporelles, mme si celles-ci peuvent tre exprimes dans le
type de diagrammes suivants :

State diagrams, ou elles apparaissent tiquetant les transitions.

Sequence diagrams, ou les contraintes temporelles peuvent se baser sur le fait de choisir entre
les observations temporises ou temporelles.

Dans tous ces diagrammes les contraintes temporelles ont toutes la mme signification et la mme
expressivit.
De nombreux chercheurs se sont intresss la normalisation dUML, sa formalisation ou son
utilisation dans une approche mixte. Pour cette raison, dresser un tat de lart exhaustif de toutes les
approches existantes serait illusoire.
En effet, pour la quasi-totalit des modles formels prsents prcdemment, il existe des travaux de
couplage avec UML. Ainsi, des propositions sont disponibles pour : les langages Z [Led96], B
[LM00, MLL00, Mar00], LOTOS [CLA00], des logiques temporelles [KNR02] des automates
temporiss [RKT00] etc.

8.7

Traduction du langage UML vers

MAUDE

Dans lordre dexprimer le bien-fond de traduire les modles UML vers le langage MAUDE et ainsi
obtenir une forme universelle excutable, nous allons le dmontrer travers un exemple simple.
Lexemple en question reprsente, le modle dune bibliothque. Pour bien expliquer notre ide, il
sagit de ne considrer quune partie aussi gnrale que possible et nous lessons le soin aux lecteurs de
deviner les dtails qui se trouvent consigns dans les travaux de F. Duran et al. [DV01] et [Reb05].
Dans un premier temps nous commencerons par une spcification informelle dune bibliothque, qui
sera crite dans le langage UML et par la suite elle sera raffine et crite dans le langage MAUDE.
Dans cette bibliothque, nous identifions, quatre rles, appels communment, borowers, library
items, calendars et librarians. Par mesure dintgrit, nous prfrons garder la dnomination de tous
les lments de ce modle dans la langue de Shakespeare, mais a nempche pas de les traduire,
dailleurs la traduction est lmentaire, par exemple borrowers veut dire emprunteurs donc les lecteurs

126

dune faon juste. Labrary items, ce sont les livres, les journaux et autres, calendars veut dire
calendriers ou plus prcisment dates (demprunt et de retour), librarians, il sagit de lagent libraire.
Revenons maintenant notre modle. Il y a trois types de lecteurs (personnel acadmique, tudiants en
graduation et tudiants en postgraduation, appelons-les : academic staff, undergrads et postgrads. Les
lecteurs peuvent emprunter deux catgories darticles books et periodicals (livres et periodiques). La
communaut de la bibliothque peut tre vue comme tant compose dun calendrier, dun ou de
plusieurs agents libraires, darticles et des lecteurs. Un lecteur peut emprunter des livres et/ou des
priodiques. Toutes ces informations sont consignes dans la Figure 8.16. Nous devons noter que
chaque objet (information) remplie un et un seul rle, quoique nous devons considrer par exemple, le
staff acadmique ou les tudiants se comporter exactement comme les libraires, il suffit pour cela
dintroduire des relations dhritages en sus. Lutilisation des diagrammes de classes pour la description
de la structure de la communaut, a t propose par plusieurs auteurs [DV01]. Dans notre cas, nous lui
avons apport quelques modifications pour tayer notre point de vue publi dans [Reb05].
Nous notons que les attributs et les oprations de chaque classe dfinissent linformation de base de
la spcification. Mis part les attributs (title, author, et ISBN des livres et nom et adresses des lecteurs),
dautres attributs mritent quelques explications :
La priode de prt prescrite et la limite qui est impose sur le nombre darticle emprunter
chaque emprunt qui est spcifi respectivement par les attributs maxloans et loanPeriods de la classe
Library.
Le lecteur qui ne retourne pas le ou les articles en sa possession au moment de la date de retour
fixe doit tre pnalis. Le montant de cette pnalit ainsi que le nombre darticles emprunts sont
gards (mmoriss) dans les attributs fines et borrowedItems de la classe Borrower.
Les lecteurs peuvent tre suspendus par lagent libraire, sils ne payent pas lamande en question,
cette situation sera consigne par lattribut status de la classe Borrower and suspendedUsers de la
classe Library. La valeur de ces attributs doit tre consistante, ce qui ncessitent une reprsentation
dune telle situation par lutilisation de contrainte qui sera considre comme un invariant.
Les attributs status de la classe Item dfinissent ltat dun article matrialis par les valeurs
possibles on loan , free , ou disposed au cas ou le livre t dtruit ou tout simplement perdu.
Lattribut location de la classe item dcrit lemplacement sur les tagres de larticle correspondant
quant il est disponible dans la bibliothque.
Finalement, nous dfinissons les oprations borrow, return et pour illustrer comment les oprations
sont modlises dans notre approche.
Supposons, maintenant que nous voulions dcrire le modle UML de notre cas dtude
(bibliothque), cest--dire de traduire cette spcification directement en Maude, la traduction se
prsentera comme suit :
Dans un premier temps, nous prsenterons tous les acteurs intervenant dans la collaboration et nous
commencerons par les lecteurs qui est une classe part entire savoir :
class reader | code : Nat, name : string, address : string, status : ReaderStatus,
ReaderItem : Nat, fines : pointsNomber .
Including MACHINE-INT .
Including Qid .
Including CONFIGURATION .
sort Reader ReaderStatus .
subsort Reader < Cid .
ops suspended released : ReaderStatus .
var Academic-staff PostGrad-stud UnderGrad-stud : Reader .

127

var reader : Reader .

var Rayan : Oid .
rl [change_status] <Rayan : reader | readerStatus : nil> <L : Librarian >(set_Suspended)

<Rayan : reader | reader_status : suspended><L : Librarian | suspendedUsers : reader_name> .

La rgle change_status (ci-dessus) traduit le comportement concurrent des objets appartenant la
classe reader et ceux de la classe Librarian. Linteraction influence par le message set_suspended
permet de balancer ltat du reader de nil vers Suspended tout au dbut, et rajoute le nom du lecteur
la liste des lecteurs supendus.
Comme le lecteur lui appartient interagir sur lune des classes suivantes, ces derniers sont traduites
en MAUDE comme suit :
class academic

| dept : string, faculty : string .

class postGrad

| dept : string, authoriser : string .

class undergrad | faculty : string, dept : string, tutor : string .

Les trois classes (academic, postGrad, undergrad) sont des sous-classes de la classe reader et par
consquent elles seront dclares par :
subclasses academic postGrad undergrad < reader .
Lune des classes les plus importantes qui est dailleurs linterface entre le lecteur (reader class) et
les classes Book et Periodic tant la classe item. Ces trois classes seront traduites comme suit avec une
petite diffrence cest que les classes Book et Periodic sont considres comme des sous-classes de la
classe item :
class Item | location : string, status : ItemStatus, title : string .
class Book | author : string, ISBN : string, quantity : Nat, year : Nat, code : string,
observation : string .
class Periodical | ISSN : string, date : Date, number : Nat .
subclasses Book Periodical < Item .
Lopration suivante permet de procder une diminution de qtyAvaillable dune unit lorsque un
article (book ou periodical) vient dtre rendu. Cette opration matrialise par une rgle de rcriture,
tmoigne de laisance mme du langage MAUDE exprimer dune faon naturelle lchange
dinformation entre objets concurrents et par consquent intervient directement sur le changement
dynamique des variables intervenant sur le comportement des objets. Par exemple, les quatre classes
(objets) se synchronisent pour dcrotre le nombre darticles qui seront disponibles dans la bibliothque.
Rl [decreaseqtyavailableOfaBook] <R : reader | code : ?, ISBN = ?>(getBookin) <BookLend :
BookLending | InitialDate : date, ExpiredDate : date + 15, Observation : nil>( RentBook)<book
: Book | Author : Peter Moses, ISBN : #=1252514, Year : 2004, Quantity : N>(getLending)
<book : Book | Author : Peter Moses, ISBN : #=1252514, Year : 2004, Quantity : N - 1>
La rgle decreaseqtyavailableOfaBook ne fournie pas toutes les informations mises en valeurs lors
de linteraction entre lobjet reader, lobjet book et la relation book lending. Nous pouvons titre
128

dexemple tendre linteraction et faire intervenir la sous-classe TypeOfBook appartenant la classe

Book puis faire intervenir les objets labrarian et library pour mettre jour la base de donnes.
Il serait aussi possible dlargir la classe Book et la sous-classe Periodic afin de donner plus de
dtails leurs caractristiques. Par exemple rajouter le type de livres et le numro de linstance du livre.
Ce qui fait que par similitude nous dclarons la mme chose pour les articles (item) de Periodical, ceci
se fait comme suit :
class TypeofBook | code : string, description : string .
class BookCopy | number : string, position : string, status : bookStatus .
subclasses typeOfBook BookCopy < Book .
class TypePeriodic | number : string, description : string .
class PeriodicCopy | number : string, position : string, status : PeriodicStatus .
subclasses typePeriodic PeriodicCopy < Book .
class BookReservation | reservationDate : date, reader : Oid, item : Oid, observation : string .

class Booklending | lendingDate : Date, initialDate : Date, Observation : string,

reader : Oid, item : Oid .
class PeriodicalReservation |
observation : string .

reservationDate : date, reader : Oid, item : Oid,

class PeriodicalLending | lendingDate : Date, initialDate : Date, Observation : string,

reader : Oid, item : Oid .
class Calendar | date : Date .
rl [new-date] : <C : calendar | date : D> <C : Calendar | date : D + 1> .
class Library | intitution : string, address : string, loanPeriod : maxLoans: Pfun(Cid, Nat),
suspendedsers : set(Oid) .
class Pay_fines | reader : string, pay_date : Date, amount : money .
Dans le diagramme des classes de la Figure 8.16, la classe Librarian ne possde pas dattributs, mais
elle offre trois mthodes qui sont dclares comme des messages cres pour permettre la
communication et lchange dinformation et de notification.
class Librarian .
msgs borrow return : Oid Oid Oid Msg .
msg payCharges : Oid Money Oid Msg .
Chaque message sera renomm juste aprs lopration quil modlise, et le premier et le dernier
argument du message sera lidentificateur des objets appelant respectivement. Le reste des arguments
correspondent aux arguments dclars pour lopration. Par exemple :
msg payCharges : Oid Money Oid Msg .

dtermine les charges qui doivent tre payes par le lecteur pnalis.
8.7.1 Contraintes: passage de lOCL vers Maude
Une fois avoir spcifi la forme statique qui dtermine la structure de notre systme, nous passons
la deuxime exigence savoir interprter les contraintes sur les diffrents diagrammes. Dans ce cadre
dide nous pouvons nous imposer certaines spcifications qui contraignent le comportement du

129

systme. Pour bien exprimer le passage de la spcification semi-formelle donc dans le langage OCL
vers une rcriture dans le langage MAUDE, prenons en considrations les trois exigences suivantes :
1. Premier Invariant : Il ne doit y avoir quune seule bibliothque et quun seul calendrier dans le
systme
2. Deuxime Invariant : Le nombre dobjets emprunter doit tre gal la somme des valeurs des
attributs borrowedItems de tous les lecteurs dans le systme
3. Troisime Invariant : La liste suspendedUsers de la bibliothque doit contenir exactement les
identificateurs de tous les lecteurs suspendus.
Le premier invariant limite le nombre dobjets dune classe donne dans le systme. Le prdicat
suivant thereIsOneAndOnlyOne impose le fait quun seul (unique) objet dune classe donne dans une
configuration donne.
op thereIsOneAndOnlyOne : Cid Configuration Bool .
op numberOfOccurrences : Cid Configuration Nat .
var M : Message .
var Ats : Attributes
var O : Oid .
vars A A : Cid .
eq thereIsOneAndOnlyOne(A, C) = numberOfOccurences(A, C) == 1 .
eq numberOfOccurences(A, <O : A| > C) = if <O : A | > : A then 1 + numberOfOccurences(A, C)
else numberOfOccurences(A, C) fi .
eq numberOfOccurences(A, M C) = numberOfOccurences(A, C) .
eq numberOfOccurences(A, none) = 0 .

Pour le deuxime invariant, la spcification scrira :

op consistentNumberOfLoans : Configuration Bool .
op borrowedItemsSum : Configuration Nat .
var N : Nat .
eq

consistentNumberofLoans( C ) = numberOfOccurences(Loan, C) == borrowedItemSum( C ) .

eq borrowedItemSum(< 0 : Borrower | borreowedItems : N> C) = N + borrowedItemsSum( C ) .

ceq borrowedItemSum(< 0 : A | > C) = borrowedItemsSum( C ) if not < O : A|> : Borrower . .
eq borrowedItemSum(M C) = borreowedItems( C) .
eq

borrowedItemsSum(none) = 0 .

Le troisime invariant, est dcrit comme suit :

op consistentSuspendedUsers : Configuration Bool .
eq consistentSuspendetUsers(<O : Library | suspendedUsers : O OS >
<O : Borrower | status : BS > C) = (BS == suspended) and
consistentSuspendetUsers(<O : Library | suspendedUsers : OS > C) .
eq consistentSuspendetUsers(<O : Library | suspendedUsers : none >

130

<O : Borrower | status : BS > C) = (BS =/= suspended) and consistentSuspendedUsers(< O :

Library | > C) .
ceq consistentSuspendedUsers(< O : Lbrary | > <O : A | > C) = cocistentSuspendedUsers( C ) if
not <O : A | > : Borrower .
eq consistentSuspendetUsers(M C) = cocnsistentSuspendedUsers( C ) .
eq cocnstentSuspendedUsers(< O : Library | suspendedUsers : OS > = OS == none .

Figure 8.16 : Diagramme des classes dune bibliothque

Cependant, nous devons dans une certaine mesure pouvoir dclarer tous les invariants pour quils
soient reconnus par le systme, pour cela il est ncessaire de dclarer dans un premier temps lopration
{_} comme suit :
op {_} : Configuration WholeConfig .
qui est un constructeur de sorte WholeConfig. Dans ce cas, il serait en outre necessaire de differencier
entre le systme global et une de ces partie. Ce qui fait que cet invariant sera declar par lquation
speciale dite de membership.
var C : Configuration .
subsort ValidLibrary < WholeConfig .
cmb {C} : ValidLibrary if thereIsOneAndOnlyOne(Calendar, C)
and therieIsOneAndOnlyOne(Library, CD)
and consistentNumberOfLoans( C )
and consistentSuspendedUsers( C ) .

8.8

UML et le temps rel

8.8.1 Une reprsentation limite du temps

131

Lexpression des CT explicites reste limite en UML 1.3. [OMG99a]. Sur les diagrammes de
squence, le temps s'coule de haut en bas. L'axe vertical peut tre gradu afin d'exprimer des
contraintes temporelles. Deux primitives (Event.ReceiveTime et Event.SendTime) permettent de
diffrencier les instants o les messages entre objets sont envoys et reus. Pour le reste, des notes dans
un format non spcifi, peuvent tre utilises afin de dfinir des contraintes temporelles.
Dans les diagrammes dtats, en plus dEvent.ReceiveTime et dEvent.SendTime, les primitives When
et After peuvent tre utilises. When (date = janvier 1999) permet de spcifier un temps logique (ou
chantillonn) absolu. After (x units de temps) permet de reprsenter un temps relatif.
Il nest donc pas possible, sans crer une extension UML, de spcifier, par exemple : des
vnements ou des activits priodiques, de donner des informations probabilistes, de dfinir des
relations entre temps physiques et temps logiques, de diffrencier simplement les CT internes et
externes Dans ce qui suit nous allons montrer comment la modelisation des contraintes temporelles
est apprehende, nous parlerons aussi de laspect vrification en UML-RT (UML real time)[SR98,
BJO00, Ste03].

8.8.2 Illustration de UML pour la Modlisation des Systmes Temps Rel

Dans cette partie de notre expos, nous allons clarifier le problme de la spcification des systmes
temps rel et leurs proprits dans le langage UML. Considrons un systme temps rel trs simple. Il
sagit dun contrleur qui est susceptible de ragir des vnements extrieurs e = la valeur de la
concentration c est plus grande quune certaine valeur M donne ou le dlai T de deux vnement
successifs est considr comme lune des proprits du systme.
Compte tenu des lments prsents jusquici, nous construisons le systme qui est compos du
sous-systme CS (Control Subsystem) et le RS (Registration Subsystem). Il y a aussi un buffer B dans
le systme utilis pour lchange dinformation entre les deux sous-systmes. Quand un vnement se
produit les deux sous-systmes commencent fonctionner simultanment. Le sous-systme de contrle
CS peut travailler dans lun de deux modes de faon alternative. Si la concentration c se trouve dans le
rang (M c < Max), CS fonctionne alors en mode normale. Dans ce mode le sous-systme calcule la
position x de control lid, enregistre le rsultat dans le buffer et donne lordre (commande) de faire
bouger le lid. Si (c Max), alors CS se met dans le mode emergency mode. Dans ce mode le soussystme ouvre plusieurs lids au maximum, envoie une notification puis enregistre la position courante
de x du contrle lid dans le buffer. Le sous-systme RS peut se positionner off et on par le personnel.
Sil est positionn on alors et en raction lvnement e, RS enregistre la concentration actuelle et la
position courante du contrle lid du Buffer.

Figure 8.17 : Les diagrammes de classes (A), les diagrammes Statechart (B) et le diagramme des
squences ( C )

132

8.8.3 Une approche pour la spcification des systmes temps rel en

UML
Nous avons montr auparavant, quun systme temps rel peut tre modlis par une extension,
disons intelligente mais lourde de consquence. Cette approche qui dfinissait un systme temps rel
comme un ensemble dlments du langage UML (diagramme de classe, collaboration, statecharts
etc..), plus quelques artifices qui correspondent merveilleusement aux caractristiques propres des
STRs, savoir les capsules, les ports et les protocoles. Cette faon de reprsenter les STRs permet
justement de retracer la partie statique et le comportement, disons la partie dynamique. Naturellement,
il existe dautres approches [ABD98, WTB+00, TER00, KNR02, Bjo00] qui ont permis dapporter
plus dclaircis compte tenu de la sensibilit des STRs. Ces mthodes qui puisent leur fondement
thorique de travaux de recherches dj cits, tels que ceux de Dill, Alur, Henzinger, Manna et Pnueli
et bien dautres permettent non seulement de proposer des architectures temps rel, mais en plus
dfinissent une manire noble de traiter lexpression de proprits dans un langage ou dans un autre
pousant par la mme occasion un aspect temporel. Donc, du temporis exprim en gnral selon la
caractristique du problme par des valeurs prises dans un domaine la plupart du temps dense pour le
continu, cest--dire prenant des valeurs dans IR+, et IN+ pour le discret.
Dans le prsent travail, nous proposons un metamodel de UML. Le profile slectionne des lments
du metamodel UML utile pour la conception mais dans un domaine dapplication spcifique. Le profile
peut aussi inclure des rgles pour la validation et la transformation des diagrammes.
Le profile en question tourne autour des dfinitions suivantes :
Un domaine temporel Dense,
Quelques notions dUML pour la spcification des systmes temps rel : real time class, class
diagram, object diagram, statechart diagram,
Quelques notions dUML pour la spcification de proprits temps rel : spcification class,
extended class diagram, extended statechart diagram, rules of deriving the properties
spcification des diagrammes de classes.
Cette approche consiste-en :
Un diagramme de classes pour le temps rel, construit par mixage des classes temps rel et des
classes traditionnelles.
Un diagramme objet qui dfinie lensemble des objets et leurs associations.
Un diagramme statechart est construit partir des statcharts de classes.
Un diagramme de classe tendu construit en utilisant les classes de spcification avec des
contraintes prdfinies. La spcification de proprits est drive automatiquement partir des
diagrammes de classes tendues.
Un diagramme de statechart est driv automatiquement partir des classes et des statecharts
tendus. La spcification est smantiquement quivalente un graphe de transition temporis.
8.8.4 Spcification des systmes temps-rel
Rappelons quune classe dans le metamodel UML est le tuple CL = (At, Op, C), avec At lensemble
(fini) des attributs, Op est un ensemble fini des oprations et C est une contrainte.
Supposons pour le moment que C soit vrai. Nous dfinissons une classe temps rel comme une
classe forme des attributs traditionnels et des attributs caractristique temps rel de type DenseTime.
Pour modliser le comportement dune telle classe, nous utilisons les diagrammes statechart de
lUML. Une configuration de statechart est dfinie comme un arbre statique form dtats (tats
composites, tats histoire, sous-tats, tats synch, etc.) Une transition est prsente par la notation

133

e[g]/ a

suivante : t : s

s' , avec

s une configuration source, s est une configuration cible. Une fonction

trigger (dclenchement) affecte un vnement e dit de lancement une transition, une fonction de garde
associe un prdicat dfini sur lensemble des attributs de la classe correspondante, et une fonction
deffet qui affecte une action la transition. Une transition sera emprunte si sa condition de garde [g]
soit vraie et son vnement e prend place. Si plusieurs transitions sont choisies, alors uniquement seule
lune delles doit tre emprunte immdiatement et ce choix est dterministe.
Un diagramme de statechart est le tuple Sch = (S, E, G, A, TR) ou S est lensemble de
configurations, E est lensemble des vnements, G est lensemble des conditions sur les gardes. A est
un ensemble dactions, et TR = {(si, sj, e, g, a)|si, sj S ; e E, g G, a A} est lensemble de
transitions.
Lintroduction du temps est donne par ce qui suit :

Lensemble des vnements doit inclure des vnements sur les horloges, par exemple, t = T
(horloge t possde la valeur T), t1 t2.

Un prdicat de garde [g] peut tre dfini sur lensemble des horloges.

Parmi ces actions il existe des actions de rinitialisations des horloges.

Le temps passera dans la configuration aussi longtemps quune transition ne vrifie pas les
conditions de passage.

Le temps passera dans une transition aussi longtemps jusqu ce que laction termine son
excution.

Nous dfinissons maintenant, la spcification dun systme temps rel comme le tuple :
SP = (Class Diagram, Object Diagram, Statechart Diagram)
Dans ce tuple la Class diagram = (Classes, Associations) est lensemble (finie) de classes et
dassociations entres les classes. Une association de deux classes A et B dans un diagramme de classe
est le tuple R = (Atype, A, B, NA, NB), ou AType Atypes.
Lensemble des associations possibles de deux classes est reprsent par des artes entre les classes
avec une terminaison spcifique : Atypes = {aggregation, composition, gnralisation, association}.
NA, NB sont un nombre dobjets des classes A et B. Lensemble dassociation peut tre vide. Il existe
un ensemble de signaux Signals Cl parmi les classes. Ils sont marqus par le strotype <<Signal>>.
Un objet diagramme est utilis pour viter les ambiguts, et cest la paire OD = (Objects,
Associations0), ou Objects est lensemble dobjets des classes du diagramme des classes. Assocoations0
est lensemble de relations de ces objets. Associations0 Associations, seulement des relation un un
des objets est autorise.
Nous notons en fin de compte que larbre de calcul temporis (Timed Computational Tree) peut tre
spcifi en utilisant TCTL.

8.8.5 Spcification de lextension du langage UML

Pour spcifier les proprits dun systme temps rel, nous faisons une extension du langage UML
travers le diagramme dtats et du diagramme statecharts. Les deux spcifications systme et
proprits sont maintenant reprsentes par la paire : diagramme des classes et diagramme de
statecharts (Figure 8.26). Nous pressentons dans cette figure une extension du diagramme des classes et
du diagramme des statecharts de la Figure. Dans ce graphique quatre spcifications sont notifies
chacune correspond une proprit dfinie auparavant. Les proprits 3 et 4 sont modelises par les
instances du strotype Deadline-stereotype. La proprit 2 est reprsente par une instance de
strotype Rearlier-stereotype. La proprit 1 est modlise par la spcification class Property 1. La
classe possde un attribut disons k : Integer qui contient la srie des ractions conscutives du systme
de contrle CS aux vnements e en mode emergency. Quand le systme de contrle ragit en mode
134

emergency (SS(c) [c Max]), la specification-class Property 1 fait une transition de ltat P1 vers ltat
P2 et lattribut k est incrment. Quand le sous-systme de contrle ragit dans le mode normal (SS(c)
< Max]), la specification-class property 1 fait une transition de ltat P2 vers ltat P1 et lattribut k est
rinitialis zro. La contrainte de la spcification specification-class
C(SP)property 1 AG(k < 2)
signifie que pour tout chemin et pour tout tat de larbre de calcul (computational tree) du systme du
contrle de concentration (k < 2), i.e. il ne doit y avoir deux ractions conscutives lvnement e
quand le sous-systme CS fonctionne en mode emergency en deux temps.
Une contrainte dune classe de spcification dclare une proprit de larbre de calcul du systme. La
proprit du systme est la conjonction des contraintes de toutes les classes de spcification partir du
diagramme de classe tendu du systme.
Nous pouvons partir de ce systme tablir quelques proprits, qui sont :
Propriet 1 : Il ne peut y avoir deux ractions conscutives lvnement e, tel que le sous-systme
CS fonctionne dans le mode emergency pendant deux priodes conscutives.
Proprit 2 : Lenregistrement de la position x du lid partir du buffer par le sous-systme
denregistrement doit tre complt U units de temps avant lenregistrement dune nouvelle position
lid au buffer par le sous-systme de contrle.
Proprit 3 : Une raction loccurrence de lvnement e (du CS en mode normal) serait acheve
dans les limites du temps de sparation de lvnement.
Proprit 4 : Une raction lvnement e (du CS dans le mode emergency) serait acheve dans les
limites du temps de sparation de lvnement.
Dans la figure suivante il est not les lments suivants :
Il existe une interface externe I( c ) de concentration c comme paramtre.
La classe SP modlise une raction sporadique lvnement e. La classe possde une opration
ReactToIc() et deux attributs : T ! Real cest le temps de sparation ; M : Real est une valeur de la
concentration partir duquel le systme doit ragir. Quand linterface I( c ) prend place et la condition
du garde soit vraie, cest--dire [c > M] = true, la classe SP ralise une transition de ltat Idle vers ltat
Reacted. La transition Reacted vers idle sera aussi possible aprs le temps de sparation.
Loccurrence du signal SS( c ) pousse les deux sous-systmes (CS et RS) ragir. La
concentration c tant le paramtre du signal.
La classe CS correspond au sous-systme de contrle. Ces attributs Max : Real est une valeur
de la concentration. La valeur de cet attribut dfinie le mode de raction du sous-systme de contrle.
F est le signal, qui est envoy par le systme de contrle aprs avoir termin son travail.
Nt est un signal de notification du personnel.
La classe RS est un model du sous-systme RS. La classe possde les oprations on(), off(),
ReactToSS() et deux attributs :
C : ArrayOf(Real est un array de valeur de concentration ;
S : ArrayOfReal est un array de valeurs des positions lid.
La classe B modlise le buffer. La classe contient lattribut : S : Real pour sauvegarder une valeur
de la position lid et deux oprations : putS() pour crire lattribut S, getS() pour lire lattribut S.

135

Figure 8.18 : Les diagrammes de classes et de statecharts du systme du Contrle de concentration

Le statechart (Figure 8.26) modlise le comportement du systme. Par contre le diagramme de
squence permet de spcifier les proprits du systme. Cette spcification montre certains problmes :
premirement, nous ne sommes pas capables de spcifier que lvnement e arrive sporadiquement.
Cependant, ce problme peu tre rsolu par une simple extension syntaxique. Deuximement : nous ne
pouvons pas reprsenter toutes les squences de ractions lvnement e sur le diagramme des
squences et nous ne pouvons pas dfinir leurs proprits. Ce qui montre que nous ne pouvons pas
reprsenter la proprit 1 en UML.
En gnral, UML est incapable de reprsenter les proprits temporelles et essentiellement la
proprit datteignabilits (reachability property), ainsi que les proprits relatives aux squences de
ractions diffrentes instances dun vnement.
Nous proposons dans ce travail une extension du langage UML pour la spcification de proprits
temps relle.

8.8.6 Exemple de specification-stereotypes

1. Deadline-stereotype. Soit SPx la spcification dune classe X donne. ClassDiagramX dfinie
cette classe. Le statechartX fixe lensemble des tats de la classe X, les conditions de garde et les
actions.
2. Nous dfinissons aussi le deadline T dun tat de X qui peut tre atteint partir dun autre tat de
la classe. Cependant le Deadline-spereotype doit tre spcifi. La contrainte du deadline-Stereotype est
alors crite comme suit :
CD : AG((X@x) [g] and e (r := 0).(AFX@y) (r T)))),
ou r:DenseTme est un attribut. Nous dfinissons lensemble suivant des paramtres du Deadlinestereotype :
T la valeur du deadline,
X@x - la configuration du statechart partir duquel nous commenons calculer le temps qui
passe,
g la condition sur les gardes dune transition de X@x,
e le prdicat sur lvnement e dune transition partir de X@x

136

 X@y - la configuration de statthalter partir duquel nous terminons le temps de calcul.

La contrainte ci-dessus signifie que pour tout chemin, pour tout tat, si nous somme dans la
configuration X@x et le garde [g] dune transition prenant naissance en X@x est vrai, lvnement e
est activ et nous rinitialisons lhorloge r zro, alors dans tout chemin, qui commence partir de cet
tat, ltat X@y est atteignable avant le deadline (r T).
3. Counter-stereotype. Quand on spcifie des ractions instantanes un vnement e, nous
utilisons un strotype du type counter (compteur) pour compter les diffrentes occurrences dun
vnement. Le strotype Counter possde un attribut (i : integer). La contrainte du strotype est true.
Quand un vnement se produit, la valeur de la lattribut est incrment de 1.
4. Earlier-Stereotype. Soit la spcification de deux classes X et Y, quand les classes sont ltat
X@b Y@b, elles ragissent la mme occurrence de lvnement e. Supposons que les ractions des
classes soient des squences dtats apriodiques, un strotype Earlier modlise la proprit quun tat
X@x de la classe X se produit U units de temps avant que ltat Y@y de la classe Y soit atteint.
5. La contrainte de la specification-stereotype :
6. Cearlier : AG(X@b Y@b e ==> (Y@y) AU(X@x Y@y))
AG(X@b Y@b e ==> AF(Y@y))
AG(X@b Y@b e ==> AG(X@x (z := 0= . AG(z < U (Y@y)))
Qui signifie qu en raction lvnement e :
Pur tout tat (chemin) X@x sera atteint tel que ltat Y@y ne peut tre atteint ni avant X@x ni
simultanment avec X@x.
Pour tous les chemins, ltat Y@y sera atteint par moment,
Pour tous les chemins, toujours, si nous rinitialisons lhorloge dans ltat X@x, alors ltat Y@y
ne peut pas tre atteint avant z U.

8.9

Conclusion

Au cours de ce chapitre nous avons abord le problme du choix dune ou des mthodologies de
modlisation adaptes de faon particulire aux systmes ractifs et de prfrence temps-rel. Nous
avons admis que dans les temps actuels, UML constitue le meilleur choix. Naturellement nous avons
explicit dans les dtails ce choix et prsent quelques lments du langage de description UML ainsi
que son extension OCL pour ladapter nos besoins quest la spcification des systmes temps-rel. Au
fil de cet crit, nous avons montr travers un exemple trs intressant (Train-Gate-Controller)
quUML et OCL sadaptent trs bien la spcification du type de problmes traits dans notre thse. Le
problme qui se pose actuellement et dailleurs qui est sujet un investissement intense en matire de
recherche, cest justement comment adapt UML/OCL pour lappliquer en tant quoutil de description
du problme mme de la vrification. Dans ce cadre dide nous avons propos une approche singulire
et lavoir adapt au problme du TGC, ce qui a confort dans un certain sens lun des soucis majeurs
des concepteurs.
Dans un deuxime temps, nous avons su adapter les modles UML/OCL pour quils soient spcifis
dans la logique de rcriture et MAUDE travers des modules fonctionnels/objets et utilisant des rgles
dinfrence pour les adapter aux rgles de lOCL, un exemple trs intressant (modle de la
bibliothque) a t fournit pour montrer le bien-fond de nos ides.

137

CHAPITRE 9

Implantation

138

9.1 Introduction
Dans ce chapitre, nous prsentons les diffrentes parties composant le systme global. Nous
retardons un petit peu nos explications pour bien dfinir larchitecture, le modle logique, le
fonctionnement les interfaces et les diffrents modules composant le systme VALID et son extension
VALID 2. La partie vrification est matrialise par loutil ROBDD dfinie dans le chapitre 4, des
modules de vrification bass sur la logique linaire temporelle LTL et PTL. Nous notons quun
module bas sur la logique CTL a t dvelopp mais ne sera pas prsent. A la fin de ce chapitre nous
dtaillons deux exemples typiques de systmes (lun hardware et lautre software) qui ont t spcifi
puis vrifier et finalement un tableau rcapitulatif dun certain nombre de benchmarks avec leurs
solutions et comparaison.

9.2 Module de Spcification et de Simulation des Systmes

Ractifs
Les mthodes de description issues de nos travaux utilisent en partie la philosophie UML et le
systme VALID tel quil est prsent dans [AM94,AS94,AS96] par Attoui et al. Nous montrons dans ce
qui suit que VALID a t enrichi de diffrentes manires. Nous fournirons par la suite une table mettant
en valeur les caractristiques de VALID, de VALID2 et leurs diffrences, avant cela une introduction
rapide mettra en valeur ces deux systmes.

9.2.1 Le Systme VALID

Contrairement certains systmes de modlisation des systmes concurrents tels que LOTOS et
ESTELLE, VALID prsente un formalisme qui sapparente davantage au langage Maude. Dabord, il
ne fait appel qu une seule thorie pour la spcification formelle des structures de donnes et de la
dynamique des systmes. Le langage adopt par VALID peut tre considr comme un sous-ensemble
du langage MAUDE, aussi minime soit-il mais toute fois trs expressif. Il sagit dune gnralisation de
la programmation fonctionnelle oriente objet. La principale diffrence entre VALID et MAUDE est
que VALID retient un seul concept de base qui est le module formel. Un module formel peut dcrire
un module de faon similaire telle que OBJ1, OBJ2 et OBJ3. Le module formel une fois instanci est
utilis pour gnrer, filtrer et rduire les entits syntaxiques qui le concernent dans les phases du
systme formel correspondant.
Le systme VALID, durant le processus de spcification considre tout objet comme un systme
complexe compos si ncessaire dautres objets. Le processus de dcomposition est dfini alors comme
une suite hirarchique de composants. Dans ce cas, un module formel peut faire appel pour sa
spcification dautres modules formels, ce qui forcment met en place un mcanisme de prise en
charge de la notion de niveau et de visibilit qui est similaire la notion de mtargles telles que
dfinies dans les systmes experts. Cest--dire quun systme A est dun niveau immdiatement
suprieur un niveau B, si le systme B intervient directement dans la composition du systme A. De
cette faon le systme A ne connat alors que les attributs des systmes de son niveau qui sont rendus
visibles ou publiques.
9.2.1.1

La Signature du Langage VALID

La figure 9.1 donne la grammaire du formalisme textuel pour la spcification des systmes
concurrents temps rel de VALID.

139

.
Figure 9.1 : Signature des Systmes Concurrents supports par VALID
Cette signature prcise la construction syntaxique du systme formel. Neaumoins elle ressemble un
tout petit peu une partie de la grammaire de MAUDE. Nous pouvons trs facilement faire une
correspondance, titre dexemple du mot cl Type de VALID est le mot rserv sort de
MAUDE. Il nest pas ncessaire dintroduire les dfinitions de chaque partie de cette syntaxe, le lecteur
est invit consulter les travaux de Attoui et al. [AS96, Has97].
La description dun systme consiste instancier les mta-types des lments du vocabulaire
(Object, Attributs, Msg, ), en fonction de la ralit perue de faon dfinir les objets qui le compose
ainsi que les messages ou les vnements susceptibles dagir sur le comportement de lobjet ou de
linteraction de plusieurs objets.
9.2.1.2

Les rgles de rcriture dans VALID

Un objet en VALID peut tre sollicit pour un service. Cette sollicitation est reprsente par un
message qui peut contenir des paramtres. Leffet dun message sur un objet est dcrit travers une
rgle. Un tel message ne peut tre mis que par des objets du mme niveau ou du niveau suprieur. Un
message peut tre intercept par une rgle et redirig vers nimporte quel niveau. Les rgles dans ces
conditions permettent de raisonner par changement dtats des objets du systme et de tirer des
conclusions valides sur lvolution. Une rgle indique ainsi que le systme passe dune configuration
une autre exactement comme dans le langage MAUDE. Une rgle peut aussi tre active lorsque toutes
les conditions sont runies. La forme gnrale dune rgle dans VALID est donne par :
Messages1 .. n Objets1..m ObjetS1..k NewObjetsS1..p NewMessages1..q [Timing]
Pour comprendre le comportement dune telle rgle, il vaudrait mieux pour nous de se refferer au
langage Maude.
Pour mieux apprhender la syntaxe et la smantique de VALID un exemple simple est sollicit dans
ce cas. Nous rappelons lexemple trait dans la partie MAUDE, il sagit de la gestion de comptes
bancaires qui sera rcrit dans le langage VALID, cette spcification est reprsente par les deux
modules formels suivants (Figure 9.2) :

140

ModuleFormel COMPTE :
(Importe Date, Montant, Liste, Compte ;
Signature
{
Type Compte, Id.Compte, ObjectId, Msg, Valeur, Configuration ;
SousType Id.Compte < ObjectId < Valeur ;
SousType Msg.Compte < Msg ;
SousType Msg, Compte < Confgration ;
Op <_ : Compte / solde : _, criture : _> : Id.Cmpte Montant Liste[Coupe[Date, Montant]] Compte ;
Op (crditer_de_) : Compte Montant Msg.Compte ;
Op (dbiter_de_) : Compte Montant Msg.Compte ;
Op (solde de_pour _) : Compte Montant ObjetId Msg .Compte;
Op (solde de_est _pour) : Compte Montant ObjetId Msg .Compte;
Op _ _ : Configuration Configuration Cnfiguration [Assoc, Com, Id= Nul]
}
Rgles
{
Var C : Compte ;
M, S : Montant ;
H : Triplet ;
I : Oid ;
(crditer C de M) <C : Compte / solde : N, criture : N, criture : H> ==>
<C : Compte / : N + M, criture : (date_aujourdhui, +M) H> ;
(dbiter C de M) <C : Compte / solde : N, criture : H> ==>
<C : Compte / : (solde : N M) >= 0, critures : (date_aujourdhui, -M) H> ;
(solde de C pour I) <C : Compte / solde : N, criture : H> ==>
<C : Compte / solde :: N, criture : H> (le solde de C est N pour I) ;
}
}
ModuleFormel BANQUE
{
Importe Compte, Montant, Date, Nat, Liste, Triplet, Pourcentage ;
Signature
{
SousType Cpt_dpt < Compte ;
SousType Cpt_librett < Compte ;
SousType Codevi < Cpt_livret , Compte ;
SousType Cpt_courant < Cpt_livret ;

141

Op (Triplet) : Cpt_dpt Liste[Triplet[Date, Nat, Argent]] ;

Op (Taux_) : Cpt_livret Poucentage ;
Op (plafond_) : Codevi Montant ;
Op (datefermeture_) : Codevi Date ;
Op (chque enregistrer numro _ de valeur _ sur le compte _) : Nat Montant Compte Msg.Cpt.dpt ;
Op (intrt de ) : Compte Cptlivret ;
Op (fermet _ dans _) : Compte Compte Msg.Codevi ;
Op (transfrer _ de _ dans _) : Argent Compte Compte Msg ;
}
Rgles
{
Vars C, CV : Compte ;
N : Montant ;
N : Nat ;
(chque enregistrer numro N de valeur M sur le compte C) <C : Cpt_dpt/Triplet :H> = => C :Cprt_dpt /
Triplet : insrer(date_aujourdhui, N, M) dans H)> (dbiter C de M) ;
(intrt de C) <C :Cpt_livret / taux : R> = = > <C :Cpt_livret / taux : R> (crditer C de (solde de C)* R) ;
(fermer CV dans C) <CV : Codevi /plafond : P, date_fermeture :D> = = > (crditer C de (solde de CV)) si D <
date_aujourdhui sinon (crditer C de (/*formule permettant le calcul des intrts*/)) ;
(transferet M de C dans CV) = = > (dbiter C de M)(crditer CV de M) ;

Figure 9.2 : Spcification des comptes bancaires dans VALID

Nous pouvons remarquer que l alphabet de ce module formel est constitu dobjets complexes
imports (Date, Montant, Liste et Couple etc.). Il existe par contre un deuxime type de module dit
module fonctionnel dont la description est tout fait identique celle dun module orient objet. La
seule diffrence entre les deux types de modules au niveau conceptuel, rside dans leur comportement.
Un module fonctionnel un comportement purement fonctionnel. Il sert dfinir un type abstrait de
donnes qui reprsente une classe dentits qui ne change pas dans le temps (statique). Un module de ce
genre contiendra les lments qui permettent de construire, dinterroger et de manipuler ses lments.
Dans ce module le terme quation est utilis au lieu de rgle .
En outre VALID permet de dclarer des rgles synchrones et asynchrones juste pour diffrencier
entre le vrai paralllisme et celui dinterleaving.
Le systme VALID admet une reprsentation particulire des rgles dite internes, elle se prsente
sous cette forme :
Oi = = > Oi m On Mq Mr [T].
Ce type de rgles permet dexprimer les changements dtats dus non pas une excitation externe,
mais une logique interne qui nest pas visible ce niveau. Elles concernent donc un objet complexe
actif, qui peut voluer dans le temps suite une activit interne. Cela permet de spcifier, entre autres,
le comportement de certains objets qui obissent des lois internes quelconque, on introduit
lindterminisme dans le comportement.

142

9.2.2 Processus de Modlisation dans VALID

9.2.2.1

Architecture de VALID

Le systme VALID est un systme ouvert qui pouse diffrents concepts de modlisation et repose
sur un processus de modlisation cyclique dit de Gourgant (Figure 9.3). Le cycle dans ce cas est
incrmental et itratif, chaque tape tant susceptible dalimenter les autres. Il est arrt que lorsque le
fonctionnement du systme est jug conforme aux dsirs du concepteur.
Lenvironnement VALID est form de deux grandes parties aussi importantes lune que lautre
savoir :

Le modle de connaissance (ou de fonctionnement), contient les spcifications de topologie et

de fonctionnement attendu du systme. Ce modle tant la reprsentation de la partie statique du
systme, ensuite la partie dynamique sera spcifie formellement par des rgles de rcriture telles que
dfinies auparavant. La description de cette partie est assure par une interface graphique trs
conviviale et simple la fois.

Le modle daction : cest la traduction du modle de connaissance, dabord en un systme de

rcriture concurrente pour prouver que la spcification du systme satisfait les proprits de
confluence, de terminaison. Ensuite une srie de transformations formelles de spcifications et dont
ltape finale est lobtention du code en Prolog qui assurera par la mme occasion le comportement du
systme par lintermdiaire de lexcution des rgles de rcriture gnres par PROLOG lui-mme.

Figure 9.3 : Processus de modlisation

La figure suivante (Figure 9.4) dfinie au mieux larchitecture de VALID quelque peut amlore
dans le cadre de nos travaux. Comme extension apporte VALID, plusieurs dtails furtifs sont
consigns dans les articles [RBJ+03a, RBJ+03a, RJ04a, RJ04b].

143

Figure 9.4 : Architecture de VALID

9.2.2.2

Mthodologie de spcification des systmes concurrents avec VALID

La mthode VALID utilise deux phases de spcification distinctes relies entre elles.
Lditeur graphique tant la pice matresse et sert de support. Pendant une session de spcification
dun systme, il permet dinstancier et de spcialiser les modles pour chaque objet du systme global.
La spcialisation consiste essentiellement prciser le type rel des mta-types : Objet, Valeur,
ObjetId, Pour les mta-types qui ne peuvent pas tre spcialiss automatiquement, soit par manque
dinformation, soit en raison dambiguts de description, une interaction avec lutilisateur est ainsi
requise pour plus de clart.
Le systme VALID procde selon les phases suivantes :
9.2.2.2.1

Phase de mise en place de larchitecture et de linterface

La premire phase consiste mettre en place les objets du systme en procdant par niveau
dabstraction. Dans cette phase il est important de respecter la hirarchie naturelle des objets du systme
modlis. A un niveau donn, seuls les objets visibles sont mis en vidence.
Dans VALID, un systme complexe sera reprsent par les lments suivants :
Des variables dtat,
Des flots de donnes et de contrle en entre (vecteur dentre)
Des flots de donnes et de contrle en sortie (vecteur de sortie),
Des rgles et des lois de gnration des flots en sortie partir des flots en entre (rgle de
transformation)

144

 Une dynamique du systme, exprime facilement laide des rgles que nous avons introduites
prcdemment,
Des attributs visibles des sous-systmes composites ncessaires pour sa partie dynamique
Cette reprsentation est rcursive et sapplique aussi aux sous-systmes.
Un objet complexe est considr comme un systme qui est susceptible dtre dcompos en une
suite de sous-systmes. Cette dcomposition est guide en privilgiant les relations de composition qui
existent au sein mme du systme. A ce niveau de spcification des lments tels que les relations de
spcialisation / gnralisation, de rfrence etc., peuvent tre prises en charge par le systme VALID.
Ce qui revient dune faon globale dcouper les spcifications en modules de spcialisation qui
sembotent les uns aux autres.
Le systme VALID procde selon les tapes suivantes :

Cration du systme principal. Dans le cas de lditeur VALID le systme principal est
toujours de niveau 0 et ne peut contenir quun seul sous-systme

Cration de larchitecture.
1. Cration des systmes et sous-systmes.
2. Cration des attributs pour les systmes spcifis.

Cration de linterface.
1. Cration des messages.
2. Description des attributs visibles.
3. Phase de vrification de larchitecture et de linterface : Cette vrification est
importante, car avant dentamer la description des rgles il est impratif que larchitecture soit complte
et cohrente. Cette phase vitera plus tard de nombreuses tapes de modifications des rgles dues la
mise jour de larchitecture.
Description du comportement de chaque systme.
La visualisation du systme spcifier se prsente sous sa forme rduite selon la figure 9.5. Cette
faon de reprsenter tous les sous-systmes sur une mme fentre se fait justement dans cette forme
(rduite) qui laisse apparatre que linterface (messages en entre et en sortie du systme et les attributs
visible). A ce stade de spcification, nous omettons la description du contenu.
Remarque : Pour le moment nous mettons de ct tous les lments techniques de cration, de
modification, de suppression dun systme ou dun de ces sous-systmes. Nous ferrons de mme pour
lcriture de toutes les appellations (descriptions). Par contre un systme dvelopp cest la
reprsentation graphique de tous les sous-systmes (sous leur forme rduite) et attributs qui le
composent.

Figure 9.5 : Exemple de systme dvelopp.

145

Lobjet Attribut
Lattribut reprsente un objet qui ne peut tre dcompos hirarchiquement. Il devient un composant
part entire du systme et est dcrit par les caractristiques suivantes :
Un nom qui lidentifie de manire unique dans le systme considr.
Une description qui reprsente sa documentation.
Le Type de lattribut qui reprsente lensemble des valeurs que peut prendre cet attribut.
Une case de slection de visibilit. Si elle est coche la porte nest pas seulement locale mais
aussi exploitable par le systme pre de celui qui contient cet attribut.
Pour mieux comprendre la notion dattribut, il peut tre assimil une variable locale un systme
mais qui peut tre modifiable par un systme pre (ou hirarchiquement suprieur) en cas de slection
de visibilit.
Les messages
Les messages qui sont pris en charge par VALID sont similaires ceux de MAUDE (figure 9.6). La
bote de dialogue relative la description d'un message s'affiche et il ne reste plus qu' renseigner les
diffrents champs. Aprs validation des informations, le message apparat dans la liste concerne par
cette cration.

Figure 9.6 : Boite de dialogue de description dun message.

La rduction dans VALID est un moteur dordre 0+. Il utilise la stratgie du parcours en profondeur
dabord (DFS). Il gre galement un chancier pour la ralisation des contraintes temporelles. Pour
crer un scnario de validation, il faut respecter les tapes suivantes :
Slectionner un systme dvelopp de niveau n, puis slectionner l'option Tester un objet du
menu Rduction. A ce moment une fentre apparat et affiche le systme instanci du systme
slectionn prcdemment.
Choisir dans le menu Fichier l'option nouveau Scnario.
Dcrire les diffrents tats ncessaires au scnario.

146

Figure 9.7 : Schma exhaustif des diffrentes phases de spcification sous VALID de latelier de
fabrication

9.3 Simulation et Animation dans VALID 2

Le systme de simulation et danimation tel quil a t conu est crit dans le langage Java version
1.2.. Le programme utilise des fonctions prdfinies des classes SIMJAVA une bibliothque de
modles. SimJava est une collection de trois packages, eduni.SimJava, eduni.SimAnim et

eduni.SimDiag.

Eduni.SimJava : est un package utilis pour construire le modle de la simulation en

java, et produit un fichier de traces comme rsultat par dfaut. Simjava contient un nombre
dentits qui fonctionnent en totale indpendance, cest-a-dire en parallle. Le comportement
dune entit utilise la mthode Body() ou corps. Les entits utilisent des primitives de
simulation et qui sont :
1. Sim_schedule() : envoie un vnement dautres entits travers des ports.
2. Sim_holde() : suspend la simulation pour un certain temps.
3. Sim_wait() : attente pour larrive dun vnement dobjet.
4. Sim_select() : slectionne des vnements de la queue reporte.
5. Sim_trace() : crit un message temporaire dans un fichier de trace.
Eduni.SimAnim : fournit un squelette dApplet pour construire une animation du
modle de simulation. Deux mthodes de SimAnim crent lanimation :
1. Anim_init() : pour ajouter des boutons de contrles.
2. Anim_layout() : est tendu pour placer les icnes dentit.

Eduni.SimDiag : est une collection de classes JavaBeans utilise pour laffichage des
rsultats de la simulation (diagramme, histogramme, etc.). SimDiag fournit deux types de
JavaBeans, qui sont (TraceEventListeners), et (GraphEventListeners).
Le graphique de la Figure 9.11 nous donne une ide sur le rsultat fournit par le simulateur. Nous
pouvons voir sur ce graphique, un rseau de processus (Alternating Bit Protocol), gauche lemeteur,
droite le receveur et au milieu (en haut) le bus data-channel et en bas le bus acknowledge (Figure 9.9) .

147

9.3.1 Architcture de lditeur de simulation

Figure 9.8 : Architecture du simulateur et de lanimateur dobjets concurrents

9.3.1.1

Description des diffrents composants du systme

9.3.1.1.1 Construction de schma

Notre systme est bas sur une interface graphique qui met la disposition de lutilisateur un
ensemble dicnes ayant chacune une smantique propre. Ces icnes sont gnralement disponibles
travers des menus, et peuvent tre slectionnes par le biais de la souris ou du clavier. Le schma est
reprsent graphiquement par la connexion des objets graphiques (icnes) entre elles pour former une
reprsentation du systme modliser. Chaque objet (icne) possde gnralement des paramtres qui
sont spcifis travers des boites de dialogues, de ce fait le module en question hrite les particularits
de VALID et des descriptions UML (Figure 9.9).
9.3.1.1.2 Le gnrateur de code

Il est ralis grce aux connaissances des composants de schma. Le gnrateur de code accepte des
connaissances simples de schma et produit un code source excutable (crit en langage Java) (Figure
9.10)
9.3.1.1.3 LExcution du programme gnr

Lexcution du programme obtenu par ltape de gnration de code, nous donne une animation du
modle simul (Figure 9.11).

148

Figure 9.9 : Reprsentation (modlisation) du Protocole ABP

Figure 9.10 : Une partie du code-Java gnre du protocole ABP

Figure 9.11 : Le rsultat de la simulation et de lanimation du Protocole ABP

149

9.4 Transformation de Spcifications VALID en MAUDE

9.4.1 Vrification de
spcification

la

terminaison

et

de

la

confluence

dune

Les rgles de rcriture gnres par le systme VALID lors de leur excution ne fournissent quun
code permettant de mettre en valeur le comportement de linteraction des rgles de rcriture entre
elles (concurrence). Le comportement tout a fait linaire, est forme dune succession de rgles
consignes dans un fichier trace (*.trc). Ce fichier quelquefois est dune longueur incommensurable et
cest pour cela que loutil ORME [Les94a, Les94b], un outil de premire gnration qui est dailleurs
un laboratoire de rcriture, ft utilis pour vrifier dans un premier temps et avant toute excution la
terminaison et la confluence des rgles ainsi gnres.
Loutil ORME tel quil a t conu offre plusieurs possibilits pour manipuler des ensembles
dquations et des systmes de rcriture. Les interactions avec lutilisateur permettent de choisir une
commande spcifique permettant dagir plus finement sur la spcification ainsi prte pour tre
manipule. Dans ce cas, lune des oprations les plus importance tant de donner la possibilit
lutilisateur de choisir lui-mme lordre des quations, de les orienter sa guise et dopter pour lune
des mthodes de simplification du systme, savoir :

La mthode des interprtations,

Lordre rcursif des chemins.

Aprs la manipulation de la spcification, ORME fournit les rsultats

situations suivantes :

de lune des deux

Lensemble des rgles ne possde pas la proprit de terminaison, donc ne possde pas la
proprit de confluence. ORME indique ainsi la rgle qui est lorigine de cette non-terminaison.
Lordre tabli au sein des symboles doprateurs, gnralement source de conflits doit tre revu.
Lensemble des rgles se termine. Dans ce cas ORME indique lensemble des paires
critiques. Si cet ensemble est vide, la vrification est termine, sinon ces paires critiques sont limines
et ainsi on rajoutera dautres rgles.
Pour illustrer ltape de traduction de la spcification (ensemble des rgles) pour quelle soit prise
en charge par loutil ORME pour la vrification, lexemple suivant dfinit au mieux cette opration :
Considrons un sous-ensemble de rgles de rcriture tir de la spcification du gestionnaire de
compte bancaire savoir :
R01 : (contenu de A de C pour O)<C : Client/A=V, > <C : Client/A=V,>(contenu de A est V pour O)
R02 : (mettre A de C V) )<C : Client/A=S, > <C : Client/A=V,>
R1 : (Dbiter C de S)<[M] : Client/tat : actif> (connexion serveur de C pour [M] :Client/tat :actif>(attendre
Dbiter C de S)

Ces rgles sont traduites dans ORME dans le systme dquations suivantes :
1. Config1(Contenpour(a,c,o),Structobj(c,a,v),Fictif1)=Config2(Structobj(c,a,v),Contenuest(a,v,o),Fictif)
2. Config1(Mettre(a,c,v), Structobj(c,a,s),Fictif1) = Config2(Structobj(c,a,v), Fictif, fictif2)
3. Config1(Debiter(c,s),Structobj(client,etat),Fictif1)= Config2(Connectionserveur(c,client), Structobj(client,etat),
AttendreDebiter(c,s))

Lordre lexicographique des termes ainsi choisis est selon ce qui suit :
Config1 > Config2 > Debiter > Cintenypour >Mettre >Fictif1 > Fictif2 > Structobj > Contenuest >
Connectionserveur > AttendreDebiter.

150

9.4.2 Gnration de code MAUDE partir de Spcifications VALID

Dans le chapitre 6, nous avons montre que la logique de rcriture vhicule par le langage MAUDE
tant une logique universelle prouve, cest dire que du fait quelle utilise un mcanisme
mathmatique trs puissant qui est la reflction, permet dans un certain sens toute logique
mathmatique ou bien toute description (modles, langages, machines abstraite, machine dtats,
logique temporelle, etc.) de prendre forme dans cette mme logique (logique de rcriture), donc dtre
dcrit dans le langage MAUDE.
Le fait, dornavant de raisonner en toute libert en MAUDE, nous donne certes des avantages
normes que nous avons pris le soin de citer auparavant (spcifications entirement formelles,
rcriture, systme trs puissant et trs rapide, plus lensemble des outils qui vont avec). Cette
possibilit, nous a pouss crire un mini-interprteur crit entirement en MAUDE qui permet aux
spcifications VALID dtre interprtes et excuter dans le systme MAUDE dun cot mais aussi
dutiliser les outils de vrification de la confluence, de la terminaison qui sont beaucoup plus
performants que loutil ORME, plus dautres caractristiques propres aux systmes de rcriture mais
aussi aux systmes ractifs en gnral. En gros, cette faon de procder nous permet dintgrer tous les
formalismes ainsi dvelopps dans une mme plate-forme unificatrice.
Le code suivant introduit juste une partie du mini-interpreteur de transformation de spcifications
VALID en thories MAUDE.
======
*** dclaration des oprateurs ***
op Op_ : _ : Token Sort OpDecl .
op Op_ : _[_] . : Token Sort AttrList OpDecl .
op Op _ : _ _ . : Token SortList Sort OpDecl .
op Op_ : _[_] . : Token SortList Sort AttrList OpDecl .
op Op _ : _ _ . : NeTokenList Sort OpDecl .
op Op_ : _[_] . : NeToken Sort AttrList OpDecl .
op Op _ : _ _ . : NeTokenList SortList Sort OpDecl .
op Op_ : _[_] . : NeToken SortList Sort AttrList OpDecl .

=======
*** dclaration de variables ***
op vars_ :_ . : NeTokenList Sort VarDecl .
op var_ :_ . : NeTokenList Sort VarDecl .

=======
*** dclaration des rgles ***
op RL_ : -=>_. : Token Buble Buble RuleDecl .
op rl_ : -=>_. : Token Buble Buble RuleDecl .
op CRL_ : _=>_if_. : Token Buble Buble Buble RuleDecl .
op crl_ : -=>_if_. : Token Buble Buble RuleDecl .

=====
*** dclaration du module fonctionnel
op ModuleFormel_ _ FinMF : ModuleName FdeclList PreModule .

151

Pour continuer dans le mme sillage savoir lutilisation du systme MAUDE comme plate-forme
de spcification, nous proposons dans ce qui suit dans un premier temps un Model-checker bas sur la
logique temporelle PTL pour vrifier les systmes ractifs qui prsentent des comportements linaires
et un deuxime bas sur la logique arborescente CTL tels quils ont t introduit dans le chapitre 7.
Nous donnerons par la suite juste un fragment du code du Model-checker suivant :

9.5 Proposition dun Model Checker bas sur la Logique

Temporelle PTL
Nous rappelons toutes les dfinitions, la syntaxe et la smantique de la logique propositionnelle
(chapitre 3) et de la logique temporelle linaire (chapitre 5) juste titre pour ne pas alourdir ce
manuscrit.
Nous savons dj quun Model-checker support deux niveaux de spcification :
niveau de spcification du systme : utilis pour la formalisation du systme concurrent,
niveau de spcification des proprits qui doivent tre vrifies annonant le comportement du
systme.
Dans le langage MAUDE une thorie de rcriture bien construite peut tre spcifie par un modulesystme. Aussi en supposant dans un modle (module-systme M) un tat initial, disons init de sort
StateM, nous pouvons ainsi vrifier toutes les formules temporelles linaires de LTL (PTL, PLTL).
Un module qui reprsente la logique propositionnelle scrit alors :
fmod PPPRRROOOPPPOOOSSSIIITTTIIIOOONNNNNNEEELLLLLLEEE iiisss
Protecting TRACE .
sort Boolean.
subsort Bool < Boolean.
op _<_ : Boolean Boolean -> Boolean.
op _and_,_*_: Boolean Boolean -> Boolean [assoc comm prec 55].
op _or_,_+_ : Boolean Boolean -> Boolean [assoc comm prec 59].
op _->_ : Boolean Boolean -> Boolean.
op not_ _!_: Boolean -> Boolean [prec 53].
op _<->
_ : Boolean Boolean -> Boolean.
op _nor_ : Boolean Boolean -> Boolean [assoc comm prec 54]
op _xor_ : Boolean Boolean -> Boolean [assoc comm prec 54]
vars X Y Z: Boolean.
eq false < true = true.
eq true < false = false.
eq X and X = X.
eq true and X = X.
eq X or X = X.
eq X or false = X.
eq X -> Y = (not X) or Y.
eq false nor X = X.

152

eq X nor X = false.
eq X and (Y nor Z) = X and Y nor X and Z.
eq X or Y = X and Y nor X nor Y.
endfm

Comme les formules temporelles sont dfinies sur des graphes de Kripke il est ncessaire dans ce cas
dintroduire des constructions sur les chemins du graphe ce qui veut dire autrement, sur des traces.
Linterprtation dune telle situation est assure par le module suivant :
fmod TRACE is
sorts Event Event* Trace .
subsorts Atom < Event < Event* < Trace .
sort Formula .
subsort Atom < Formula .
ops true false : -> Formula .
op [_] : Formula -> Boolean [strat (1 0)] .
op _|=_ : Trace Boolean -> Boolean .
op _{_} : Formula Event* -> Formula [prec 10] .
op nil : -> Event .
op __ : Atom Event -> Event [prec 23] .
op _* : Event -> Event* .
op _,_ : Event Trace -> Trace [prec 25] .
var X Y Z : Boolean .
var T : Trace . vars A A : Atom .
var E* : Event* .
var E : Event .
eq T |= X /\ Y = T |= X and T |= Y .
eq (X /\ Y){E*} = X{E*} /\ Y{E*} .
eq [X /\ Y] = [X] and [Y] .
eq [X ++ Y] = [X] xor [Y] .
eq [true] = true .
eq [false] = false .
eq true{E*} = true .
eq false{E*} = false .
eq A{nil} = false .
eq A{A} = if A == A then true else false fi .
eq A{A E} = if A == A then true else A{E} fi .
eq A{E *} = A{E} .
op _|=_ : Trace Formula -> Bool [prec 30] .
eq T |= true = true .
eq T |= false = false .
eq E |= A = [A{E}] .
eq E,T |= A = E |= A .
endfm

Les formules temporelles sont aisment vrifiables par le module suivant :

fmod LTL is extending PROPOSITIONNELLE .
*** syntaxe
op []_ : Formula -> Formula [prec 11] .
op <>_ : Formula -> Formula [prec 11].
op _U_ : Formula Formula -> Formula [prec 14] .
op o_ : Formula -> Formula [prec 11] .
*** semantique
vars X Y : Formula .

153

var E : Event .
var T : Trace .
eq <> false = false .
eq <> true = true .
eq o (X * Y) = o X * o Y .
eq o (X + Y) = o X + o Y .
eq X U (Y + Z) = (X U Y) + (X U Z) .
eq false U X = X .
eq X U false = false .
eq true U X = <> X .
eq E |= [] X = E |= X .
eq E,T |= [] X = E,T |= X and T |= [] X .
eq E |= <> X = E |= X .
eq E,T |= <> X = E,T |= X or T |= <> X .
eq E |= X U Y = E |= Y .
eq E,T |= X U Y =
E,T |= Y or E,T |= X and T |= X U Y .
eq E |= o X = E |= X .
eq E,T |= o X = T |= X .
vars X Y : Formula .
var E : Event . var T : Trace .
eq ([] X){E} = [] X /\ X{E} .
eq ([] X){E *} = X{E *} .
eq (<> X){E} = <> X \/ X{E} .
eq (<> X){E *} = X{E *} .
eq (o X){E} = X .
eq (o X){E *} = X{E *} .
eq (X U Y){E *} = Y{E *} .
op _|-_ : Trace Formula -> Bool [strat (2 0)] .
eq E |- X = [X{E *}] .
endfm

9.6 Exprimentation
Nous avons conduit plusieurs vrifications sur des systmes dont nous avons pris le soin de
formaliser et de spcifier ainsi que certaines de leurs proprits. La table 9.12 rcapitule juste titre une
partie de notre exprimentation.
Nous donnons tout de suite le texte descriptif de la spcification de certains de ses systmes. Comme
nous lavons dit auparavant, les systmes ractifs peuvent se prsents dans une forme Hard : un
circuit ou quivalent et une forme soft : un logiciel, un programme ou quivalent.
9.6.1

Exemple de spcification dun systme Hardware: Muller-C circuit

Figure 9.12 Le Circuit Muller C- avec retard

154

Le circuit Muller-C est ralis partir de trois circuits majeurs selon le graphique de la figure 9.12.
Comme nous pouvons le constater, la structure et le comportement dun tel circuit peut tre formalis
par la formule de la logique temporelle suivante :
[ ](e ((in1 in2) (in1 in3) (in2 in3)))
avec un dcalage dun dlai dune unit selon :
[ ]( @out ((in1 in2) (in1 in3) (in2 in3)))
Lorsque lon relie la sortie (out) avec lune des trois entres, disons In3 par exemple, nous obtenons
lexpression du circuit Muller-C comme suit :
[ ](@out ((in1 in2) (in1 out) (in2 out)))
En suivant une telle description du circuit Muller-C, nous pouvons alors dvelopper un outil trs
large form par des spcifications pour dcrire les comportements du circuit concern, mais aussi
dautres circuits quivalents. Par exemple nous pouvons mettre en place les spcifications suivantes et
dmontrer par la mme occasion leurs validits. Nous proposons trois spcifications qui se rsument
comme suit :
Spcification1. Deux signaux en entre (par exemple In1 et In2) sont au niveau high conduit
(implique) que la sortie soit un niveau low jusqu ce quelle devienne (ventuellement) high
(peut tre bien immdiatement) et restera ce niveau low, jusqu ce que In1 et In2 redeviennent en
mme temps au niveau low de nouveau, ou bien si cette dernire conditions ne surviendra jamais
(restera pour toujours de mise). La spcification est crite comme suit :
[ ]( (in1 in2 out U(out (out U ( in1 in2) [ ] out)))
De la mme manire nous decrivons la deuxime et la troisime spcification selon ce qui suit :
Specification 2.
[ ]( (in1 in2 out U( out (out U (in1 in2) [ ] out)))
Specification 3.

out U (in1 in2) out U(in1 in2) [ ] (@out out )

Notre outil permet de faon simple la verification du comportement circuit Muller-C qui se rsume
la spcification globale suivante :
Muller-C specification1 specification2 specification3
La solution dun tel comportement est execut en 63 oprations de rcriture en moins d une millliseconde.
9.6.2

Exemple de specification dun Software : Peterson Algorithms

Pour mieux apprcier ltendue de cet algorithme, jose le prsenter dans sa version originale qui
permet de garder son sens et sa port. La traduction est aussi aise que la version anglaise.
Le Problme :
A paradigmatic problem in concurrent programming is the mutual-exclusion problem, which asks for
a programming solution to ensure that no two processes simultaneously access a common resource,
such as an I/O devise or a write-shared variable.

155

In a practical way there is a finite numbers of algorithms modelling the problem of the mutualexclusion control. Among such paradigm, Petersons algorithm is the simpler solution to the problem of
mutual exclusion.
Peterson's Mutual Exclusion Algorithm for 2 processes each of which can adopt 4 states (non-critical
section, request section, wait section and critical section). Such states are defined for each process using
Boolean equations as follows :
We admit that the parameters c1, c2, d1 and d2 are used to control the accessibility of the critical
section, and the unary operator ~ is the negation form.
**** Process P1
NCS1 = ~c1 /\ ~c2;
# non-critical section
TRY1
= c1 /\ ~c2;
# request section
WAIT1 = ~c1 /\ c2;# wait section
CS1
= c1 /\ c2;
# critical section
*** Process P2
NCS2
= ~d1 /\ ~d2;
TRY2
= d1 /\ ~d2;
WAIT2 = ~d1 /\ d2;
CS2
= d1 /\ d2;
The processes are modeled using interleaving, which is represented by a program counter' bit (pc). If pc (true)
then the first process is running, if ~pc (false) the second is so. There are other 'global' variables (bits), in1 (in2):
process 1 (2) requests the critical resource. If in1 /\ in2 /\ t (t is the 'tie-breaker') then process 1 enters the critical
section, if in1 /\ in2 /\ ~t then process 2 enters.
/* The complete system: */
peterson = start /\ []first /\ []second /\ fairness
/* The specification to prove mutual exclusion
mut_exc = [] ~(CS1 /\ CS2);
/* To verify that the implementation (Peterson algorithm) meets its requirement (verify the specification), we write :

peterson -> mut_exc

Start, first, second, fairness are defined as follows :
***** The behavior of the first process
first =
pc -> (d1 <-> @ d1) /\ (d2 <-> @ d2) /\ (in2 <-> @ in2) /\ ( NCS1 /\ @ TRY1 /\ @ in1 /\ (t <-> @
t) \/ TRY1 /\ @ WAIT1 /\ @ ~t /\ (in1 <-> @ in1) \/ WAIT1 /\ @ WAIT1 /\ in2 /\ ~t /\ (t <-> @ t) /\ (in1 <-> @
in1) \/ WAIT1 /\ @ CS1 /\ (~in2 \/ t) /\(in1 <-> @ in1) /\ (t <-> @ t) \/ CS1 /\ @ NCS1 /\ @ ~in1 /\ (t <-> @ t)
);
***** The behavior of the second process
second = ~pc -> (c1 <-> @ c1) /\ (c2 <-> @ c2) /\ (in1 <-> @ in1) /\ ( NCS2 /\ @ TRY2 /\ @ in2 /\ (t
<-> @ t) \/ TRY2 /\ @ WAIT2 /\ @ t /\ (in2 <-> @ in2) \/ WAIT2 /\ @ WAIT2 /\ in1 /\ t /\ (t <-> @ t)/\ (in2 <->
@ in2) \/ WAIT2 /\ @ CS2 /\ (~in1 \/ ~t) /\ (in2 <-> @ in2) /\ (t <-> @ t) \/ CS2 /\ @ NCS2 /\ @ ~in2 /\ (t <->
@ t) );
**** The initial start
start = t /\ ~in1 /\ ~in2 /\ NCS1 /\ NCS2;
/* Infinitely often pc high and infinitely often pc low: */
fairness = []<> pc /\ []<> ~pc;

The solution of such formula is performed in 103 rewrites and at less than 160 ms.
La table suivante rsume au mieux un certain nombre de circuits et logiciels. Dans
colonne nous prsentons le nom du systme en question, dans la deuxime sa dure
utilisant un outil de vrification PTL-tool [PTL-Tool], dans la troisime colonne, le
rcritures qui ont permis la vrification et finalement dans la quatrime colonne le temps
des spcifications.

156

la premire
dexcution
nombre de
dexcution

Dnomination

Temps dexcution

du model

( PTL-tool)

Nombre de

Temps dexcution

rcritures

(ms)(VALID2)

Muller_C

0.1 s

70

40

Lars1

3.0 s

124

adder

0.1 s

195

Mul4

158.7s

216

10

Dff1

0.0

53

20

Josko3

105.6 s

21

10

Josko4

18.0 s

20

10

Mutex1

1.3 s

91

30

Mutex2

19.1 s

93

20

Peterson

103

160

Scc-event

23

10

Josko5

20

10

Muller-C2

20

10

Mutex

65

10

CallHear

34

10

Hailpern

70

20

Table 9.12 : Rsultats dexprimentations vrifies par Notre Model-Checker

9.7 Conclusion
Cette partie de notre thse concerne les rsultats obtenus suite un effort considrable pour la mise
en pratique des ides dveloppes pour la spcification et la vrification des systmes ractifs. En effet
nous avons crit les programmes suivant :

Une implmentation des diagrammes de dcision binaire qui constitue en lui-mme (le BDD)
un choix incontournable pour la vrification des systmes software/hardware dcrits comme
des rseaux boolens.

Une implmentation dun module mixte bas sur les algorithmes gntiques et la
programmation linaire bivalente. Ce module na pas t dcrit dans cette thse mais la t
dans certaines de nos publications.

Lextension du systme VALID en VALID 2, plus certains outils de modlisation, de

spcification, de simulation et de vrification.

Lcriture dun ensemble de modules excuts dans le systme MAUDE sur une plate-forme
Linux.

Nous signalons aussi, que plusieurs exprimentations ont t ralises travers la spcification, la
programmation et la vrification de plusieurs problmes (circuits et algorithmes) mettant en uvre les
applications dveloppes dans le cadre de nos recherches et des rsultats trs encourageants ont t
obtenus.

157

Conclusion et Perspectives
Un systme embarqu complexe comme ceux que lon trouve dans les satellites, les avions, les
fuses, les robots, etc., se compose de plusieurs cartes ddies. Chaque carte assure une fonction
particulire (tlcommunication, traitement de signal, surveillance des quipements, pilotage et
conduite du systme, etc.). Chaque carte est compose dune partie matrielle (matriel RISC, un circuit
ASIC, un DSP (processeur de traitement de signal), un microprocesseur classique et dune partie
logicielle (applicatif). Si tous les outils qui relvent du domaine du gnie logiciel des systmes temps
rel permettent actuellement de bien mener terme les projets de dveloppement des logiciels de ce
type de systmes, la phase dintgration du matriel et du logiciel reste encore assez laborieuse et trs
coteuse, et reprsente, dans certain cas jusqu 50% du cycle de dveloppement du systme embarqu.
Les travaux de recherches abords dans cette thse, permettent justement de prendre en charge
plusieurs tapes du cycle de dveloppement de ce type de problmatique. Avant dentamer une
rcapitulation des rsultats de nos travaux, dont le sujet mme nous a influenc pour lancer
successivement plusieurs tapes de recherche. Dans la premire tape, il tait question de prospecter
ltat de lart du sujet et dapporter une contribution notable en choisissant une projection dans une
optique purement formelle. La deuxime tape sest approche de trs prt du cadre mme de notre
objectif premier qui est de runir tous les moyens thoriques et pratiques pour concrtiser le fait de
reprsenter les systmes critiques temps rel dans un formalisme universel plutt une science en ellemme, quest la logique de rcriture et ainsi de les pourvoir dun outil dexcution suffisamment
puissant pour permettre aux spcifications dtre excutes de faon simple et naturelle. Pour raisonner
en terme de rcriture formelle, nous avons eu lembarras du choix entre Cafe-Obj, Elan, PVS et
MAUDE. Une tude trs pousse nous a permis de choisir le bon et cela selon plusieurs critres, quil
nest pas ncessaire de relater. Notre choix sest port finalement sur le langage et systme MAUDE.
Dans ltape suivante, nous avons eu connatre, la complexit mme des systmes temps rel
embarqus puisquelle impose dadopter une mthodologie rigoureuse pour les apprhender et pour
garantir une cohrence certaine entre les diffrentes phases de dveloppement. Ces systmes (critiques
temps rel embarqus) constitus dentits matrielles et logicielles (co-design) ncessitent lutilisation
doutils permettant de prendre en charge indiffremment les parties logicielles et les parties matrielles
toutes considrations technologiques et ceci dans les premires phases du cycle de dveloppement.
La phase dintgration logiciel/matriel qui est une phase cruciale, peut tre facilite par le recours
des outils de co-vrification matriel/logiciels. Pour laspect logiciel nous avons eu recours au
dveloppement de systmes de spcification et de vrification bass sur des mthodes semi-formelles
dans un premier temps (UML et UML-Real Time) pour une reprsentation fiable des structures internes
et externes par des ADTs (abstract data type), mais aussi de leur comportement qui, la plus part des cas
est modlis selon une reprsentation formelle sous forme de machines dtats ou simplement
dautomates gnraliss. De faon globale il sagit aussi de tisser tous les liens entre les diffrents
objets (modules) dun systme. Nous avons eu recours dans ce cas des formalismes algbriques tel le
langage CCS et sa forme tendue Timed-CCS. A partir de l, il tait facile dapprhender la notion de
bisimulation (timed et untimed) pour la comparaison et la simplification des systmes de transitions
tiquets (une reprsentation abstraite des systmes concurrents). Dans ce cadre dide un algorithme
du Paige & Tarjan et un autre du Fernandez et Mounier ont t revus (ces algorithmes nont pas t
repris dans cette thse). Ces deux algorithmes permettent justement la simplification des systmes de
transition en partitions plus fines, do la notion de forte-connexit qui simpose (Paige & Tarjan
Algorithm) et une vrification la vole (Fernandez et al.) moyennant la notion dtats accessibles et de
deadlock qui sont des critres de sret inalinables.
La partie vrification sest impose delle-mme par le recours de lune des mthodes les plus
efficaces de nos jours, cest la mthode de vrification symbolique implmente dans les meilleurs
outils de vrification (SVM, SVC et autres) et qui est base sur les diagrammes binaires de dcision.
Nous notons quun module BDD a t crit dans le langage Java de JDK 1.2. Ce module BDD, tel
qunonc dans le texte de cette thse a t utilis par la suite comme module SAT, pour la rsolution

158

des systmes dquations de la programmation linaire en nombre bivalents et ainsi de satisfaire des
contraintes donc les spcifications.
La partie la plus intressante de notre thse et qui nous a valu un nombre important de publications
tant la logique de rcriture et le langage MAUDE. Dans le mme sens dide, plusieurs modules ont
t crits en MAUDE, les uns donnant des codes dune rapidit certaine pour la simulation symbolique
et la vrification de diffrents systmes concurrents ractifs. Les autres essayant tant bien que mal de
reprsenter les systmes temps rels, leur spcification et leur vrification, des cas rels ont mme
taient revus et tester.
Comme le passage dune description formelle vers sa reprsentation en MAUDE est dune lourdeur
ennuyeuse compte tenu de la longueur mme du code crire qui avoisine trs facilement les centaines,
voir, les milliers de lignes, lcriture dune interface graphique, de spcification, de gnration de code,
de deboggage et de simulation sest faite sentir un peu plus tard. Dans un premier temps nous avons
enjoint nos efforts celle de lquipe de Attoui, Professeur au laboratoire de recherche CESALP-LLP
Universit de Haute-Savoie pour adopter lenvironnement VALID juste comme une interface graphique
qui gnre du code et que ce code est transfrable via un traducteur dans le langage MAUDE pour quil
puisse tre excut. Nous avons ensuite crit notre propre interface qui reste encore un stade primitif
Dans le sillage de ce travail, plusieurs techniques de vrification ont t rappeles, les unes rcrite
dans le langage MAUDE selon lalgorithme original qui les rgit, telles que CTL de Emerson et PTL de
Manna. Elles ont t ensuite traduite dans une forme axiomatisable, puisque MAUDE et la logique de
rcriture sadaptent bien cette forme dexpression en plus de leur symbiose utiliser leur schma de
dduction bas sur les rgles ACI (associativit + commutativit + idempotence).
Finalement, nous notons quun ensemble dides ont t proposes qui montre laisance mme du
langage de rcriture MAUDE dadopter UML et OCL et par la mme occasion les modle de
vrification.
PERSPECTIVES
Deux champs de vision soffrent nous :
Une implmentation du noyau de rcriture sur machines fortement parallles : en effet deux
aspects importants qui caractrisent la logique de rcriture sont :
1. La dclaration mme des rgles de rcriture sous forme dquations mettant en place la
notion de rflexivit, transitivit, symtrie, congruence permet dexprimer le paralllisme
sous ces deux facettes (free & dinterleaving). Le premier nonce une architecture
massivement parallle et le deuxime, la dcomposition dexcutions parallles en une srie
dexcutions qui se relayent par squencement.
2. La puissance de la reflction de la logique de rcriture nous donne la possibilit de rcrire
un code MAUDE minimal, de limplmenter sur des puces et de lui associer les programmes
que nous avons crits (spcification, vrification, etc.) et den crer autant de machine
MAUDE miniaturises qui puissent constituer une partie dun systme Hardware/Software
mont sur une carte lectronique.
Etendre linterface graphique pour quelle soit conviviale le plus possible et quil puisse y crer
une certaine complicit entre le systme informatique et lutilisateur ou carrment les utilisateurs dans
un environnement coopratif. En plus de cela, il sagit dtoffer les programmes de spcification et de
vrification par de nouvelles techniques, puisquil ne se passe un jour pour quune nouvelle mthode ne
soit trouve et implmente. Cet aspect est trs encourag, puisque le systme que nous avons
dvelopp ainsi que MAUDE sont des applications systmes fortement ouvertes.

159

BIBLIOGRAPHIE
[ABD98]

Andr C., Boufaed H., et Dissoubray S., Les SyncCharts: un modle graphique
synchrone pour systmes ractifs complexes, RTS, Paris, pp. 175-196, 1998.

[ACD90]

Rajeev A., Courcoubetis C., et Dill L. D.. Model-checking for real-time systems, 5th
Symp. on Logic in Computer Science (LICS 90), pp. 414-425, 1990.

[ACH+95] Alur R., Courcoubetis C., Halbwachs N., Henzinger T. A., Ho P.-H., Nicollin X.,
Olivero A., Sifakis J., et Yovine S., The algorithmic analysis of hybrid systems.
Theoretical Computer Science, 138:334, 1995.
[AD90]

Alur R. and Dill D. L., Automata for modeling real-time systems. In Automata,
Languages et Programming, 17th International Colloquium, vol. 443, LNCS, pp. 322335, Springer-Verlag, July 1990.

[AD94]

Alur R. et Dill D.L., A theory of timed automata, Theoretical Computer Science,

126(2):183-235, 1994.

[AH92]

R. Alur R. et Henzinger. T.A. Logics and models of real time: a survey, In J.W. de
Bakker,K. Huizing, W.-P. de Roever, and G. Rozenberg (eds.), Real Time: Theory in
Practice,vol. 600, LNCS, pp. 74106. Springer, 1992.

[AHU74]

Aho A. V., Hopcroft J. E., et Ullman J. D., Design and Analysis of Computer
Algorithms, Addison-Wesley, Reading, MA, 1974.

[Ake78]

Akers S.B., Functional Testing with Binary Decision Diagrams, in Eighth Annual
Conference on Fault-Tolerant Computing, pp. 75-82, 1978.

[AKZ96]

Awad M., Kusela J., et Ziegler, J., Object-Oriented Technology for Real-Time
Systems, Prentice Hall, NJ, 1996.

[Alu98]

Alur R., Timed automata, in NATO-ASI Summer School on Verification of Digital

and Hybrid Systems, 1998.

[AM00]

Arajo, J., et Moreira, A., Specifying the Behaviour of UML Collaborations Using
Object-Z, Proc. of the Americas Conference on Information Systems, California,
2000.

[AN92]

Arnold. A. et Niwinski. D., Fixed point characterisation of weak monadiclogic

definable sets of trees, in Nivat, M. & Podelski, A. (eds.): Tree Automata and
Languages, Elsevier, pp. 159-188, 1992.

[Ari96]

Ariane 5 flight 501 failure: Report by the inquiry board, July 19, 1996.
http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html.

[Arn88]

Arnold. A., Logical definability of fixed points, in TCS, vol. 61, pp. 289-297, 1988.

[AT00]

Aleman. J.L.F. et Toval. A, Formally Modeling and Executing the UML Class
Diagram, in Rodriguez, M.J., Paderewski, P. (eds.): Proc. of the V Workshop
MENHIR, Universidad de Granada, Spain, March 2000.

[ATH00]

Aleman. J.L.F., Toval. A., et Hoyos. J.R, Rigorously Transforming UML Class
Diagrams, in Rodriguez, M.J., Paderewski, P. (eds.): Proc. of the V Workshop
MENHIR, Universidad de Granada, Spain,2000.

[AM94]

Attoui. A. et Maouche A., A tool for Parallel Applications Designs, in Proceedings

2nd Euromicro Workshop on Parallel and Distributed Processing, Malaga, Spain, 1994.

[AS94]

Attoui. A. et Schneider, M., A Formal Approach for Prototyping Distributed

Information Systems, in Proc. IEEE International Workshop on Rapid Prototyping,
Grenoble, France, June 21-23, 1994.

160

[AS96]

Attoui. A. et Schneider. M., A Formal Approach to the Specification and the Behavior
Validation of Real-Time Systems Based on Rewriting Logic, J. of Real Time
Systems, Kluwer Academic Publishers, vol. 10, pp. 5-22, 1996.

[Bal97]

Balarin. F. et al., Hardware-Software Co-Design of Embedded Systems, Kluwer

Academic Publishers, 1997.

[BB91]

Benveniste. A. et Berry G., The synchronous approach to reactive and real-time

systems, Proc. of the IEEE, 79(9):1270-1282, 1991.

[BBE01]

Boniol. F., Bel G., et Ermont J., Modlisation et vrification de systmes intgrs
asynchrones: tude de cas et approche comparative, 9 ime confrence internationale
sur les systmes temps-rel, RTS01, Mars 2001.

[BBL+97]

Beer. I., Ben-David S., et Landver A., RuleBase: an Industry-oriented Formal

Verification Tool, Proc. Design Automation, Conference (DAC'96), pp. 665-660,
1996.

[BCG99]

Benveniste A., Caillaud B., et Le Guernic P., From synchrony to asynchrony, 10th
International Conference on Concurrency Theory, LNCS, vol. 1664, pp.162-177, 1999.

[BCM+92] Burch J.R., Clarke E.M., McMillan K.L., et Dill D.L.. Symbolic model checking: 1020
states and beyond. Information and Computation, 98:142-170, 1992.
[Be96]

Betriebliches Lastenheft ffur FunkFahrBetrieb, Stand 1.10., German Railways, 1996.

[BHR84]

Brookes D.D., Hoare CAR, et Roscoe A.W., A theory of Communicationg Sequential

Processes, J. of the ACM, 31 (3), pp. 560-599, 1984.

[Bir35]

Birkhoff G., On the Sructure of Abstract Algebras, in Proc. Of the Cambridge

Philosophical Society, 31, 433-454.

[BJM00]

Bouhoula A., Jouannaud J-P., et Meseguer J., Specification and proof in membership
equational logic, Theoretical Computer Science, 236:35-132, 2000.

[BJO00]

Bjorkander M., Real-Time Systems in UML and SDL, Embedded System

Engineering, October/November 2000, (http://www.telelogic.com).

[BK85]

Bergstra J. A. et Klop. J. W., Algebra of communicating processes with abstraction,

Theoretical Comput. Sci., 37(1):77{121, 1985.

[BKK+96] Borovansky P.,. Kirchner C, Kirchner H., Moreau P-E, et Vittek M., ELAN: A logical
framework based on computational systems, in Jos Meseguer (eds), Proc. WRLA96,
vol. 4 of ENTCS, pp. 35-50. Elsevier, 1996.
[BM88]

Boyer R.S. et Moore J.S., A Computational Logic Handbook, Academic

Press,Boston, 1988.

[Bra95]

Brayton R.K., VIS: A System for Verification and Synthesis, Technical Report
UCB/ERL M95, University of Berkley, December 1995.

[BRB90]

Brace K.L., Rudell R.L. et Bryant R.E, Efficient Implementation of a BDD Package,
27th ACM/IEEE Design Automation Conference, pp. 40-45, 1990.

[Bry86]

Bryant R. E., Graph-based algorithms for Boolean function manipulation, IEEETransactions on Computers, C-35(8):677-691, Aug, 1986.

[Bry91]

Bryant R. E., On the complexity of VLSI implmentations and graph representations of

boolean functions with application to integer multiplication, IEEE Transactions on
Computers 40, 2, 205-213, 1991.

[Bry92]

Bryant R.E, Symbolic Boolean Manipulation with Ordered Binary Decision

Diagrams, ACM Computing Surveys, vol.24(3), pp.293 318, Sep. 1992.

[Buc77]

Buchi, J. R., Using determinacy of games to eliminate quantifiers, in Fundamentals of

Computation Theory, LNCS, vol. 56, pp. 367-378, 1977.

161

[Cad99]

Cadence, USA., Formal Verification Using FormalCheck, Version 2.3, 1999.

[CC77]

Cousot P. et Cousot R., Abstract interpretation: A unified lattice model for static
analysis of programs by construction or approximation of fixpoints, in the 4th ACM
Symp. Princ. of Prog. Lang., pp. 238-252, ACM Press, 1977.

[CCL+99]

Chauhan P., Clarke E., Lu Y., et Wang D., Verifying IP-Core based System-On-Chip
Designs, in Proc. of the IEEE ASIC Conference, September 1999.

[CDE+04] M. Clavel, F. Duran, S. Eker, P. Lincoln, N. Mart-Oliet, J. Meseguer, et C. Talcott.,

Maude manual (version 2.1). http://maude.cs.uiuc.edu/manual/, 2004.
[CDE+99] Clavel M., Duran F., Eker S., Lincoln P., Mart-Oliet N., Meseguer J., et Quesada J..
Maude: Specification and programming in rewriting logic, Computer Science
Laboratory, SRI International, January 1999.
[CDE+00] Clavel M., Duran F., Eker S., et Meseguer J., Building equational proving tools by
reflection in rewriting logic, in Cafe: An Industrial-Strength Algebraic Formal
Method, Elsevier, 2000. http://maude.csl.sri.com.
[CDS+00a]

Clavel M., Duran F., Eker S., Lincoln P.,. Mart-Oliet N, Meseguer J., et. Quesada J.F. ,
Maude tutorial, March 2000. March 25, 2000. http://maude.csl.sri.com/tutorial.

[CDS+00b]

Clavel M., Duran F, Eker S, Lincoln P., Mart-Oliet N, Meseguer J., et Jose F.
Quesada., Towards Maude 2.0, in 3rd WRLA00, vol. 36 of ENTCS, Elsevier, 2000.

[CDS+99]

Clavel M., Duran F., Eker S., Lincoln P., Mart-Oliet N., Meseguer J., et. Quesada J. F.
Maude: Specification and programming in rewriting logic, January 1999.
http://maude.csl.sri.com/manual.

[CE81]

Clarke E. et Emerson E.A., Design and synthesis of synchronization skeletons using

branching-time temporal logic, in Workshop on Logic of Programs, LNCS 131, 1981.

[CES86]

Clarke E.,. Emerson E., et Sistla A., Automatic Verification of Finite-State Concurrent
Systems Using Temporal Logic, in Proc. of ACM Transactions on Programming
Languages and Systems, 8(2):244-263, April 1986.

[CH78]

Cousot P. and Halbwachs N., Automatic discovery of linear restraints among the
variables of a program, in 5th ACM Symp, Princ. of Prog. Lang., pp. 84-97, Jan. 1978.

[Che80]

Chellas B. F., Modal Logic: an Introduction, Cambridge University Press,1980.

[CHP+91]

Caspi P., Halbwachs N., Pilaud P., et Raymond P.., Programmation et vrification des
systmes ractifs : le langage LUSTRE, TSI, vol.10(2), pp.139-158, 1991.

[CLA00]

Clarck R.G., et Moreira, A.M.D., Use of E-LOTOS in Adding Formality to UML,

Journal of Universal Computer Science, vol.6 (11), pp. 1071-1087, 2000.

[Cla01]

Clavel M., The ITP tool, in A. Nepomuceno, J. F. Quesada, et F. J. Salguero, (eds),

Logic, Language, and Information : Proc. of the First Workshop on Logic and
Language, pp. 5562. Kronos, 2001.

[CM96]

Clavel M. et Meseguer J., Reflection and strategies in rewriting logic, in J.

Meseguer, (ed) : Proc. Of the First Intl. Workshop on Rewriting Logic and its
Applications, 4 of ENTCS, Elsevier, 1996.

[CYB98]

Chen T. A., Yang B., et Bryant R. E., Breadth-First with Depth-First BDD
Construction: A hybrid Approach., Carnegie Mellon University, CMU-98-120.

[Dam96]

Dams D. R., Abstract Interpretation and Partition Refinement for Model Checking,
PhD thesis, Eindhoven University ofTechnology, July 1996.

[DBR96]

R. Drechsler, B. Becker, and S. Ruppertz, K*BMDs: A New Data Structure for

Verification, in Proc. European Design & Test Conference, pp. 28, 1996.

[DCE+98] Duran F, Clavel M, Eker S, et Meseguer J., Building equational proving tools by

162

reflection in rewriting logic, in Proc. of the CafeOBJ Symposium '98, 1998.

[DDL99]

Dellacherie S., Devulder S., et Lambert J.-L., Software Verification Based on Linear
Programming, in: J.M. Wing, J. Woodcock, J. Davies (Eds.): FM'99 Proc., Vol. II,
Springer LNCS 1709, 1999.

[Der87]

Dershowitz N., Termination of rewriting, J. of Symbolic Computation, vol. 3, pp.69116,1987.

[Dic91]

Dick A. J., An introduction to Knuth-Bendix completion, The Computer Journal,

34(1):2-15, 1991.

[DJ90]

Dershowitz N. et Jouannaud J.-P., Rewrite systems, in J. van Leeuwen, (ed), Handbook of Theoretical Computer Science, vol. B, chap. 6, Elsevier, Amsterdam, 1990.

[DP60]

Davis M. et Putnam H., A Computing Procedure for Quantification Theory, J. of the

ACM for Computing Machinery, vol. 7, pp. 201-215, July 1960.

[DPP03]

Dovier, Piazza, et Policriti., Fast Bisimulation Algorithm, CAV 2001, Theoretical

Computer Science, 2003.

[Dur99]

Durch R.., A Reflective Module Algebra with Applications to the Maude Language,
PhD thesis, University of Malaga, 1999.

[DV01]

Duran F. et Vallecillo A., Writing ODB Entreprise Specifcations in Maude,

http://www.lcc.uma.es/v/Publicaciones/01/ITI-2001-8-pdf

[EC80]

Emerson E. A. et Clarke E. M., Characterising correctness properties of parallel

programs using fixpoints, in 7th ICALP, Proc., LNCS vol. 85, pp. 169-181, 1980.

[EC82]

Emerson E.A. et Clarke E., Using Branching-time Temporal Logic to Synthesize

Synchronization Skeletons, Science of Computer Programming, 2:241-266, 1982.

[EH00]

Etessami K et Hotzmann G.J., Optimizing Buchi Automata, in CONCUR 2000,

LNCS 1877, pp. 153167, 2000.

[Eme83]

Emerson E. A., Alternative semantics for temporal logics, in J. TCS, vol. 26, pp.
121-130, 1983.

[Eme96]

Emerson E. A., Automated temporal reasoning about reactive systems, in Logics for
Concurrency, Structure versus Automata, LNCS 1043, Springer, pp. 41-101, 1996.

[EMS02]

Eker S., Meseguer J., et Sridharanarayanan A., The Maude LTL model checker, in
Proc. Of the WRLA02, ENTCS71, Elsevier, 2002.

[EN97]

EN 50128 CENELEC, Railway Application Software for Railway Control and

Protection Systems, 1997.

[Ern98]

Ernst R., Codesign of Embedded Systems: Status and Trends, J. of IEEE Design &
Test of Computers, pp. 45-54, April-June 1998.

[FD98]

Futatsugi K. et Diaconescu R.., CafeOBJ Report, World Scientific, AMAST Series,

1998.

[FGK+96] Fernandez C., Garavel H., Kerbrat A., Mateescu R., Mounier L., et Sighire M., CADP
Caesar Aldebaran Development Package Protocol Validation and Verification
Toolbox, in proc. CAV96, LNCS Springer Verlag, 1996.
[FH98]

Foxand C. J. et Harman N. A., Algebraic models of correctness for microprocessors,

Technical Report CSR 8-98, University of Wales Swansea, 1998.

[FM90]

J.C. Fernandez et L. Mounier., Verifying bisimulations on the fly, in J. Quemada, J.

Manas et E. Vasquez, (eds), Proc. FORTE '90, North Holland, Amsterdam, 1990.

[FT99]

Fernandez J. L. and Toval A., A formal syntax and static semantics of UML
statecharts, Technical Report, Department of Informatics: Languages and systems,
University of Murcia, Spain, 1999.

163

[FV98]

Fisler K. et Vardi M.Y., Bisimulation Minimization in an Automata-Theoretic

Verification Framework, in Formal Methods in CAD, pp. 115-132, 1998.

[FV99]

Fisler K. et Vardi M.Y., Bisimulation and Model Checking, in CHARME 1999.

[Ger97]

Gerth R., Concise Promela Reference, 1997.

http://cm.bell-labs.com/cm/cs/what/spin/Man/Quick.html.

[Gla94]

van Glabbeek R.J., What is Branching time Semantics and why to use it?, Report
Paper, Stanford University 1993. ftp://Boole.stanford.edu/pub/DVI/branching.dvi.gz,

[GM88]

Goguen J. A et Meseguer J., Order-sorted algebra I, Technical Report, SRI

International, Stanford University, 1988.

[GM93]

Gordon M J C. et Melham T F., Introduction to HOL, Cambridge University Press,

1993.

[Gna92]

Gnaedig I., Termination of order-sorted rewriting, in Proc. 3rd Conference on

Algebraic and Logic Programming, Pisa1, LNCS 632, pages 37-52, 1992.

[GO01]

Gastin P et Oddoux D., Fast LTL to Buchi Automata Translation, in Thirteenth

Conference on Computer Aided Verification (CAV01), LNCS 2102, pp. 53-65, 2001.

[GO03]

Graf S. et Ober I., A real-time profile for UML and how to adapt it to SDL, in Proc.
of SDL Forum, LNCS, 2003.

[GOO03]

Graf S., Ober I. et Ober I., Timed annotations with UML, SVERTS03, 2003.

[GPS96]

Godefroid P., Peled D. et Staskauskas M., Using partial-order methods in the formal
validation of industrial concurrent programs, J. of IEEE Transactions on software
engineering, 22(7), July 1996.

[GPV+95] Gerth R., Peled D., Vardi M. et Wolper P., Simple on-the-fly Automatic Verification
of Linear Temporal Logic, in Protocol Specification Testing and Verification, pp. 318, 1995.
[GUE00]

LE GUENNEC A., Mthodes formelles avec UML : Modlisation, validation et

gnration de tests, Actes du 8 Colloque Francophone sur lIngnierie des Protocoles
CFIP2000, Toulouse, Editions Herms, Paris, pp. 151-166, 17-20 octobre 2000.

[GW88]

Goguen J. A et Winkler T., Introducing OBJ3, Technical report, SRI, Computer

Science Lab, 1988.

[GW93]

Godefroid P. and Wolper P., Partial-order methods for temporal verification,

CONCUR '93, LNCS 715, pp. :233-246, August 1993.

[Hal93]

Halbwachs N., Synchronous programming of reactive systems, Kluwer Academic

Pub., 1993.

[Har00]

Harman N. A. Verifying a simple pipelined microprocessor using maude, Technical

Report; Computer Science Report, University of Wales Swansea, 2000.

[Har87]

Harel D., "Statecharts: a Visual Formalism for Complex Systems," Science Computer
Program, Vol8, pp 231-274, 1987.

[Har88]

Harel D., "On Visual Formalism", Communications of the ACM, Vol 31, No 5, May
1988.

[Has97]

Hasbani A., "Contribution la Conception dun Environnement de Spcification

Formelle et de Validation des Systmes Ractifs, Thse de Doctorat, Universit Blaise
Pascal, Clermont II, France.

[HC72]

Hughes, G. E. et Cresswell, M. J., An Introduction to Modal Logic, 2nd ed.,

Routledge, 1972

[HCR+91a Halbwachs N., Caspi P., Raymond P. et Pilaud D., The synchronous data flow
]
programming language Lustre", Proc. of the IEEE, 79(9), septembre 1991.

164

[HCR+91b Halbwachs N., Caspi P., Raymond P. et Pilaud D., Programmation et verification des
systmes ractifs l'aide du langage et de donnes synchrone Lustre", TSI, 10(2),
]
1991.
[Hei87]

Heite M., "Hood une mthode de Conception Hirarchise Orient-objet pour le

Dveloppement de Gros Logiciels Techniques Rel", Bigre N 57, Journes ADA
France, Dec 1987.

[HHW97]

T. A. Henzinger, P.-H. Ho, et H. Wong-Toi., HyTech: A model checker for hybrid

systems. Software Tools for Technology Transfer, vol. 1, pp. 110122, 1997.
http://www-cad.eecs.berkeley.edu/Utah/HyTech/.

[Hil93]

HILL D. R. C., "Analyse Orient Objet et Modlisation par Simulation", Ed.AddisonWisley, France, Juillet 1993.

[HKP97]

Huet G., Kahn G., et Paulin-Mohring C., The Coq Proof Assistant, A Tutorial
Version 6.1, INRIA, France, 1997.

[HM85]

Hennessy, M. et Milner, R., Algebraic laws for nondeterminism and concurrency, in

Journal of the ACM, vol. 32, 1985, pp. 137-162

[HNS+94] Hezinger T.A., Nicollin X., Sifakis J. et Yovine S., Symbolic model checking for realtime systems. Information and Computation, 111(2) :193-244, 1994.
[Hoa69]

Hoare, C. A. R., An axiomatic basis for computer programming, in Communications

of the ACM, vol. 12, 1969, pp. 576-580.

[Hoa78]

Hoare C.A.R.., Communicationg sequential processes, in Communication of the

ACM, 21:666-677, 1978.

[Hoa85]

Hoare C. A. R., Communicating Sequential Processes, Prentice-Hall International,

1985.

[Hol97]

Holzmann G.J., The Model Checker SPIN, IEEE Transactions on Software

Engineering, 23:279-295, May 1997.

[Hop71]

J. E.Hopcroft., An n log n algorithm for minimizing states in a finite automaton, in

Theory of Machines and Computations, Academic Press.1971.

[HPY97]

Holzman G, Peled D., et Yannakakis M., On nested Depth First Search, Design: An
International Journal vol.13, pp. 289-307, 1998.

[HR00]

Havelund K. et Rosu G., Testing linear temporal logic formulae on finite execution
traces, 2000. http://citeseer.nj.nec.com/havelund00testing.html

[HT96]

Harman N A et Tucker J V., Algebraic models of microprocessors: Architecture and

organisation, Acta Informatica, vol.33, pp. 421-456, 1996.

[Hue80]

Huet G., Confluent Reductions : Abstract Properties and Applications to Ter

Rewriting Systems, J. of the ACM, vol..27, n.4, pp.797-821, 1980.

[Hue81]

Huet G., A Complete Proof of Correcteness of the Knuth-Bendix Completion

Algorithm, J. of CSS, vol. 23, pp.11-21, 1981.

[Hul80]

Hullot J. M., Canonical Forms and Unification, in Proc. Fifth Conf. On Automated
deduction, Les Arcs, France, pp.318-334, 1980.

[HyTech]

http://www-cad/eecs.berkeley.edu/~tah/HyTech.

[ISY91]

Ishiura N., Sawada H., and Yajima S., Minimization of Binary Decision Diagrams
Based on Exchanges of Variables, in Proc. Of the (ICCAD-91, pp. 472475, 1991.

[ITU01]

ITU-T, "Specification and Description Language (SDL)", ITU-T Recommendation

Z.100 Corrigendum 1, October 2001.

[ITU94]

Z.100 ITU, Specification and description language (SDL), June 1994.

165

[ITU99]

ITU-T "SDL combined with UML", ITUtT Recommendation Z.109, November

1999.

[ITU-T99] "Message Sequence Charts (MSC-2000)", ITU-T Recommendation Z.120, November

1999.
[JAR98]

Jard C., Jazquel J.-M., et PennanacH F., Vers lutilisation doutils de validation de
protocoles dans UML", TSI, vol. 17, n9, pp. 1083-1098, Herms, Paris, 1998.

[Java]

Java 2 Platform Enterprise Edition. http://java.sun.com/j2ee

[JS00]

Jansen L., et Schneider J., Traffic Control System case Study; Problem description
and a note on Domain-based Software Specification, Technical report,2000.

[Kah74]

Kahn G., The semantic of a simple language for parallel programming, in IFIP 74,
North Holland, 1974.

[Kat99]

Katoen, J.-P., Concepts, Algoritms, and Tools for Model Checking, 1999.

[KB70]

Knuth D. E. et Bendix P. B., Simple word problems in universal algebras, in J.

Leech, (ed), Computational Problems in Abstract Algebra, pp. 263-297. Pergamon
Press, Oxford, 1970.

[KC99]

Kim S.-K. et Carrington D., Formalizing the UML class diagram using Object-Z, in
R. France and B. Rumpe, (eds), Proc., UML, Fort Collins, USA, LNCS 1723, pp. 8398, Springer, 1999.

[Kle52]

Kleene, S. C., Introduction to Metamathematics, North-Holland Edition, 1952.

[Klo92]

Klop J. W., Term rewriting systems, in S. Abramsky, D. Gabbay, and T. Maibaum,

(eds), Handbook of Logic in Computer Science, vol. 2, pp. 1-116. Oxford University
Press, 1992.

[KM96]

Kaufmann M.et Moore J.S., ACL2 an Industrial Strenght of Nqthm, in Conf.

COMPASS96, pp. 23-34, IEEE, Computer Society Press, 1996.

[KNR02]

Knapp A., Merz S. et Rauh C., "Model checking Timed UML State Machines and
Collaborations", 2002.

[Koz83]

Kozen, D., Results on the propositional mu-calculus, in TCS, vol. 27, pp. 333-354,
1983.

[KP84]

Kozen, D. et Parikh, R., A decision procedure for the propositional mu-calculus, in

Logics of Programs, Workshop, CMU University, 1983, LNCS. 164, Springer-Verlag,
1984, pp. 313-325.

[KP99]

King P. et Pooley R., Using UML to derive stochastic Petri net models, in N.
Davies and J. Bradley, editors, UKPEW '99, University of Bristol, July 1999.UK
Performance Engineering Workshop.

[KRONOS] http://www-verimag.imag.fr/TEMPORISE/kronos.

[KS80]

Kannellakis P. et Smolka S., CCS Expressions, Informationand Computation, 86:43

68, 1990.

[KW00]

Kosiuczenko P. et Wirsing M., Towards an Integration of Message Sequence Charts

and Timed Maude, J. of Integrated Design & Process Science, Vol. 5(1), 2001.

[KW96]

Kosiuczenko P. et Wirsing M., Timed Rewriting Logic, in Proc. of the Third

AMAST, Salt Lake City, Utah, pp. 242-257, March 6-8, 1996.

[KW97a]

Kosiuczenko P. et Wirsing M., Timed Rewriting Logic with Applications to TimeSensitive Systems, H. Schwichtenberg (ed.): Logic of Computation, Computer and
System Science, Vol. 157, pp. 229-264, Springer 1997.

[KW97b]

Kosiuczenko P. et Wirsing M., Timed Rewriting Logic with an Application to ObjectBased Specification Science of Computer Programming. 28(2-3), Elsevier 1997, pp.

166

225-246.
[Lam94]

Lamport L., The temporal logic of actions, J. of the ACM Transactions on

Programming Languages and Systems, 16(3):872-923, May 1994.

[Lar86]

Larsen K. G., Context-dependent bisimulation between processes, PhD thesis, 1986.

[Led96]

Ledru Y., Completing Semi-Formal Specifications with Zn in Proc. of KBSE'96: 5261, 1996.

[LGS95]

Loiseaux C., Graf S., Sifakis J., A. Bouajjani, and S. Bensalem., Property preserving
abstractions for the verification of concurrent systems, Formal Methods in System
Design, 6:1-35,1995.

[LM00]

Laleau R. et Mammar A., An overview of a method and its support tool for
generating B specifications from UML Notations, in Proc. of the 15th Int. Conf. on
Automated Software Engineering, ASE2000, Grenoble, France, September 2000.

[LN00]

Leucker M. et Noll T., Rewriting Logic as a Framework for Generic Verification

Tools, ENTCS 36, 2000.

[LPS99]

Laroussinie F., Petit A., et Schnoebelen P., Vrification de logiciels : Techniques et

outils du model-checking, Vuibert ditions, 1999.

[LPY97]

Larsen K, Pettersson P., Yi W., UPPAAL, in a nutshell. International Journal on

Software Tools for Technology Transfer, 1(1-2) :134-152, 1997.

[Les94a]

Lescanne P., "Elementary Interpretations in Proofs of Termination", Technical Report,

Centre de Recherche en Informatique (CNRS), INRIA-Loraine, 1994.

[Les94b]

Lescanne P., "An introduction to ORME", Rapport Technique disponible sur

ftp.loria.fr:/pub/loria/ORME.LIFHT, 13 Avril, 1994.

[Mar00]

Marcano R., Formalizing Patterns Applicability: An approach based on UML and B,

in Proc. of ASE2000, IRISA technical report, n PI-1353, Sept 2000.

[McG82]

Mcraw J.R., The Val language : description and analysis, TOPLAS, 4(1), Janvier
1982.

[McM93]

McMillan K. L., Symbolic Model Checking, Kluwer, 1993.

[McM99]

McMillan K.L., The SMV language, Cadence Berkeley Labs, 1999.

[Mes00]

Meseguer J., Rewriting logic and Maude: a wide-spectrum semantic frameworkfor

object-based distributed systems, in S. Smith and C. Talcott, editors, Formal Methods
for Open Object-based Distributed Systems IV, Kluwer, 2000.

[Mes90]

Meseguer, J., Rewriting as a unified model of concurrency, in Proc. Concur90,

LNCS, Volume 458, pp. 384400, 1990..

[Mes92]

Meseguer J., Conditional rewriting logic as a unified model of concurrency. TCS,

96:73-155, 1992.

[Mes98]

Meseguer J.,. Membership algebra as a logical framework for equational

specification, in F. Parisi-Presicce, (ed), Proc. WADT'97, LNCS, pp. 18-61, 1998.

[Mil80]

R. Milner., " A calculus of communicating systems", LNCS 92, 1980.

[Mil89]

Milner. R., "Communication and Concurrency", International Series in Computer

Science, Prentice Hall, 1989.

[MLL00]

Marcano R., Levy N. et Losavio F., Spcification et Spcialisation de Patterns en

UML et B", in Actes LMO00 Langages et Modles Objets, Ed. Herms.
Montral (Ca), janvier 2000.

[MM96]

Marti-Oliet N. et Meseguer J., Rewriting logic as a logical and semantics Framework

, Workshop on Rewriting Logic and its Applications, vol. 4 of ENTCS, Elsevier,
1996.

167

[Mou92]

Mounier. L., "Mthodes de vrification de spcifications comportementales", tude et

mise uvre, Thse, Universit Joseph Fourier, Grenoble, janvier 1992.

[MP92]

Manna Z. et Pnueli A., The Temporal Logic of Reactive and Concurrent Systems
Specification, Springer-Verlag, 1992.

[MP95]

Manna Z. et Pnueli A., Temporal Verification of Reactive Systems: Safety,

Springer-Verlag, New York, 1995.

[MRS01]

Moller M. O., RueB H. et Sorea M., Predicate Abstraction for Dense Real-Time
Systems, BRICS Report Series, RS-01-44, ISSN 0909-0878, November 2001.

[MS00]

Marques-Silva J.P. et Sakallah K.A.., Boolean Satisfiability in Electronic Design

Automation, DAC, pp. 675680. 2000.

[MW85]

Mellor S. et Ward P., "Structured Development for Real Time Systems", Youdon
Press, Prentice Hall, New York, USA, 1985.

[NPW81]

Nielsen M., Plotkin G. et Winskel G., Petri Nets, Event Structures and Domains, part
1, TCS, 13:85-108, 1981.

[Odo77]

ODonnell M.J., Computing in Systems Described by equations, in LNCS 58, 1977.

[Odo85]

ODonnell M.J, Equational Logic as a programming Language, The MIT Press,

Cambridge MA, 1985.

[OKW96]

Olveczki P., Kosiuczenko P. et Wirsing M., Steamboiler specification problem: an

algebraic object-oriented solution, in J. Abrial, E. Boerger, H. Langmaack (eds.):
LNCS 1165, Springer, 1996, 17 pages.

[Olv02]

Olveczky P.C. Formal modeling and analysis of distributed systems in Maude,

Lecture notes for INF220, University of Oslo, Department of Informatics, June 2002.
http://www.ifi.uio.no/inf220/Kompendium/komp2.pdf.

[Olve00]

Olveczky P. C., Specification and Analysis of Real-Time and Hybrid System, in

Rewriting Logic. PhD thesis, University of Bergen, 2000.. http://maude.csl.sri.com/

[OM01a]

Olveczky P. C. et Meseguer J., Specification of real-time and hybrid systems in

rewriting logic, disponible au at http://maude.csl. sri.com/papers, January 2001.

[OM01b]

Olveczky P. C. et Meseguer J.. Specifying and analyzing real-time object systems in

Real-Time Maude, in P. Pettersson and S. Yovine, editors, Proc. Workshop on RealTime Tools, Aalborg University, Denmark, 2001, 2001. Technical report 2001-14,
Department of Information Technology, Uppsala University.

[OMG01]

OMG. Object Constraint Language Specification. in : OMG Unified Modeling

Language Specification, Version 1.4, September 2001. Object Management Group,
Inc., Framingham, Mass., Internet http://www.omg.org, 2001.

[OMG99a] OMG. UML notation guide version 1.3. http://www.rational.com/uml/, June 1999.
[OMG99b] OMG, Unified Modeling Language Specification Version 1.3, Object Management
Group http://www.omg.org/technology/uml/index.htm, 1999.
[OMG99c] OMG GROUP, UML Profile for Scheduling, Performance, and Time, Request for
Proposal, 1999, ftp://ftp.omg.org/pub/docs/ad/99-03-13.doc.
[ORS92]

Owre S., Rushby J., et Shankar N., PVS: A prototype verication system, in
Automated Deduction CADE-11, vol. 607 of LNAI, pp. 748-752, 1992.

[Par81]

Park D., Concurrency and automata on infinite sequnces, in Proceedings of the 5th
GI Conference, LNCS 104, pp. 167-183. Springer-Verlag, 1981.

[Pen88]

Penczek W., A temporal logic for event structures, Fundamenta Informatica,

11(3):297-326, 1988.

[PH85]

Pnueli A. et Harel D., On the Development of Reactive Systems, vol. F13 of NATO

168

ASI, pp. 477-498, Springer-Verlag Berlin Heidelberg, 1985.

[Plo77]

Plotkin G.D, "LCF as a Programming Language", TCS 5, 223-257.

[Pnu77]

Pnueli A., The temporal logic of programs", in Proc. 18th IEEE Symp. Found. of
Comp.Sci., pages 46-57. IEEE Computer Society Press, 1977.

[Pnu85]

Pnueli A., Linear and Branching Structures in the Semantics and Logics of Reactive
Systems, in Proc. Of the 12th ICALP, LNCS 194, pp. 15-32, 1985.

[Pnu86]

Pnueli A., Applications of temporal logic to the specification and verification of

reactive systems: A survey of current trends, in W.-P. de Roever and G. Rozenberg,
editors, Current trends in Concurrency: Overviews and Tutorials, vol. 224 of LNC,
Springer-Verlag, NewYork, N.Y., 1986.

[Pra86]

Pratt V. R., Modeling concurrency with partial orders, International Journal of

Parallel Programming, 15(1):33-71, February 1986.

[Pra95]

Pratt V.R, Anatomy of the Pentium Bug, in P. D. Mosses, M. Nielsen, and H. I.

Schwartzbach, (ed), TAPSOFT'95, vol. 915 of LNCS, pp. 97-107, Springer, 1995..

[PT87]

Paige R. et Tarjan R.E., Three partition refinement algorithms, SIAM Journal on

Computing, 16(6):973989, 1987.

[QS82]

Queille J. et Sifakis J., Specification and verification of concurrent systems in

CESAR, in M. Dezani-Ciancaglini and U. Montanari, (eds), Intl. Symposium on
Programming, vol. 137 of LNCS, pp. 337-351, Springer-Verlag, 1982.

[Rat92]

C. Ratel., Dfinition et ralisation d'un outil de vrification formelle de programmes

LUSTRE : le systme LESAR, Thse de doctorat, INPG, Grenoble. Juillet 1992.

[RBJ+03a] Rebaiaia M.L, Benmohamed M., Jaam J.M. et Hasnah Ahmad, A Toolset for the
Specification and Verification of Embedded Systems, in Hamid R. Arabnia,
Youngsong Mun (Eds.): Proc. of the International Conference on Parallel and
Distributed Processing Techniques and Applications, PDPTA '03, June 23 - 26, 2003,
Las Vegas, Nevada, USA, Vol. 4. pp. 1539-1545, CSREA Press 2003, ISBN 1892512-44-0.
[RBJ+03b] Rebaiaia M.L, Benmohamed M., Jaam J.M. et. Hasnah A, A Rewriting Logic-Based
Computation and Deduction Approach to Avoid Reactive System Malfunctions, in
Hamid R. Arabnia, Youngsong Mun (Eds.): Proc. of the International Conference on
Parallel and Distributed Processing Techniques and Applications, PDPTA '03, pp. 573579, June 23 - 26, 2003, Las Vegas, Nevada, USA, Vol. 4. CSREA Press 2003, ISBN
1-892512-44-0.
[RBP91]

J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Object-Oriented

Modeling andDesign, Prentice Hall, Englewood Cliffs, 1991.

[Reb00]

Rebaiaia M. L., Specification of Real-Time Systems in Timed Rewriting Logic, In

Proc. International Arab Conference of Information Technology, Zarka, Jordan,
October, 2000.

[Reb04a]

Rebaiaia M.L., Embedded Systems Certification using Temporal Logic, in the Proc.
of IEEE International Conference, Information and Communication Technologies:
From Theory to Applications, pp. 577- 578, Syria 19-23 April 2004,. IEEE : ISBN: 07803-8482. http://www.ieeexplore.ieee.org/xpl/.

[RBJ+03c] Rebaiaia M.L, Benmohamed M., Jaam J.M et Hasnah A., Symbolic Simulation:
Toward and Approach Using Prepositional Logic Integer Programming and Neural
Networks, Proc. of, ACIT03, Alexandria, Egypt, 2003.
[Reb02a]

169

Rebaiaia M.L., Real-Time Systems Specification in Timed Rewriting Logic, Zarka

Journal for Research and Studies, Vol 4, N2, pp. 37-53, December 2002, ISSN 15619109.

[RBA+01] M.L Rebaiaia, Benfifi K., Abdellaoui F., Rezki B.et Moustari S, VERIF: an
Automatic Specification and Verification Tool for Industrial and Reactive Systems,
Proc. of the International ACIT01, Jordan, 2001..
RJH03

Rebaiaia M. L., Jaam J. M et Hasnah A, A Decision Support System Based on

Ranking Methods, in H. R. Arabnia,(Ed.),Proc. of the International Conference on
Information and Knowledge Engineering. IKE'03, June 23 - 26, 2003, Las Vegas,
Nevada, USA, Vol. 2. pp. 591-597, CSREA Press 2003, ISBN 1-932415-08-4.

[RG00]

Richters M. et Gogolla M., Validating UML Models and OCL Constraints, in: Proc.
of UML 2000: 3th Int. Conf. The Unified Modeling Language, York, UK. Springer,
Berlin, LNCS 1939, 2000.

[Rit00]

Ritter G., Sequential equivalence checking by symbolic simulation, in FMCAD2000,

vol. LNCS 1954, Springer, November 2000.

[RJ04a]

Rebaiaia ML. et Jaam J.M., VALID-2: A Practical Modeling, Simulation and

Verification Software for Distributed Systems, in the Workshop PMEO-PDS04,
IEEE-IPDPS 2004, San Diego, USA, ISBN : 0-7695-2132-IEEE-2004

[RJ04b]

Rebaiaia ML. et Jaam J.M, A Hierarchical Approach to the Formal Verification of

Distributed Systems, in Proc. of the Internationnal Conference IEEE-ICICS, King Fahd
University, 29/11/ au 01/12, 2004, Dharhan, Seoudia Kingdom, 2004.

[Reb04b]

Rebaiaia M.L, A Deductive Approach to Verify e-commerce Protocols, iIn the Proc. of
the Internationnal Conference IEEE-ICICS, King Fahd University, 29/11/ au 01/12, 2004,
Dharhan, Seoudia Kingdom, 2004.

[RBJ04b]

Rebaiaia ML., Benmohamed M, et Jaam J.M, Improving PTL Model-Checker using

Maude Rewriting Logic, in : Proc. of the SETIT04 International Conference, Sousse,
Tunisie, 2004, ISBN : xxxx-xxxx.

[RJH03a]

Rebaiaia M.L, Jaam M. J et Hasnah A., An Efficient Model Checker Based on the
Axiomatization of Propositional Temporal Logic in Rewriting Logic, in : the Proc. of the
10th IEEE International Conference on Electronics, Circuits and Systems, pp. 866-869,
December 14-17, 2003 - Sharjah - United Arab Emirates, IEEE Catalog Number:
03EX749C. ISBN : 0-7803-8164-5.

[RJH03b]

Rebaiaia M.L, Jaam M. J et Hasnah A., A Neural Network Algorithm for HardwareSoftware Verification, in : the Proc. of the 10th IEEE International Conference on
Electronics, Circuits and Systems, pp. 1332-1335, December 14-17, 2003 - Sharjah United Arab Emirates. ISBN : 0-7803-8164-5.

[RB03]

Rebaiaia M.L et Benmohamed M., A Specification and Verification Software for Critical
Systems, in : Proc. of the Second International Conference on Signals Systems and
Information Technology SSD03, March 26-28-2003, Sousse, Tunisia..

[Reb03b]

Rebaiaia M.L, Mixing Propositional Logic, Integer Programming and Neural Network
for the Hardware/Software Verification, In : Proc. of the Second International
Conference on Signals Systems and Information Technology SSD03, March 26-28-2003,
Sousse, Tunisia..

[Reb03c]

Rebaiaia M.L, "Modelling Real-Time Systems using Rewriting Logic", In : Proc. of the
Second International Conference on Signals Systems and Information Technology
SSD03, March 26-28-2003, Sousse, Tunisia..

[RB02]

Rebaiaia M.L et Benmohamed M., Verification Algorithms for Integer Programming

and Genetic Algorithms, in : Proc. of International Arab Conference of Information
Technology, ACIT02, Doha, Qatar, 2002.

[Reb02b]

Rebaiaia M.L, A Verification Tool Based on Integer Programming and Genetic

Algorithms, In : Proc. of the Algerian Conference on Microelectronics, ACM02, pp.5361, October 13-15, Algiers, Algeria, 2002.

170

[RBJ+03b] Rebaiaia ML., Benmohamed M, Jaam J.M et Hasnah A., Verification Algorithms for
Integer Programming and Genetic Algorithms, In the International Journal of Applied
Sciences & Computations, Vol. 10, N3, December, 2003, pp.191-204. ISSN : 10890025.
[Reb05]

Rebaiaia M.L, Monitoring and Reuse Software Patterns Analysis in Maude, to be

appreared in the Proc. of the IEEE-AICCSA Workshop in Untimed Patterns Analysis, to
be held in American University, CAIRO, Egypt, 3 January, 2005.

[RKT+00] Roubstova E.E., van Katwijk J., Toetenel W.J., Ponk C. et de Rooij R.C.M.,
Specification of Real-Time Systems in UML, ENTCS 39, 2000.
[Rob65]

Robinson J.A., A Mache-Oriented Logic Based on the Resolution Principle, Journal of

the ACM, pp. 23-41, 216-226.

[RSS96]

RueB H, Shankar N. et. Srivas M. K., Modular verification of SRT division, in R. Alur
and T. A. Henzinger, (eds), CAV '96, LNCS 1102, pp. 123-134. Springer-Verlag, 1996.

[Rud93]

Rudell R., Dynamic Variable Ordering for Ordered Binary Decision Diagrams, in ICCAD'93, IEEE Computer Society Press, 1993.

[Rus95]

Russino M.D., A Formalization of a Subset of VHDL in the Boyer-Moore Logic, in

Formal Methods in System Design, vol.7, pp. 7-25, August 1995.

[RW99]

Reggio G. et Wieringa R. J., Thirty one problems in the semantics of UML 1.3
dynamics, Workshop Rigorous Modeling and Analysis of the UML Challenges and
Limitations, OOPSLA'99, November 1999.

[Saw99]

Sawada J., Formal Verification of an Advanced Pipelined Machine, PhD thesis,

University of Texas at Austin, December 1999.

[SB00]

Sommenzi F et Bloem R., Efficient Buchi Automata from LTL formulae, in CAV00,
LNCS 1633, pp. 247-263, 2000.

[SC85]

Sistla A. P. et Clarke E. M., The complexity of propositional linear temporal logics,

Journal of the ACM, 32(3):84103, 1985.

[Sch04]

Schtz B., UML-RT Solution for Embedded Software?, TU Mnchen, Faculty for
Computer Science, Boltzmannstr.3, D-85748 Garching (Munich), 2004.

[SE84]

Streett R. S. et Emerson E. A., The propositional mu-calculus is elementary, in

ICALP'84, LNCS 172, Springer-Verlag, 1984, pp. 467-472.

[Sel03]

Selic B., An Overview of UML 2.0 (and MDA), Tutorial presented at OTS2003 18-19
June 2003. Available at http://lisa.uni-mb.si/cot/ots2003/predkonferenca/ .

[Sel98]

Selic B., "Recursive Control", in Robert Martin, Dirk Riehle, and Frank Buschmann (ed.)
"Pattern Languages of Program Design 3", Addison Wesely Longman Inc 1998, chapter
10, pp147.

[SGW94]

B. Selic, G. Gullekson et Paul T. Ward., Real-Time Object-Oriented Modeling, John

Wiley and Sons, Inc. 1994.

[SK00]

Steggles J. et Kosiuczenko P., A Formal Model for SDL Specification Based on Timed
Rewriting Logic, ASE00, Vol.7(1), Kluver, 2000, pp. 59-88.

[SM02]

Shanchez-Alonso M. et Murillo J. M., "Specifying Cooperation Environment

Requirements using Formal and Graphical Techniques", WER, pp. 225-239, 2002.

[SPIN02]

Spin Formal Verification, 2002. http://netlib.bell-labs.com/netlib/spin/whatspin.html.

[SR98]

B. Selic et J. Rumbaugh., Using UML for Modeling Complex Real-Time Systems.

http://www.objectime.com, 1998.

[SS99]

Silva J. et Sakallah K., GRASP: A Search Algorithm for Propositional Satisfiability ,

IEEE Transactions on Computers, pp.506 521, May 1999.

171

[Ste03]

Stephen F., Temporal ocl extensions for specification of real-time constraints, in Workshop Specification and Validation of UML models for Real Time and Embedded Systems
(SVERTS03), San Francisco, CA, USA, October 2003. UML 2003.

[STP]

The Stanford Temporal Prover. http://www-step.stanford.edu/.

[Tar55]

Tarski, A., A lattice-theoretical fixpoint theorem and its applications, in Pacific Journal
of Mathematics, vol. 5, 1955, pp. 285-309.

[TG00]

Terrier, F., et Gerard, S., Real Time System Modeling with UML: Current Status and
Some Prospects, Proc. of the 2nd Workshop of the SDL Forum society on SDL and MSC,
SAM 2000, Grenoble, France, 2000.

[TKB89]

Toyama Y, Klop J.W.et Barendregt H.P., "Termination for Direct sums of left-linear
complete term rewriting Systems", Report CS-R8923, Centre for Mathematics and
Computer Science, Amsterdam.

[TSL+90]

Touati H. J., Savoj H., Lin B. et. Brayton R. K, Implicit State Enumeration of Finite
State Machines using BDDs, in Proc of ICCAD-90, pp. 130133, 1990.

[TY01]

Tripakis S. et Yovine.S, Analysis of timed systems using time-abstracting

bisimulations", Formal Methods in System Design, 18(1):25-68, January 2001.

[UML01]

UML-OMG. Unified Modeling Language Specification. Version 1.4, September 2001.

[UML03]

IBM. UML 2.0 implementation efforts. Available at http://www.rational.com/

uml/resources/uml2/implementations.jsp 22 July 2003.

[UPPAAL] http://www.uppaal.com
[Uri98]

Uribe T. E., Abstraction-based Deductive-Algorithmic Verification of Reactive

Systems, PhD thesis, Computer Science Department, Stanford University, Dec. 1998.
Technical Report STAN-CS-TR-99-1618.

[Var87]

Vardi, M. Y., Verification of concurrent programs: the automata-theoretic framework,

in Proc. of the 2nd IEEE Symposium on Logic in Computer Science, 1987, pp. 167-176,
1988, pp. 250-259.

[Vir02]

Viry P., Equational rules for rewriting logic, TCS, 285(2):487517, 2002.

[Vir94]

Viry P., Rewriting: An effective model of concurrency, in C. Halatsis, D. Maritsas, G.

Philokyprou, and S. Theodoridis, (eds), Proc. PARLE94, LNCS 817, pp. 648660.
Springer, 1994.

[VMO03]

Verdejo A. et Mart-Oliet N., Executable structural operational semantics in Maude,

Technical Report 134-03, Departamento de Sistemas Informaticos y Programacion,
Universidad Complutense de Madrid, 2003.

[VW86]

Vardi, M. Y. et Wolper, P., Automata-theoretic techniques for modal logics of

programs, in Journal of Computer and System Sciences, vol. 32, 1986, pp. 183-221.

[Wal93]

Walukiewicz, I, On completeness of the mu-calculus, in Proceedings of the 8th Annual

IEEE Symposium on Logic in Computer Science, 1993, pp. 136-146.

[Win86]

Winskel G., Event structures, in W. Brauer, editor, Petri nets: central models and their
properties; advances in Petri nets, LNCS, Berlin-Heidelberg-New York, 1986, Springer.

[Wir90]

Wirsing M., Algebraic specification, in J van Leeuwen, (ed), Handbook of TCS, Vol.
B: Formal Models and Semantics, pages 675 -788. Elsevier, 1990.

[WK98]

Warmer J. et Kleppe A., The Object Constraint Language, Precise Modelling with
UML, Addison-Wesley, 1998.

[WK99]

Warmer J. and Kleppe A., The Object Constraint Language, precise modeling with
UML, Addison-Wesley, Object Technology Series, 1999.

[Wol97]

Wolfgang T., Languages, automata, and logic, in Handbook of formal languages, vol. 3,

172

pp. 389455, Springer, Berlin, 1997.

[WTB+00] Wang Y. , Talpin J-P., Benveniste A. et Le Guernic P., a semantics of UML statemachines using synchronous pre-order transition systems, International Symposium on
Object-Oriented Real-Time Distributed Computing, IEEE Press, Mars 2000.
[You91]

Coad C P et Yourdon E., Object Oriented Analysis, 2nd Edition, YOURDON Press
Computng Series, 1991.

[Yov97]

Yovine S., Kronos: A verification tool for real-time systems, 1997. http://wwwverimag.imag. fr/TEMPORISE/kronos/.

[Yov98]

Yovine. S., Model-checking timed automata, in G. Rozenberg and F. Vaandrager, (eds),

Embedded Systems, LNCS 1494, pp. 114-152, Springer-Verlag, 1998.

[ZB96]

Zhou Z. et Boulerice N., MDG Tools (V1.0) Users Manual, Dept. of Information and
Operational Research, University of Montreal, Montreal, Canada, 1996.

173

ANNEXE A

LA SIGNATURE DU MODULE DE TRANSFORMATION DU CODE VALID EN

CODE MAUDE
Nous informons le lecteur que le code suivant nest quune partie du code original, il peut tre tendu
outrance pour prendre en charge dautres paradygmes de la programmation. Aussi, compte tenu que
Full-MAUDE a t crit en Core-MAUDE, ce qui veut dire que nous aussi nous avons t influenc par
Full-Maude ce qui par la mme occasion montre quune partie du code crit est similaire celle de FullMAUDE.
fmod SIGNS&VIEW-EXPRS is
sorts Token NeTokenList Bubble
SortToken Sort SortList SortDecl
ViewToken ViewExp
SubsortRel SubsortDecl
OpDecl Attr AttrList Hook HookList .
subsorts SortToken < Sort < SortList .
subsort ViewToken < ViewExp .
subsort Attr < AttrList .
subsort Hook < HookList .
op ((_)) : Token Token .
op _[_] : Sort ViewExp Sort [prec 40] .
op __ : SortList SortList SortList [assoc] .
op _,_ : ViewExp ViewExp ViewExp [assoc] .
*** dclaration des types
op Types_. : SortList SortDecl .
op Type_. : SortList SortDecl .
*** dclaration des sous-types
op Subtype_. : SubsortRel SubsortDecl .
op Sutypes_. : SubsortRel SubsortDecl .
op _<_ : SortList SortList SubsortRel .
op _<_ : SortList SubsortRel SubsortRel .
*** operator attributes
op __ : AttrList AttrList AttrList [assoc] .
op assoc : Attr .
op com : Attr .
op id:_ : Bubble Attr .
op strat(_) : NeTokenList AttrList .

174

op strategy(_) : NeTokenList AttrList .

op prec_ : Token Attr .
op gather(_) : NeTokenList Attr .
op gathering(_) : NeTokenList Attr .
op idem : Attr .
*** operator declaration
op Op_: _. : Token Sort OpDecl .
op Op_: _[_]. : Token Sort AttrList OpDecl .
op Op_:__. : Token SortList Sort OpDecl .
op Op_:__[_]. : Token SortList Sort AttrList OpDecl .
op Ops_: _. : NeTokenList Sort OpDecl .
op Ops_: _[_]. : NeTokenList Sort AttrList OpDecl .
op Ops_:__. : NeTokenList SortList Sort OpDecl .
op Ops_:__[_]. : NeTokenList SortList Sort AttrList OpDecl .
endfm
fmod F&S-MODS&THS is
including SIGNS&VIEW-EXPRS .
sorts FDeclList SDeclList PreModule
ImportDecl ModExp Parameter ParameterList
ModuleName EquationDecl RuleDecl MembAxDecl
VarDecl VarDeclList .
subsort Parameter < ParameterList .
subsorts Token < ModExp ModuleName .
subsort VarDecl < VarDeclList .
subsorts VarDecl ImportDecl SortDecl SubsortDecl
OpDecl MembAxDecl EquationDecl VarDeclList < FDeclList .
subsorts RuleDecl FDeclList < SDeclList .
*** dclaration des variables
op Vars_:_. : NeTokenList Sort VarDecl .
op Var_:_. : NeTokenList Sort VarDecl .
*** dclaration des rgles
op R[_] :_=>_. : Token Bubble Bubble RuleDecl .
op CRl[_]:_=>_if_. : Token Bubble Bubble Bubble RuleDecl .
*** dclaration dimportation (*** limportation nexiste pas en VALID nous lavons incorpor***)
op including_. : ModExp ImportDecl .

175

op protecting_. : ModExp ImportDecl .

*** dclaration des listes
op __ : VarDeclList VarDeclList VarDeclList [assoc] .
op __ : SDeclList SDeclList SDeclList [assoc] .
op __ : FDeclList FDeclList FDeclList [assoc] .
*** dclaration des classes
op class_|_. : Sort AttrDeclList ClassDecl .
op class_. : Sort -> ClassDecl .
op _,_ : AttrDeclList AttrDeclList AttrDeclList [assoc] .
op _:_ : Token Sort AttrDecl [prec 40] .
*** dclaration des sous-classes
op subclass_. : SubsortRel SubclassDecl .
op subclasses_. : SubsortRel SubclassDecl .
op _<_ : SortList SortList SubsortRel .
op _<_ : SortList SubsortRel SubsortRel .
*** dclaration de message
op msg_:__. : Token SortList Sort MsgDecl .
op msgs_:__. : NeTokenList SortList Sort MsgDecl .
*** Dclaration du Module formel
op moduleFormel_is_} : ModuleName FDeclList PreModule .
endfm
fmod COMMANDS is
including MOD-EXPRS .
sorts PreCommand .
*** down function
op down_:_ : ModExp PreCommand PreCommand .
*** reduce command
op red_. : Bubble PreCommand .
op red-in_:_. : ModExp Bubble PreCommand .
op reduce_. : Bubble PreCommand .
op reduce-in_:_. : ModExp Bubble PreCommand .
*** rewrite command
op rew_. : Bubble PreCommand .
op rew[_]_. : Token Bubble PreCommand .
op rew-in_:_. : ModExp Bubble PreCommand .

176

op rew-in[_]_:_. : Token ModExp Bubble PreCommand .

op rewrite_. : Bubble PreCommand .
op rewrite[_]_. : Token Bubble PreCommand .
op rewrite-in_:_. : ModExp Bubble PreCommand .
op rewrite-in[_]_:_. : Token ModExp Bubble PreCommand .
*** select command
op select_. : ModExp PreCommand .
*** show commands
op show module . : PreCommand .
op show module_. : ModExp PreCommand .
op show all . : PreCommand .
op show all_. : ModExp PreCommand .
op show sorts . : PreCommand .
op show sorts_. : ModExp PreCommand .
op show ops . : PreCommand .
op show ops_. : ModExp PreCommand .
op show vars . : PreCommand .
op show vars_. : ModExp PreCommand .
op show mbs . : PreCommand .
op show mbs_. : ModExp PreCommand .
op show eqns . : PreCommand .
op show eqns_. : ModExp PreCommand .
op show rls . : PreCommand .
op show rls_. : ModExp PreCommand .
op show view_. : ViewExp PreCommand .
op show modules . : PreCommand .
op show views . : PreCommand .
endfm
fmod FULL-MAUDE-SIGN is
including VIEWS .
including COMMANDS .
endfm

177

ANNEXE B
La logique propositionnelle
Les proprits des systmes squentiels peuvent sexprimer par des relations de pr- et postconditions telles que dfinies par Hoare [Hoa69]. Dans une smantique axiomatique ou bien dans un
modle de vrification, une pr-condition dcrit en gnrale un certain ensemble dtats de dpart tels
que un input(s) dsir(s). Les post-conditions dcrivent loutput(s). De ce fait, la paire pr- et postcondition permet de spcifier le comportement dun programme. A titre dexemple, le programme
squentiel {x = x + 1 ; x = x + 2} tablit la post-condition x gal 3 , une fois que la pr-condition
serait x gal 0 . Le comportement de ce programme ne fait que transformer la valeur de la variable x
de zro vers 3, aprs avoir excut les deux instructions lune aprs lautre.
Comme tout langage de modlisation ou bien de programmation, la logique propositionnelle possde
elle aussi une syntaxe et une smantique propre elle.
Dans ce qui suit, nous allons tudier certains fondements thoriques de cette logique, puisquelle
constitue la base de presque toutes les logiques modales et temporelles.

4.2.1 Syntaxe de la Logique Propositionnelle

La syntaxe de la logique propositionnelle est fonde sur des variables appeles propositions
atomiques qui expriment des faits sur les tats du systme considr (exemples : x gal 0 ,
x suprieur 2 , il pleut , il ny a plus de processus dans la file dattente ). Nous dnotons par
AP lensemble des propositions atomiques que nous notons avec des lettres majuscules ou bien des
lettres quelconques au gr des convenances, possiblement avec des indices ou des primes. Ces lettres
sont censes reprsenter des proprits de base, qui sont soit vraies (true) soit fausses (false). Ces
variables sont combines au moyen de connecteurs logiques pour former des formules quon appellera
propositions que nous noterons par les lettres grecques et (avec des indices ou des primes).
On admet que pour chaque tat dans le systme, il est connu quelle proposition atomique sera
considre pour tablir ce quon appelle la fonction dinterprtation dfinie comme suit,
Dfinition 4.1 (Fonction dInterprtation) La fonction dinterprtation L : S 2AP attribut chaque
tat sS la proposition atomique L(s) qui est valide en s. Autrement dit la fonction L indique quelle sont
les propositions atomiques qui sont valides pour tout tat s. Si par exemple ltat s, L(s) = , ceci
signifie quaucune proposition nest valide en s. Un tat s pour lequel une proposition p est valide
(p L(s)), scrit p-state
Dfinition 4.2 Soit X un ensemble infini dit de variables de proposition. L'ensemble AP des
formules propositionnelles est le plus petit ensemble contenant toutes les variables, et tel que si et
sont des formules, alors , et sont des formules.
En forme textuelle, nous utilisons des parenthses et des priorits pour liminer les ambiguts:
(oprateur de ngation) est plus prioritaire que (oprateur de conjonction) qui l'est plus que
(oprateur de disjonction) qui l'est plus que . Donc la notation de la formule ''' est
exactement la mme chose que dcrire (')'', ' reprsente ()', et ''''''
(')(''''), en particulier. De plus, et sont associatifs gauche, i.e. ''' reprsente
(')'' et ''' (')''. Loprateur est associatif droite, par exemple ' ''
reprsente (''').
Nous dfinissons aussi des abrviations pour d'autres oprations. Par exemple, l'quivalence logique
est dfinie par: = ( ) et ' gale (')(').

178

La relation dquivalence sur les formules permet de regrouper celles qui possdent la mme
signification.
Dfinition 4.3. Par dfinition de la valeur dune formule, deux formules et sont quivalentes si
et seulement si .

4.2.2 Smantique de la Logique Propositionnelle

La smantique des langages de programmation ou tout autre langage sattache donner une
signification toutes ces constructions, cest--dire aux mots du langage selon des rgles bien prcises.
Contrairement aux langages de programmation, chaque formule (mot) construite dans la logique
propositionnelle est cense tre soit vraie soit fausse. Formellement, l'ensemble des valeurs de vrit
est l'ensemble B = {T,F} des boolens, o T F. La signification des connecteurs est dfinie l'aide de
fonctions des boolens vers les boolens. Ces fonctions sont reprsentes par des tables de vrit. Les
voici pour quelques connecteurs de cette logique.
Par exemple, si est suppos vraie (T(rue)), et ' est suppos fausse (F(alse)), alors ' doit
tre faux, (Le premier argument est en colonne, le second en ligne dans les tables de vrit). Ceci
dfinit des fonctions binaires et ou et implication de BB B, et une fonction unaire non.
La signification d'une formule dpend des valeurs de vrit supposes des variables, et nous
dfinissons :
Dfinition 4.7 Une affectation ou
variables propositionnelles vers B.

interprtation

est une application de lensemble X des

Dfinition 4.8 La smantique [] d'une formule dans l'affectation est dfinie par rcurrence
structurelle sur par :

[A] = (A) si A est une variable propositionnelle.

['] =

[] et ['],

['] =

[] ou ['],

['] =

[] implique ['],

[]

non [].

Nous dirons qu'une formule est vraie dans l'affectation si et seulement si [] = T, elle est
fausse dans si et seulement si [] = F.
Dfinition 4.9 Soit une formule propositionnelle, et une affectation. Nous disons que est un
modle de ou que satisfait, et nous crivons |=, si et seulement si [] = T.
Dfinition 4.10 Nous disons qu'un ensemble de formules entrane , et nous crivons |= ,
si et seulement si toutes les affectations satisfaisant toutes les formules de en mme temps (les
modles de ) sont aussi des modles de , c'est--dire quand |= pour tout implique
|= .
Dfinition 4.11 est valide si et seulement si est vraie dans toute affectation [] = T pour tout

, (not |=), et est invalide sinon. Une formule propositionnelle valide est aussi appele une
tautologie.
Dfinition 4.12 est satisfiable si et seulement si elle est vraie dans au moins une affectation, et
est non satisfiable sinon.
Remarque 4.13 Toutes les formules valides sont satisfiables, et toutes les formules non satisfiables
sont invalides. Ceci divise l'espace des formules en trois catgories : les formules valides (toujours
vraies), les formules non satisfiables (toujours fausses), et les formules la fois invalides et satisfiables
(parfois vraies, parfois fausses).

179