Méthodes Formelles pour le Parallélisme

Abstract

L‘objectif de ce cours est d‘apporter aux lecteurs les connaissances fondamentales
sur le domaine des méthodes formelles pour la spécification, la modélisation et la
vérification des systèmes parallèles. Où l‘accent sera mis sur les méthodes
sémantiques de parallélisme, les outils formels de modélisation, ainsi que sur les
méthodes formelles de vérification.
Ce cours est dispensé en 6 chapitres. Le chapitre 1 est un chapitre introductif qui
contient des définitions de base du domaine ainsi que les différentes étapes de
conception d‘un système dit sûr. Le chapitre 2 présente les types de parallélisme ainsi
que ses caractéristiques. Le chapitre 3 est subdivisé en 3 parties, la partie 1 aborde en
détails toutes les notions de base sur les réseaux de Petri en tant qu‘outil de
modélisation puissant des systèmes parallèles. Comme il contient une introduction
aux RdP colorés et RdP temporels. La partie 2 est consacrée à la présentation d‘un
autre outil de modélisation formelle qui est les STE où nous étudierons les deux
notions d‘équivalence et de bisimulation. Dans la partie 3 nous apprenons le langage
de spécification formelles Lotos avec ses deux versions Basic et Full. Le chapitre 4
introduit l‘étudiant au domaine de vérification en essayant de mettre en valeur son
importance dans le processus de développement de systèmes, où nous focalisons sur
le model checking. Le chapitre 5 introduit le problème d‘explosion combinatoire du
graphe d‘état. Finalement le dernier chapitre est une introduction au domaine des
systèmes temps réel.

Full text

UNIVERSITE 8 MAI 1945 GUELMA
Faculté de Mathématiques, d’Informatique et de Sciences de la Matière
Département d’informatique
Polycopiés du module
Méthodes Formelles pour le
Parallélisme
Spécialité master 2 SIQ
Dr. Djalila BOUGHAREB
Année universitaire 2016-2017
 



Table des matières
2
Table des matières
Avant propos ........................................................................................................................................ 8
Pré-requis ............................................................................................................................................. 8
Chapitre 1 : Trajectoire de Conception des Systèmes Sûrs ............................................................. 9
Introduction. .................................................................................................................................... 9
Définition 1.1 (Sûreté de fonctionnement). .................................................................................. 9
Définition 1.2 (Fiabilité). ................................................................................................................ 9
Définition 1.3 (Maintenabilité). ..................................................................................................... 9
Définition 1.4 (Disponibilité). ........................................................................................................ 9
Définition 1.5 (Sécurité). ................................................................................................................. 9
Définition 1.6 (Défaillance). ........................................................................................................... 9
Etapes de Conception des Systèmes Sûrs. .................................................................................. 10
Phase Architecturale. ........................................................................................................ 10
Phase d‘implémentation. .................................................................................................. 10
Phase de réalisation. ......................................................................................................... 10
Méthodes formelles. ...................................................................................................................... 10
Définition 1.7 (Spécification). ....................................................................................................... 10
Types de spécifications. ................................................................................................................ 10
Spécifications informelles ................................................................................................. 10
Spécifications semi-formelles ............................................................................................ 11
Spécifications formelles ..................................................................................................... 11
Définition 1.8 (Parallélisme vs concurrence). ............................................................................ 11
Modèles de spécification du parallélisme. .................................................................................. 11
Modèles sémantiques de parallélisme. ....................................................................................... 12
Modèles entrelacés, ............................................................................................................ 12
Modèles non entrelacés, .................................................................................................... 12
Approches de vérification. ............................................................................................................ 12
L‘approche comportementale. ........................................................................................... 12
L‘approche logique. ............................................................................................................ 12
L‘approche test formel. ...................................................................................................... 13
Chapitre 2 : Sémantique du Parallélisme ....................................................................................... 14
Types de sémantique. .................................................................................................................... 14
Sémantique d‘entrelacement .............................................................................................14
Sémantique de non-entrelacement ....................................................................................14
Caractéristique du parallélisme. .................................................................................................. 14
Caractéristique par bisimulation. ......................................................................................14
Caractéristique par raffinement d‘actions. ........................................................................14
Chapitre 3. Les modèles de spécification ........................................................................................ 16
I. Les Réseaux de Petri .................................................................................................................. 16
Introduction. .................................................................................................................................. 16
Définition 3.1 (Réseau de Petri). .................................................................................................. 16
Règles de base. ............................................................................................................................... 17
Définition 3.2 (Entrées/Sorties). ................................................................................................. 17
Représentations de RDP ............................................................................................................... 17
Représentation graphique ................................................................................................. 17
Représentation matricielle. ................................................................................................ 17

Table des matières
3
Définition 3.3 (Marquage). ........................................................................................................... 18
Franchissement. ................................................................................................................................ 18
Définition 3.4 (Franchissabilité).................................................................................................. 18
Exercice 3.1. ................................................................................................................... 18
Définition 3.5 (Tir de transitions). .............................................................................................. 19
Définition 3.6 (Transition tirée). ................................................................................................. 19
Définition 3.7 (Graphe d'accessibilité). ....................................................................................... 20
Définition 3.8 (Graphe de couverture)........................................................................................ 20
Règles de construction. ................................................................................................................. 20
Propriétés. ...................................................................................................................................... 20
Définition 3.9 (Concurrence). ...................................................................................................... 21
Définition 3.10 (Conflit)................................................................................................................ 21
Définition 3.11 (Non-déterminisme). .......................................................................................... 21
Définition 3.12 (Conflit). ............................................................................................................... 21
Définition 3.13 (Conflit structurel). ............................................................................................. 21
Définition 3.14 (Conflit effectif). .................................................................................................. 21
Définition 3.15 (Parallélisme structurel). ................................................................................... 21
Définition 3.16 (Parallélisme effectif). ........................................................................................ 22
Exercice 3.2. ................................................................................................................... 22
Propriétés standards des RdP ...................................................................................................... 22
Définition 3.17 (Bornitude). ......................................................................................................... 22
Définition 3.18 (Pseudo vivacité). ................................................................................................ 22
Définition 3.19 (Quasi-vivacité). .................................................................................................. 22
Définition 3.20 (Vivacité d‘une transition). ............................................................................... 22
Définition 3.21 (Vivacité d‘un réseau). ........................................................................................ 23
Exercice 3.3. ................................................................................................................... 23
Définition 3.22 (Réversibilité). .................................................................................................... 23
Définition 3.23 (Place invariante, transition invariante).......................................................... 23
Définition 3.24 (Pureté). ............................................................................................................... 23
Définition 3.25 (Blocage). ............................................................................................................. 24
Définition 3.26 (RDP répétitif). ................................................................................................... 24
Autres propriétés ........................................................................................................................... 24
Définition 3.27 (Réseau à capacité). ............................................................................................ 24
Exercice 3.4 (récapitulatif). ....................................................................................... 25
Modélisation des systèmes concurrents par les réseaux de Petri. ........................................... 25
Extension des RdP. ........................................................................................................................ 26
Réseaux de Petri Colorés (RdPC). ............................................................................................... 26
Réseaux de Petri temporels (RdPT). ........................................................................................... 26
II. Les Systèmes de transitions ........................................................................................................ 28
Introduction. .................................................................................................................................. 28
Définition 3.28 (système de transitions). ................................................................................... 28
Définition 3.29 (Systèmes de transitions étiquetés). ................................................................ 28
Types d‘actions............................................................................................................................... 29
Action d‘entrée. ................................................................................................................. 29
Action de Sortie. ................................................................................................................ 29

Table des matières
4
Action interne. .................................................................................................................. 29
Définition 3.30 (Chemin). ............................................................................................................ 29
Définition 3.31 (exécution). .......................................................................................................... 30
Définition 3.32 (trace)................................................................................................................... 30
Définition 3.33 (Trace observable). ............................................................................................. 30
Définition 3.34 (Arbre d'exécution). ........................................................................................... 30
Définition 3.35 (STE avec variables). .......................................................................................... 30
Synchronisation. ............................................................................................................................ 30
Synchronisation par message. ........................................................................................... 31
Synchronisation par variables partagées. .......................................................................... 31
Définition 3.36 (Équivalence de traces). ..................................................................................... 31
Définition 3.37 (Équivalence de traces observables)................................................................. 31
Définition 3.38 (Bisimulation). .................................................................................................... 32
Définition 3.39 (Bisimulation faible vs forte). ........................................................................... 32
Exercice 3.5. ................................................................................................................... 33
III. Modèles des Algèbres de Processus .......................................................................................... 34
Basic et Full LOTOS .......................................................................................................................... 34
Introduction. .................................................................................................................................. 34
Définition 3.40 (Langage LOTOS)............................................................................................... 34
Définition 3.41 (Basic LOTOS). .................................................................................................... 34
Définition 3.42 (Processus). ......................................................................................................... 34
Définition 3.43 (Expression de comportement). ....................................................................... 35
Syntaxe. ........................................................................................................................................... 35
Types d‘action. ............................................................................................................................... 35
Actions internes. ............................................................................................................... 35
Actions de synchronisation ............................................................................................... 35
Opérateurs du langage. ................................................................................................................. 35
Processus élémentaire. ..................................................................................................... 35
Terminaison avec succès. .................................................................................................. 35
préfixage (séquence) ......................................................................................................... 35
Choix non déterministe..................................................................................................... 36
Instanciation de processus................................................................................................ 36
Parallélisme. ...................................................................................................................... 37
Exercice 3.6.................................................................................................................... 37
Masquage (Hiding). .......................................................................................................... 39
Composition séquentielle.................................................................................................. 39
Interruption. ..................................................................................................................... 40
Exercice 3.7. ................................................................................................................... 40
Définition 3.44 (Full LOTOS). ..................................................................................................... 41
Définition 3.45 (Action Full LOTOS). ......................................................................................... 41
Définition 3.46 (Variable LOTOS). .............................................................................................. 41
Définition 3.47 (Expression de valeur). ...................................................................................... 41
Définition 3.48 (Sort). ................................................................................................................... 41
Opérateurs du langage. ................................................................................................................. 41
Préfixage. ...........................................................................................................................41
Synchronisation. ................................................................................................................41

Table des matières
5
Types de synchronisation. .................................................................................................41
Exemple. ............................................................................................................................41
Exemple ............................................................................................................................ 42
Prédicat et garde. .............................................................................................................. 42
Types abstraits de données........................................................................................................... 42
Opération ........................................................................................................................................ 43
Équation ......................................................................................................................................... 43
Exercice 3.8. .................................................................................................................. 43
Chapitre 4. Vérification des Systèmes Concurrents ...................................................................... 45
Introduction. .................................................................................................................................. 45
Définition 4.1 (Vérification formelle). ......................................................................................... 45
Points de vérification. ................................................................................................................... 45
Approches de vérification. ............................................................................................................ 46
L‘approche logique. ........................................................................................................... 46
Logique modale. ............................................................................................................................ 46
Opérateurs principaux. ..................................................................................................... 46
Propriétés. ......................................................................................................................... 46
Limites de HML ................................................................................................................ 47
Logique temporelle. ....................................................................................................................... 48
Logique du temps linéaire (LTL). ..................................................................................... 48
Syntaxe de LTL ................................................................................................................. 48
Sémantique des opérateurs de LTL .................................................................................. 48
Exercice 4.1. ................................................................................................................... 49
Computation Tree Logic (CTL) ......................................................................................... 49
Syntaxe de CTL ................................................................................................................. 49
Opérateurs temporels ....................................................................................................... 49
Sémantique des Formules CTL de base. ........................................................................... 50
Exemple CTL (le diner des philosophes). .......................................................................... 51
Exercice 4.2. ................................................................................................................... 51
L‘approche comportementale. ..................................................................................................... 51
 L‘équivalence comportementale. ................................................................................ 51
 La bisimulation. .......................................................................................................... 51
 L‘équivalence de test ................................................................................................... 51
L‘approche test formel. ................................................................................................................. 52
Techniques de test ............................................................................................................ 52
Test de conformité. ........................................................................................................................ 52
A retenir. ......................................................................................................................................... 52
Preuve et Model checking ................................................................................................................. 53
Preuve. ............................................................................................................................................ 53
Model checking .............................................................................................................................. 53
Principe de model checking.......................................................................................................... 54
Définition 4.2 (contre exemple). .................................................................................................. 54
Avantages et limites. ..................................................................................................................... 55
Exercice 4.3. .................................................................................................................. 56
Model checking symbolique (Symbolic model checking). ........................................................ 56
Définition 4.3 (model checking symbolique), ............................................................................ 56

Table des matières
6
Principe du model checking symbolique. ................................................................................... 57
Fonctions booléennes. .................................................................................................................. 57
Fonctions Basiques. .......................................................................................................... 57
Représentations possibles................................................................................................. 57
Réduction de BDD ......................................................................................................................... 59
BDD Ordonnés (OBDDs) .............................................................................................................. 61
Exercice 4.5. ....................................................................................................................61
Opérateur à points fixés (Fixed point operators)....................................................................... 61
Axiomes de CTL. ............................................................................................................................ 62
Protocol de conception et vérification. ........................................................................................ 63
A retenir. ......................................................................................................................................... 63
Chapitre 5 : problème de l‘explosion combinatoire du graphe d‘état.......................................... 64
Introduction. .................................................................................................................................. 64
Solutions proposées. ..................................................................................................................... 64
Réduction par bisimulation. ............................................................................................. 65
Réduction basée sur les ordres partiels. ........................................................................... 65
Définition 5.1 (Indépendance). .................................................................................................... 65
Définition 5.2 (ordre partiel) ........................................................................................................ 65
Définition 5.3 ................................................................................................................................. 65
Les ensembles têtus. ......................................................................................................... 66
Ensembles persistants. ..................................................................................................... 66
Ensembles dormants (Sleep Set). ..................................................................................... 66
Techniques par « pas ». .................................................................................................... 67
Définition 5.4 (Graphe de pas couvrant), ................................................................................... 67
Principe de la sémantique de maximalité. .................................................................................. 67
A retenir. ......................................................................................................................................... 68
Chapitre 6 : systèmes temps réel ..................................................................................................... 69
Définition 6.1 (Système temps réel (STR). ................................................................................. 69
Définition 6.2 (Contraintes de temps). ....................................................................................... 69
Définition 6.3 (échéances) ............................................................................................................ 69
Types de temps. ............................................................................................................................. 69
Le temps continu, ............................................................................................................. 69
Le temps discret (ou logique), .......................................................................................... 69
Autres classifications. .................................................................................................................... 69
Types de contraintes. .................................................................................................................... 69
Contraintes temporelles externes. .................................................................................... 69
Contraintes temporelles internes. .................................................................................... 70
Classement des systèmes temps-réel. ......................................................................................... 70
Système temps-réel critique ............................................................................................. 70
Système temps-réel ferme (firm real-time) ...................................................................... 70
Système temps-réel souple, lâche ou mou (soft real-time) .............................................. 70
Définition 6.4 (Ordonnancement). .............................................................................................. 70
Classification des ordonnancements. .......................................................................................... 70
Ordonnancements Hors-ligne. ......................................................................................... 70
Ordonnancements Enligne. .............................................................................................. 70
Non préemptif. ................................................................................................................... 71

Table des matières
7
Préemptif. .......................................................................................................................... 71
Vérification des contraintes temporelles. ................................................................................... 71
Vérification formelle des systèmes temps réel. .......................................................................... 71
Syntaxe TCTL ................................................................................................................................. 71
Exercice 6.1. ................................................................................................................... 72
La sémantique de TCTL ................................................................................................................ 72
Algorithme model checking TCTL ............................................................................................... 72
A retenir. ......................................................................................................................................... 73
Conclusion. ..................................................................................................................................... 74
Bibliographie .................................................................................................................................. 75
Table des figures
Figure 2.1. Entrelacement des actions 1 et 2.............................................................................. 14
Figure 3.1 Exemple de réseau de Petri avec 3 places, une transition, et 3 jetons : Tous les arcs
ont un poids égal à 1. ......................................................................................................................... 16
Figure 3.2 la représentation graphique d‘un RdP .......................................................................... 17
Figure 3.3 Matrices d‘incidence ....................................................................................................... 18
Figure 3.4 Marquage et franchissement de transition .................................................................. 19
Figure 3.5 le graphe de couverture .................................................................................................. 21
Figure 3.6 la Représentation graphique d‘un STE ......................................................................... 29
Figure 3.7 Synchronisation............................................................................................................... 39
Figure 4.1 étapes techniques du model checking ........................................................................... 54
Figure 4.2 Arbre de décision binaire ............................................................................................... 58
Figure 5.1: un ordre partiel dans P({1,2,3}) .................................................................................... 66
Figure 5.2: Arbres de dérivation de E et F obtenus par la technique de maximalité ................. 68

Avant propos
8
Avant propos
L‘objectif de ce cours est d‘apporter aux lecteurs les connaissances fondamentales
sur le domaine des méthodes formelles pour la spécification, la modélisation et la
vérification des systèmes parallèles. Où l‘accent sera mis sur les méthodes
sémantiques de parallélisme, les outils formels de modélisation, ainsi que sur les
méthodes formelles de vérification.
Ce cours est dispensé en 6 chapitres. Le chapitre 1 est un chapitre introductif qui
contient des définitions de base du domaine ainsi que les différentes étapes de
conception d‘un système dit sûr. Le chapitre 2 présente les types de parallélisme ainsi
que ses caractéristiques. Le chapitre 3 est subdivisé en 3 parties, la partie 1 aborde en
détails toutes les notions de base sur les réseaux de Petri en tant qu‘outil de
modélisation puissant des systèmes parallèles. Comme il contient une introduction
aux RdP colorés et RdP temporels. La partie 2 est consacrée à la présentation d‘un
autre outil de modélisation formelle qui est les STE où nous étudierons les deux
notions d‘équivalence et de bisimulation. Dans la partie 3 nous apprenons le langage
de spécification formelles Lotos avec ses deux versions Basic et Full. Le chapitre 4
introduit l‘étudiant au domaine de vérification en essayant de mettre en valeur son
importance dans le processus de développement de systèmes, où nous focalisons sur
le model checking. Le chapitre 5 introduit le problème d‘explosion combinatoire du
graphe d‘état. Finalement le dernier chapitre est une introduction au domaine des
systèmes temps réel.
Pré-requis
– Cours Sémantiques formelles des langages de Programmation (Master 1)
– Cours Logique et fondements de l‘informatique (Master 1)

Chapitre I : Trajectoire de Conception des Systèmes Sûrs
Chapitre 1 : Trajectoire de Conception des
Systèmes Sûrs
Introduction.
Les avantages des méthodes formelles se traduisent essentiellement par la réduction
des coûts de développement d‘un système parallèle, et suite au fait qu‘elles sont
fondées sur une base théorique solide qui est les mathématiques, ces méthodes
permettent des validations automatisées des propriétés du système développé.
L‘objectif de ce chapitre du cours est d‘introduire le lecteur dans le domaine des
méthodes formelles de développement des systèmes parallèles. Où l‘accent sera mis
sur les phases de développement d‘un système dit sûr, ainsi que les définitions de
base inhérente au domaine à savoir : la spécification, ses qualités, ses types. Le
chapitre aborde également les différents modèles de spécification et les intérêts
d‘utilisation des méthodes formelles.
Définition 1.1 (Sûreté de fonctionnement). La sûreté de
fonctionnement est un ensemble d'outils et de méthodes qui permettent, dans toutes
les phases de vie d'un produit ou d'un système, de s'assurer que celui-ci va accomplir
les missions pour lesquelles il a été conçu, et ce, dans des conditions de fiabilité, de
maintenabilité, de disponibilité et de sécurité (FMDS) bien définies. Selon Villemeur
[Villemeur 88] la sûreté de fonctionnement est la science des défaillances, elle inclut
ainsi leur connaissance, leur évaluation, leur prévision, leur mesure et leur maîtrise.
Définition 1.2 (Fiabilité). La propriété de la fiabilité désigne l‘aptitude du
système à satisfaire une fonction requise dans des conditions données sur un
intervalle de temps [0, ].
Définition 1.3 (Maintenabilité). La propriété de la maintenabilité désigne
l‘aptitude d‘un système à maintenir ou à remettre en état de fonctionnement une
entité défaillante à un instant 1 sachant que la défaillance s‘est produite à l‘instant 0.
Définition 1.4 (Disponibilité). La propriété de la disponibilité désigne la
probabilité qu'un composant ou un système soit en état d‘accomplir une fonction
requise à un instant donné .
Définition 1.5 (Sécurité). La propriété de la sécurité désigne l'aptitude d'un
système à respecter, pendant toutes les phases de vie, un niveau acceptable de
tolérance de défaillance logicielle ou matérielle susceptible d'occasionner une
agression du personnel ou une dégradation majeure du produit ou de son
environnement.
Définition 1.6 (Défaillance). La défaillance d‘une entité signifie qu‘elle
cesse d‘accomplir une fonction requise.

Chapitre I : Trajectoire de Conception des Systèmes Sûrs
10
Etapes de Conception des Systèmes Sûrs.
Phase Architecturale. Cette phase vise à analyser et spécifier le système, elle permet
de répondre à la question : «Que fera le système ?» et elle décrit l‘apparence du
fonctionnement du système à l‘utilisateur. La phase architecturale forme un pont
entre les exigences décrites dans le cahier des charges et le code source du système.
Phase d‘implémentation. Elle décrit la structure logique qui interprète l‘architecture
élaborée. Ceci dit qu‘elle vise à répondre à la question : «Comment le système sera-t-
il construit ?»
Phase de réalisation. C‘est la structure physique qui explique la conception logique,
ici, on répond sur les questions : Qui vont utiliser le système? Où va-t-être mise en
place? Et construit-on le produit correctement ?
Méthodes formelles.
Les méthodes formelles consistent à utiliser les mathématiques pour le
développement de logiciels. Les principales activités sont [Tremblay 06]:
 L‘écriture d‘une spécification formelle;
 La preuve de certaines propriétés de cette spécification ;
 La construction d‘un programme en manipulant mathématiquement la
spécification ;
 La vérification du programme à l‘aide de raisonnements mathématiques.»
Définition 1.7 (Spécification). La spécification est le premier document qui
décrit les fonctionnalités requises du système à développer pour un client. La
spécification ne devrait décrire que ce que le système doit faire quoi ?, et non pas
décrire comment cela devrait être fait. Elle joue deux rôles vitaux : Celui d‘un
document contractuel avec le client décrivant ses besoins et exigences, et celui d‘un
document prescriptif à partir duquel le concepteur devra produire une solution.»
[Tremblay 06].
À chaque fin d‘étape du cycle de développement correspond un document appelé
spécification. Terme ‗spécification‘ peut être utilisé à différents niveaux du
développement du système: spécification des exigences, d‘implantation, d‘un module,
d‘une propriété, de tests, de procédures de tests, de données, de traitements, etc.
La spécification initiale représente le cahier des charges du produit, et la spécification
finale représente le produit lui-même.
Types de spécifications.
Les spécifications peuvent être classées selon leur degré de formalisme en trois types:
les spécifications informelles, semi-formelles et les spécifications formelles.
Spécifications informelles, elles s‘agissent de descriptions en langue naturelle, elles
manquent souvent de précision.
Exemple.
Fragment de spécification d‘un éditeur de texte
La sélection est le processus de désignation des zones du document que vous
souhaitez travailler dessus. La plupart des actions d'édition et de formatage

Chapitre I : Trajectoire de Conception des Systèmes Sûrs
11
nécessitent deux étapes: d'abord vous sélectionnez le/ les objets que vous voulez
travailler dessus, tels que du texte ou des graphiques; puis vous lancez l'action
appropriée.
La spécification ci-dessus manque de précision et de clarté tel qu‘elle n‘explique pas si
une zone désignée peut être dispersée?
Spécifications semi-formelles, elles utilisent un langage de spécification textuel ou
graphique, doté d‘une syntaxe précise et d‘une sémantique assez faible, tel que Merise
et UML.
Exemple.
Spécifications formelles, elles sont exprimées dans un langage à syntaxe et
sémantique précises, construites sur une base théorique solide (mathématiques), ce
qui permet des validations automatisées. Les réseaux de Petri, les grammaires
formelles, les automates à états finis, la logique formelle, l'algèbre de processus, la
théorie des graphes, etc., sont autant d'exemples de telles techniques.
Exemple.
Specification Distributeur_Client [MONNAIE , THE, CAFE, CHOCOLATE, CHANGE] : noexit
Behaviour
Distributeur [MONNAIE , THE, CAFE, CHOCOLATE, CHANGE, CHOIX]
| [MONNAIE , THE, CAFE, CHOCOLATE, CHANGE] |
(Client [MONNAIE, THE, CAFE, CHOCOLATE, CHANGE, CHOIX]
|||
Client [MONNAIE, THE, CAFE, CHOCOLATE, CHANGE, CHOIX])
Where
.
.
.
Endspec.
Remarque. Puisqu‘elles sont fondées sur les mathématiques, les spécifications
formelles sont précises alors que les spécifications informelles et les spécifications
semi-formelles sont ouvertes à la réinterprétation.
Définition 1.8 (Parallélisme vs concurrence).
Un système dit parallèle est un système dont ses entités ou processus peuvent
exécuter des actions qui peuvent être dépendantes simultanément pour effectuer
plusieurs taches simultanément, où chaque processus parallèle utilise ses propres
ressources. Tandis qu‘un système concurrent est un système qui permet l‘exécution
d‘actions indépendantes afin de traiter plusieurs taches à la fois permettant ainsi
l'accès simultané aux ressources partagées.
Modèles de spécification du parallélisme.
La spécification formelle de systèmes modulaires comprend une description abstraite
des modules (données et traitements) et leurs interactions. Parmi ces modèles, nous
pouvons citer :

Chapitre I : Trajectoire de Conception des Systèmes Sûrs
12
 Les modèles abstraits, définit le module par une structure de données
informatique ou mathématique et un ensemble d'opérations. Les opérations
sont des abstractions procédurales axiomatiques ou opérationnelles à base
d‘algorithmes. La concurrence entre modules est généralement implicite. Les
structures de données mathématiques sont souvent abstraites et donc plus
simples à spécifier, mais les preuves sont plus difficiles à réaliser et à
automatiser. Une spécification par modèle abstrait correspond à un système
formel dont la syntaxe est donnée par les types et opérations du modèle
abstrait et dont la sémantique est donnée par la théorie sous-jacente au
modèle abstrait par exemple la théorie des ensembles, la logique du premier
ordre, la théorie des types, etc. Parmi les langages basés sur ces modèles nous
citons le langage Z [Abrial et al 80], et Vienna Development Method VDM
[Bicarregui et Ritchie 91].
 Les modèles algébriques. Selon ces modèles, le module définit un type de
données mais aucune structure particulière n'est exhibée. Les propriétés du
système sont décrites par des axiomes et sous certaines conditions, les preuves
peuvent être automatisées. Ces modèles modélisent un module par un
processus. Dans une telle spécification l'accent est mis sur les interactions
entre modules plutôt que sur la structure. Ce type de spécification a été étudié
dans les algèbres de processus comme CSP [Hoare 85] ou CCS [Milner 89] ou
encore dans les systèmes de transitions (automates, les réseaux de Petri) ou
dans les logiques temporelles [Arnold 92].
Modèles sémantiques de parallélisme. Ils expriment la sémantique des
modèles de spécification. Nous pouvons diviser ces modèles en deux catégories :
Modèles entrelacés, se basent sur l‘hypothèse d‘atomicité temporelle et structurelle
des actions. Parmi ces modèles nous citons : les systèmes de transitions étiquetées
que nous étudierons dans le chapitre 3, les arbres de synchronisation, les arbres de
refus, les graphes de refus, etc.
Modèles non entrelacés, appelés aussi modèles du vrai parallélisme, ces modèles
considèrent, dès la phase de conception, que les actions ne sont pas atomiques. D‘où
l‘association de durées aux actions. Parmi ces modèles nous citons : les réseaux de
Petri que nous étudierons dans le chapitre 3, les systèmes de transitions asynchrones,
les arbres maximaux, etc.
Approches de vérification.
Le but de la vérification formelle est d‘assurer qu‘un système ou programme modélisé
et spécifié satisfait un certain nombre de propriétés en fonction du modèle et du
langage de spécification et avec des algorithmes. Nous distinguons dans la littérature
trois grandes approches de vérification à savoir : l‘approche comportementale,
l‘approche logique et l‘approche test formel.
L‘approche comportementale. Dans cette approche, la description opérationnelle du
système ainsi que sa spécification, sont toutes les deux exprimées par des
comportements. Cette approche sera abordée en détails au chapitre 4.
L‘approche logique. Dans cette approche, les propriétés attendues du système sont
exprimées par des assertions dans une logique avancée, par exemple la logique
modale ou la logique temporelle. Selon cette approche, deux systèmes sont
équivalents s‘ils satisfont la même proposition logique.

Chapitre I : Trajectoire de Conception des Systèmes Sûrs
13
L‘approche test formel. Elle se base sur le principe de comparaison des
comportements obtenus par le système avec le comportement attendu. Une
procédure de test est parfaite si elle confronte le système à l‘ensemble des entrées
possibles.
A retenir
Au terme de ce chapitre je vous présente brièvement dans cette section l‘essentiel à
retenir par l‘étudiant.
– Sûreté de fonctionnement regroupe les activités d'évaluation de la fiabilité, de
la maintenabilité, de la disponibilité et de la sécurité d‗un système (FMDS).
– Sûreté: quelque chose de mal n'arrive jamais.
– Spécification du système est une description plus ou moins détaillée du
comportement attendu, elle peut être informelle quand il s‘agit d‘une
description en langue naturelle ce qui manque souvent de précision. Elle peut
être semi-formelle quand elle est basée sur un langage de spécification textuel
ou graphique, (doté d‘une syntaxe précise et d‘une sémantique assez faible
comme Merise et UML). Come elle peut être aussi formelle, quand elle est
exprimée dans un langage à syntaxe et sémantique précises, construites sur
une base théorique solide (mathématiques). Ceci rend la vérification de telle
spécification réalisable, et là nous avons vu trois grandes approches de
vérification qui sont l‘approche comportementale, logique et test formel.

Chapitre 2 : Sémantique du Parallélisme
14
Chapitre 2 : Sémantique du Parallélisme
Types de sémantique. Nous pouvons distinguer deux types de sémantique : la
sémantique d‘entrelacement et la sémantique de non entrelacement.
Sémantique d‘entrelacement, la particularité des systèmes concurrents est qu‘ils
peuvent avoir plusieurs transitions franchissables simultanément. La sémantique
d‘entrelacement appelée aussi sémantique du losange repose sur le principe de tir
d‘une seule transition à la fois. Ceci permet de considérer tous les cas d‘exécution
possibles. Par exemple, le comportement d‘un système qui exécute en parallèle les
deux actions 1 et 2 contiendra les deux séquences 12 et 21 produites par leur
entrelacement (Voir la figure 2.1).
Le problème inhérent à cette sémantique est l‘explosion combinatoire qui sera
abordée en chapitre 5. Parmi les modèles d‘entrelacement nous pouvons citer les
systèmes de transitions étiquetées qui seront étudiés en chapitre 3, partie 2 et les
arbres de synchronisation.
Figure 2.1. Entrelacement des actions 1 et 2
Sémantique de non-entrelacement, ces modèles ont la capacité de décrire le
comportement d‘un système en représentant les relations de dépendance et, par
dualité, le parallélisme entre occurrences d‘actions. Ils se divisent en deux catégories
les modèles d‘ordre partiel et les modèles du vrai parallélisme.
– Sémantique d‘ordre partiel, modèle sémantique dont le principe consiste à
considérer les relations de dépendance entre les occurrences d‘actions. Parmi
les modèles qui adoptent ce principe, les arbres causaux, les arbres causaux
dynamiques, les systèmes de transitions étiquetées causaux.
– Sémantique du vrai parallélisme, qui est basée sur le principe du non
multiplication du nombre de configurations lorsque plusieurs composants
s‘exécutent en parallèle.
Caractéristique du parallélisme.
Caractéristique par bisimulation. C‘est une notion définit par Park [Park 81, Milner
89], elle est à la base des techniques de vérification par abstraction utilisées dans le
cadre des spécifications algébriques. Intuitivement, deux systèmes sont bisimilaires
lorsqu‘ils ont les mêmes possibilités d‘évolution et que chaque état atteint par une
évolution de l‘un est bisimilaire à un état atteint dans l‘autre système par la même
évolution.
Caractéristique par raffinement d‘actions. L‘utilisation des modèles de non
entrelacement en tant que domaines sémantiques pour les modèles de spécification
permet la conception de systèmes par raffinement successif. Le raffinement consiste à
2
2
1
1

Chapitre 2 : Sémantique du Parallélisme
15
remplacer une action par un processus et cette opération peut être interprétée dans le
modèle sémantique sous-jacent. Il s‘agit d‘n processus de conception allant de
l‘abstrait vers le concret. il consiste à partir d‘une spécification riche en matière de
variables mathématiques pour aboutir à une spécification riche en variables qui sont
plus simplifiées et proche de structures informatique usuelles (tableaux, scalaires,
etc.). À chaque ajout de détail des actions non observables deviennent observables ce
qui permet de décrire avec plus de détails le comportement du système. On doit
assurer de la cohérence entre le système avant et après raffinement.
A retenir.
Ce chapitre introduit à l‘étudiant de façon générale des notions de base que nous
abonderons avec plus de détails dans les prochains chapitres à savoir les différents
types de sémantique, la bissimilation et le raffinement successifs d‘actions.

Chapitre 3 : Les modèles de spécification
16
Chapitre 3. Les modèles de spécification
I. Les Réseaux de Petri
Introduction.
La théorie des réseaux de Petri a été introduite en 1962 par Carl Adam Petri dans sa
thèse de doctorat intitulée kommunication mit automaten « communication with
automata » [Petri 62]. Depuis ce temps leur utilisation a été constamment
augmentée. Ils permettent de modéliser un système concurrent ou parallèle dont
l‘analyse dévoile des informations importantes sur la structure du système et son
comportement dynamique. Le but de ce chapitre est de présenter l‘essentiel de cette
théorie de manière cohérente et consistante. Il peut être utile pour des étudiants en
graduation et en post graduation en informatique et en ingénieries.
Définition 3.1 (Réseau de Petri). Un réseau de Petri est un formalisme
mathématique pouvant être représenté par un graphe bipartite qui contient des
places (dessinées par des cercles) et des transitions (dessinées par des rectangles).
Les places peuvent comporter des jetons et elles représentent l‘état d‘une entité. Les
transitions représentent des événements ou des actions.
Formellement, un réseau de Petri (RdP) est un quadruplet (,,,), où
  est un ensemble fini de places,
  est un ensemble fini de transitions,
   ×× un ensemble fini d‘arcs pondérés connectant une place à
une transition et vice-versa.
  est une fonction qui associe à chaque arc un poids sous forme d‘un entier
strictement positif :    +
Les poids des arcs sont égaux à 1 par défaut, on ne note sur le graphe que les poids
différents de 1. La figure 3.1 montre la structure d‘un RdP ainsi que le graphe
correspondant.
Figure 3.1 Exemple de réseau de Petri avec 3 places, une transition, et 3 jetons : Tous les
arcs ont un poids égal à 1.
= {0,1,2}
= {0}
= {(0,0), (1,0), (0,2)}

Chapitre 3 : Les modèles de spécification
17
Remarque.
Les modèles graphiques des RdP utilisés dans ce chapitre ont été créés par l’outil Tina
téléchargeable gratuitement sur le lien : http://projects.laas.fr/tina//download.php
Règles de base.
– Les relations Place-place, transition-transition ne sont pas permises.
– Une place peut contenir zéro jeton ou plus.
Définition 3.2 (Entrées/Sorties). Si l‘ensemble  contient  places, ces
places sont généralement nommées 0, . . . , . Si l‘ensemble  contient  transitions,
ces transitions sont généralement nommées 0,...,. Une place  est une place de
sortie pour une transition  si  (,) > 0 ( est en aval de ). La fonction
d‘incidence arrière  est défini par   ×  . Une place  est une place
d‘entrée pour une transition  si é (,) > 0 ( est en amont de ). La fonction
d‘incidence avant é est défini par é ×  
D‘autres notations
  est l‘ensemble des prédécesseurs de .
  est l‘ensemble des successeurs de .
Représentations de RDP.
Représentation graphique
Dans une telle représentation, et comme nous avons déjà cité dans la définition 3.1,
nous utilisons les formes exposées dans la figure 3.2 pour représenter un RdP
graphiquement.
Figure 3.2. la représentation graphique d‘un RdP
Représentation matricielle.
Un RdP peut être représenté mathématiquement par une matrice dite d‘incidence qui
est calculée à partir les matrices d‘incidences avant et arrière.
Matrice d‘incidence avant, elle est aussi appelée la matrice Pré ou la matrice
d‘entrée , elle comporte  lignes (nombre de places), et colonnes (nombre de
transitions). Les valeurs correspondent aux poids des arcs entrants aux transitions.
Matrice d‘incidence arrière, elle est aussi appelée la matrice  ou la matrice de
sortie , elle comporte  lignes (nombre de places), et  colonnes (nombre de
transitions). Les valeurs correspondent aux poids des arcs sortants depuis les
transitions.
Place
Place marquée par 2
jetons
Arc
Transition
Poids de l’arc est 3
3

Chapitre 3 : Les modèles de spécification
18
Matrice d'incidence, la matrice d‘incidence  est calculée à partir des deux matrices
d‘incidence  et  telle que  =   
Remarque
La matrice d‘incidence  est indépendante du marquage.
Exemple.
Figure 3.3 Matrices d‘incidence
Définition 3.3 (Marquage). Le marquage d‘une place dans un RdP est le
nombre de jetons qu‘elle contient. Le marquage des places du RdP de la figure 3.3
est  (0) = 2,  (1) = 1 et  (2) = 0.
Le marquage d‘un RdP (,,,) est une fonction :    qui attribut à chaque
place    un nombre () de jetons. Le marquage du RDP de la figure 3.3 est
= 2. 0, 1. 1, 0. 2= 2. 0, 1.
Franchissement.
Soit  un RdP, m et m‘ sont deux marquages de R tel que le franchissement de  à
partir du marquage  donne le marquage . Nous notons [>, nous pouvons
calculer le nouveau marquage par la formule suivante :
() = () + (,)  é(,) = () + (,)
Définition 3.4 (Franchissabilité). Quand toutes les places qui pointent
vers une transition contiennent un nombre adéquat de jetons, la transition est dite
tirable ou franchissable et elle peut tirer. Le tir de cette transition entraine la
consommation des jetons depuis toutes ses places d‘entrées la déposition de jetons
dans toutes ses places de sortie.
Dans un RdP, une transition    est franchissable pour un marquage :    si
pour tout     , () > 0.
Exercice 3.1.
Soit R un RDP avec  = (0; 1; 2; 3; 4) et  = (0; 1; 2; 3; 4), avec le
marquage initial 0=0. Soient les matrices d‘incidences é et  ci-dessous:
0
1
1
2
1
0
0
p
p
p
t
pré 
1
0
0
2
1
0
0
p
p
p
t
post 
C
1
1
1
2
1
0
0
p
p
p
t



Chapitre 3 : Les modèles de spécification
19
 Dessiner le RdP correspondant avec le marquage initial 0
Définition 3.5 (Tir de transitions). Pour un RdP (,,,), soit
:   le marquage en cours. Une transition    peut tirer si elle est
franchissable à partir de .
Le franchissement de  produit un nouveau marquage :   où
  ,() = ()  (,) + (,)
Le franchissement de  est noté : [>.
Définition 3.6 (Transition tirée). Une transition franchissable peut être
tirée. Quand elle est tirée, elle consomme un nombre de jetons égal au poids des arcs
qui la relie avec chacune de ses places d‘entrées, et elle ajoute un nombre de jeton
égal au poids des arcs qui la relie à chacune de ses places de sortie.
Pour le RDP de la figure 2, le tir de la transition 0 consomme le jeton de la place 0 et
produit un jeton dans la place 1. Dans le nouvel état du système, la transition 1 est
franchissable, et elle peut être tirée,….etc.
Figure 3.4 Marquage et franchissement de transition
……
.
0(0) = 1
0(1) = 0
0(2) = 0
1(0) = 1 1 + 0 = 0
1(1) = 0 0 + 1 = 1
1(2) = 0 0 + 0 = 0
0
1
0
2(0) = 0 0 + 1 = 1
2(1) = 1 1 + 0 = 0
2(2) = 0 0 + 1 = 1
00100
00010
10001
00001
01000
5
4
3
2
1
54321
p
p
p
p
p
ttttt
post 
11000
01000
00100
00010
00001
5
4
3
2
1
54321
p
p
p
p
p
ttttt
pré 

Chapitre 3 : Les modèles de spécification
20
Définition 3.7 (Graphe d'accessibilité). Le graphe d'accessibilité d'un
réseau marqué <,0> est représenté par l‘ensemble des marquages accessibles.
,0 se définit comme suit: 0  et si   et [>  alors  .
L‘ensemble  définit l‘ensemble des marquages accessibles à partir de 0.
Si l‘ensemble de tout les marquages accessible à partir de 0 est fini, le graphe
d‘accessibilité du réseau est aussi fini et il est défini par un graphe de nœuds égaux au
nombre d‘élément de (,0). Dans le graphe, il existe un arc entre deux nœuds 
et , étiqueté par la transition , si et seulement si [> .
Dans le cas où le graphe d‘accessibilité est infini on procède à la construction d'une
abstraction finie du graphe d'accessibilité permettant de représenter les parties
infinies du graphe d'accessibilité, où certaines places deviennent non bornées d'une
manière finie. Ce nouveau graphe s‘appelle le graphe de couverture.
Définition 3.8 (Graphe de couverture). Un graphe de couverture est un
graphe ayant un nombre de nœuds égal à un nombre fini de marquages accessibles.
Dans un tel graphe, il existe un arc reliant les nœuds  et , étiqueté par la
transition  si et seulement si  est tirable à partir de  et un marquage couvert par
 est accessible. On utilise le symbole ω dans les nœuds pouvant contenir un
nombre non déterminé de jetons.
Règles de construction. Pour construire un graphe de couverture il faut
suivre les étapes suivantes :
1. Calculer le graphe d'accessibilité
2. Appliquer la seule modification suivante
3. Pour chaque marquage  calculé et pour chaque marquage   sur un
chemin qui commence du marquage initial 0 jusqu‘à , Si >=  alors
mettre () = , pour tout    avec >= 
Propriétés.
 Le graphe de couverture n‘est pas unique, sa construction dépend de la
transition que nous tirons en premier, c‘est le cas où plus d'une transition peut
être activée. Ou dans le cas où des états intermédiaires sont calculés dans un
ordre différent, ce qui peut entraîner la génération de graphes de couverture
différents.
 D‘une manière générale, le graphe de couverture ne permet pas de répondre à
des questions sur l‘accessibilité d‘un marquage, et la vivacité du réseau. Mais il
peut être utilisé pour analyser certaines propriétés telles que la répétition et la
bornitude, le symbole ω introduit alors une perte d‘information.
 Des réseaux ayant des comportements différents peuvent avoir le même
graphe de couverture.
 Plusieurs réseaux de Petri peuvent avoir le même graphe de couverture (à
cause de l'abstraction)
 Chaque exécution d'un réseau de Petri peut être imité dans le graphe de
couverture (mais pas l'inverse).

Chapitre 3 : Les modèles de spécification
21
Exemple. Le graphe d‘accessibilité et le graphe de couverture correspondants au RdP
de l‘exemple 1 sont représentés ci-dessous, voir la figure 3.5.
Figure 3.5. Le graphe de couverture
Définition 3.9 (Concurrence). Deux transitions sont prêtes à tirer dans un
état donné, et le tir de l‘une d‘elles n‘empêche pas le tir de l‘autre. On dit dans ce cas
que les deux transitions sont concurrentes.
Définition 3.10 (Conflit). Deux transitions sont prêtes à tirer dans un état
donné, mais le tir de l‘une d‘elles empêche le tir de l‘autre
– Il n‘existe pas une politique pour résoudre un conflit, dans une telle situation un
processus peut ne plus avoir une ressource ce qui est appelé le problème de la
famine ou (starvation)
Définition 3.11 (Non-déterminisme). Quand 2 transitions sont à la fois
franchissables et on a à tirer qu‘une seule alors on est devant une situation dite de
non-déterminisme.
Définition 3.12 (Conflit). On dit qu‘il y a un conflit quand deux transitions se
battent pour le même jeton.
Définition 3.13 (Conflit structurel). Deux transitions 1 et 2 sont en
conflit structurel si et seulement si elles ont au moins une place d‘entrée en commun
  ,1 .  ,20
Définition 3.14 (Conflit effectif). Deux transitions sont en conflit effectif
pour un marquage  si et seulement si 1 et 2 sont en conflit structurel et que
 (,1)
 (,2)
Définition 3.15 (Parallélisme structurel). Deux transitions t1 et t2 sont
parallèles structurellement si elles n‘ont donc aucune place d‘entrée commune (le
produit scalaire de leurs vecteurs Pré est nul)
1
2
1,3
1,2.3
2,3
1
2
1
1
2,2.3…….
.
3
[]
3
3
1
2
1,.3
2,.3
1
2
.3
2
1
3
1

Chapitre 3 : Les modèles de spécification
22
(,1)×,2= 0
Définition 3.16 (Parallélisme effectif). Deux transitions 1 et 2 sont
effectivement parallèles pour un marquage donné m si et seulement si elles sont
1. Structurellement parallèles, et
2.  (,1)
3.  (,2)
Exercice 3.2.
Soit le RdP ci-dessous, étudier le conflit et le parallélisme.
Propriétés standards des RdP
Définition 3.17 (Bornitude). La bornitude d‘une place du réseau caractérise
la possibilité pour cette place d‘accumuler une quantité bornée ou pas de jetons au
cours de l‘évolution d‘un réseau.
 Une place p d'un RDP est k-bornée si et seulement si  ne contient pas plus de
 jetons dans tout marquage du graphe de couverture.
    é    (,0), () 
 Un réseau marqué est borné si toutes ses places sont bornées.
 Les réseaux 1-bornés sont appelés des réseaux saufs.
Définition 3.18 (Pseudo vivacité). On dit que <,0> est pseudo-vivant
si pour tout  appartenant au graphe de marquage <,0> il existe toujours une
transition qui puisse être franchie
 (,0),     [
Définition 3.19 (Quasi-vivacité). La quasi-vivacité d‘une transition
signifie que depuis le marquage initial, cette transition peut être franchie au moins
une fois.
        (,0)    [
1. Un réseau est quasi-vivant si toutes ses transitions le sont.
Définition 3.20 (Vivacité d’une transition). La vivacité d‘une
transition exprime le fait que quelque soit l‘évolution du réseau à partir du marquage

Chapitre 3 : Les modèles de spécification
23
initial, le franchissement à terme de cette transition est toujours possible, c.à.d. pour
un réseau marqué (,0)
       (,0),       .
Définition 3.21 (Vivacité d’un réseau). Un réseau est vivant si toutes ses
transitions le sont, c.à.d. pour un réseau marqué (,0)
 (,0),  , (,0)   [ 
Exercice 3.3.
Soit le RDP suivant, étudier la quasi-vivacité, la pseudo-vivacité et la vivacité.
Définition 3.22 (Réversibilité). Un RdP  est réversible si, pour chaque
marquage  accessible depuis 0, 0 est accessible depuis .
Définition 3.23 (Place invariante, transition invariante). Une
place invariante ou P-invariante est une solution à l‘équation yT. C = 0, où  est la
matrice d‘incidence et est un vecteur d‘entiers. La propriété caractérise un
ensemble de places dont la somme des jetons qu‘elles contiennent reste constante
dans tous les marquages accessibles. La combinaison linéaire de p-invariantes est
aussi p-invariante.
Une transition invariante ou T-invariante est la solution à l‘équation  .  = 0, telle
que  est la matrice d‘incidences et y est un vecteur d‘entiers non-négatifs. La
propriété essentielle d‘un T-invariante est donc que si le marquage initial permet le
franchissement d‘une séquence de transitions « s » alors on revient au marquage
initial. La combinaison linéaire de T-invariantes est aussi T-invariante.
Définition 3.24 (Pureté). Un réseau de Petri est dit pur si et seulement s‘il
n‘existe pas de transition ayant une place d‘entrée qui est aussi place de sortie. sinon,
il est impur
       ,     (,). (,) = 0

Chapitre 3 : Les modèles de spécification
24
Exemple
Définition 3.25 (Blocage). Un marquage qui ne sensibilise aucune transition
est un marquage mort ou état de blocage (deadlock state). L‘absence de blocage
implique seulement que le réseau a toujours la possibilité d‘évoluer. Un réseau vivant
est un réseau sans blocage.
 ,        ,
Exemple
Définition 3.26 (RDP répétitif). Un RDP est dis répétitif s‘il existe un
marquage initial 0 et une séquence de transitions  franchissables tel que chaque
transition apparaît un nombre illimité de fois.
Autres propriétés
 Un RDP est dit conforme s‘il est vivant et sauf.
 Une transition puits est une transition qui ne comporte aucune place de sortie.
 Une transition morte est une transition qui ne figure pas dans le graphe de
couverture.
Définition 3.27 (Réseau à capacité). Dans un RDP, une capacité est un
nombre entier strictement positif affecté à une place ou plus du réseau. Un RdP à
capacités est un RdP dans lequel une/des capacité(s) est /sont associée (s) à/aux une
place /des places. Le franchissement d‘une transition d‘entrée d‘une place  dont la
capacité est () n‘est possible que si le franchissement ne conduit pas à un
nombre de jetons dans  qui est plus grand que ().
 é   = 0 1  
é (1, 1) . (1, 1) = 1.1 0     

Chapitre 3 : Les modèles de spécification
25
Suppression d‘une capacité : On peut supprimer la capacité de la place  en ajoutant
une place 1 qui est place d‘entrée de  et place de sortie de  ; la capacité de la place
 est alors limitée par le fonctionnement du RdP.
Exercice 3.4 (récapitulatif).
I. Considérant le réseau de Petri ci-dessous :
a. Construire le graphe de couverture correspondant.
b. Déterminer pour chaque transition du réseau si elle est morte, et étudier la
bornitude des places.
c. Étudier la pseudo vivacité, la quasi vivacité et la vivacité du RDP.
d. Est-il pur, conforme et sans blocage ?
II. On suppose que le dépôt possède une capacité limitée à 10 produits. Proposer une
modification du modèle où la capacité du dépôt soit limitée par le fonctionnement
du réseau.
Modélisation des systèmes concurrents par les réseaux de
Petri.
Rôle d'un jeton, un jeton peut designer :
 Un objet physique comme un produit, une pièce, un médicament, ou une
personne, etc.
 Un objet informationnel comme un message, un signal, ou un rapport;
 Un indicateur d‘état tel qu‘un indicateur de l'état d‘un processus ou l'état d'un
objet, comme un feu de circulation (allumé, éteint); (machine libre, occupée);
 Un indicateur d'une condition telle que la présence d'un jeton indique si une
condition est vérifiée.
Rôle d'une place, une place peut designer :
 Un moyen de communication comme une ligne téléphonique, un
intermédiaire ou un réseau de communication;
 Un tampon comme un dépôt, une file d'attente ;
 Une localisation géographique, par exemple une place dans un entrepôt, dans
un bureau ou dans un hôpital;
 Un état possible ou un état à condition comme l'étage où un ascenseur est
arrêté.

Chapitre 3 : Les modèles de spécification
26
Rôle d'une transition, une transition peut designer :
 Un événement tel que le début d‘une opération, l‘arrivée d'un patient, un
changement des saisons, ou le changement d'un feu de circulation du rouge au
vert;
 Une transformation d'un objet comme la réparation d'un produit, la mise à
jour une base de données;
 Un transport d'objet, à titre d‘exemple le transport de marchandises ou l'envoi
d'un fichier.
Extension des RdP. Les RdP classiques sont trop abstraits, Ils peuvent être
incapables d'exprimer le comportement adéquat d‘un système parallèle d‘où vient la
nécessité de les étendre par l‘introduction des types, du temps ou de hiérarchie.
Réseaux de Petri Colorés (RdPC).
Dans un RdPC, des couleurs sont associées aux jetons et aux places. Ces couleurs
correspondent aux types de données. La relation entre la production et la
consommation des jetons doit être spécifiée, à savoir la valeur d'un jeton produit doit
être en rapport avec les valeurs de jetons consommés.
Exemple.
La valeur du jeton produit en place somme est la somme des valeurs (Val) des jetons
consommés.
Réseaux de Petri temporels (RdPT).
Dans un RdPCT, chaque jeton a un timestamp (délai) qui représente la durée
d'indisponibilité du jeton pour la validation des transitions.
 Le temps de franchissement d‘une transition est le maximum des timestamps
des jetons à être consommés. S‘il ya plusieurs jetons dans une seule place, les
plus précoces sont consommés en premier.
 Une transition se franchit en premier par les jetons ayant le plus petit
timestamp. Les transitions sont impatientes, à savoir, elles tirent dès qu‗elles
le peuvent.
 Les jetons produits peuvent avoir du retard. Le timestamp d'un jeton produit
est égal au timestamp des jetons consommés plus le retard.
0
Ajout
Somme
Val
3
2

Chapitre 3 : Les modèles de spécification
27
Exemple.
Transition commencer est tirable dans le temps t=2 unités : 2=
max{0,min{2,3}}.
Les jetons de la place Occupé prennent un retard égal à 3 unités de temps @+3.
Le timestamp du jeton produit dans la place Occupé est égal 2+3=5.
A retenir.
– Les réseaux de Petri (RDP) constituent à la fois un modèle de spécification de
parallélisme ainsi qu‘un modèle sémantique de parallélisme. Ils représentent
un outil vigoureux pour modéliser des systèmes parallèles/concurrents.
– Habituellement, une transition spécifie un événement ou une action et son
franchissement spécifie une occurrence de l‘événement ou une exécution de
l‘action.
– La présence de jetons dans une place, dénote l‘existence d‘une condition. Par
exemple, une place peut modéliser une ressource générique. Tandis que les
jetons associés dénotent le nombre d‘instances disponibles de la ressource.
– Une transition est tirable lorsque toutes les pré-conditions d‘exécution d‘une
action ou d‘une occurrence d‘un événement sont satisfaites.
– Les RDP classiques sont trop abstraits. Ils peuvent être incapables d'exprimer
le comportement adéquat d‘un SC d‘où venait la nécessité de les enrichir par
les types de données (couleurs) et crées ce qu‘on appelle les RDP colorés, les
enrichir par le facteur temporel et là on distingue les RDP temporels.
Terminer
Occupé
Attente
3
Libre
Commencer
Fin
@+3
@+0
@+0
5
Terminer
Occupé
Attente
3
2
Libre
Commencer
Fin
@+3
@+0
@+0
0

Chapitre 3 : Les modèles de spécification
28
II. Les Systèmes de transitions
Introduction.
Les systèmes de transitions représentent l‘un des formalismes de spécification des
systèmes parallèles les plus utilisés, ils ont été introduits par Keller en 1976 [Keller
76]. Tout d‘abord, un système de transitions est un graphe orienté de nœuds et d‘arcs.
Les nœuds représentent les états du système tandis que les arcs représentent des
transitions. Dans ce chapitre on aborde les notions de base des systèmes de
transitions ainsi que les systèmes de transitions étiquetés mettant l‘accent sur les
notions d‘équivalence et de bisimulation.
Définition 3.28 (système de transitions). Un système de transitions
() est un modèle de graphe où les nœuds représentent des états, et les arcs
représentent des transitions du modèle. L‘un des états est désigné pour être l‘état
initial système.
Formellement, un système de transitions est un triplet (,0,) où  est un
ensemble fini d‘états, 0 est l‘état initial,   × une relation de transition. On
note une transition reliant un état de départ 1 à un état d‘arrivé 2 par 1 2.
Exemples d‘états:
 La couleur courante d'un panneau de signalisation.
 Les valeurs actuelles de toutes les variables d‘un programme.
Exemples de transitions:
 Le changement d'état d‘un feu de circulation d'une couleur à une autre.
 L'exécution d'une instruction de programme.
Définition 3.29 (Systèmes de transitions étiquetés). Un système de
transitions Étiquetées (STE) ou labeled transition systems (LTS) est un ST où soit les
transitions sont nommées, dans ce cas on parle des STE basés événement qui sont
communément appelés machines de Mealy. Soit les états sont nommés, dans ce cas
on parle des STE basés états qui sont communément appelés machines de Moore.
Dans le cas où les transitions et les états sont étiquetés à la fois on parle des systèmes
de transitions doublement étiquetés (ST2E). L‘ensemble des étiquettes représentent
les noms d‘actions que le système peut exécuter (actions A).
0
.
1


Chapitre 3 : Les modèles de spécification
29
Formellement, un système de transitions est un quadruplet (,0,,) où  est un
ensemble fini d‘états, 0 est l‘état initial,   × une relation de transition et A est
l‘ensemble des étiquettes.
Exemple.
Figure 3.6 la Représentation graphique d‘un STE
La figure 3.6 donne une représentation graphique d‘un STE décrivant le
comportement d‘un distributeur de café qui peut recevoir la ?Monnaie et servir
le !Café.
Types d’actions. Dans un STE on distingue 3 types d‘actions : action d‘entrée,
action de sortie et action interne.
Action d‘entrée. Une action d‘entrée représente la réception d'un message par le
système. L‘ensemble des actions d‘entrée au système est noté , il contient toutes les
actions reçues par le système. Par exemple, (?Monnaie) est une action d‘entrée pour
un distributeur de boissons.
Action de Sortie. Une action de sortie représente l‘émission d'un message par le
système, l‘ensemble des actions de sortie au système est noté O, il contient toutes les
actions émises par le système. Par exemple, (!Cafe) est une action de sortie pour un
distributeur de boissons.
Action interne. Une action interne est une action non observable à partie de
l‘environnement du système, elle est notée par τ et elle permet d'abstraire un calcul
interne ou de représenter un choix interne.
Remarque. Ensemble des actions d‘un STE est  =     {}.
Définition 3.30 (Chemin). Un chemin  est une suite (finie ou infinie) de
transitions 
 +1 telle que .  0  . ( 
 +1). On note une telle
suite :
=11
 22
 3
 +1 
1
0
?Monnais
!Café

2
1
0
.
1


Chapitre 3 : Les modèles de spécification
30
Définition 3.31 (exécution). Une exécution est un chemin débutant à l'état
initial.
Définition 3.32 (trace). Une trace est une suite d‘actions d'un chemin. On
note par () = 1.2.+1. . ., la trace du chemin . La longueur d‘un chemin ,
notée par  est le nombre de transitions, éventuellement infini, qu‘il contient.
Exemple. ?Monnaie τ !Café
Définition 3.33 (Trace observable). Une trace observable est la suite
d‘actions observables d'un chemin. Elle est composée d‘actions d‘entrée et de sortie
seulement.
Exemple. ?Montant !Café
Définition 3.34 (Arbre d'exécution). L'arbre d'exécution () d'un
système de transitions est défini inductivement de la façon suivante :
 0 est la racine de ()
 Si  est un nœud de () et si   , alors  est un fils de .
Propriétés.
 Un arbre d‘exécution déplit le système de transitions à partir de l'état initial
 Il contient toutes les exécutions du système de transitions
 Il est généralement infini (sauf si toutes les exécutions sont finies)
Définition 3.35 (STE avec variables). Un STE avec variables est
composé de :
 Un ensemble fini d‘états ;
 Un état initial 0;
 Un alphabet (fini) d'actions A ;
 Un ensemble (fini) de variables typées V ;
 Une relation de transition    × ×  × × .
Où :
() est l'ensemble des conditions portant sur les variables de V.
Et () est l'ensemble des fonctions de mise à jour des variables de V.
Exemple.
Pour l‘exemple ci-dessus, X>10 est une condition portant sur la variable X, et X :=0
est une fonction de mise à jour de X.
Synchronisation.


>10 , ! , := 0

Chapitre 3 : Les modèles de spécification
31
Synchronisation par message. Il s‘agit de se synchroniser sur deux actions la
première s‘agit de l‘émission d‘un message !m et la deuxième s‘agit de la réception du
message ?m.
Synchronisation par variables partagées. La synchronisation n‘est permise entre deux
entités E1 et E2 que lorsque les conditions sur les variables qu‘elles partagent sont
vérifiées.
Définition 3.36 (Équivalence de traces). Deux systèmes de transitions
 = (,0,,) et  = (,0,, ) sont traces equivalents s‘ils possèdent les
mêmes traces : () = ().
Exemple.
Les systèmes ci-dessous sont ils traces-équivalents ?
Tr(P)={?Monnaie !Cafe, ?Monnaie !The}
Tr ()={?Monnaie !Cafe, ?Monnaie !The}
() = (). Alors on dit que les systèmes P et  sont traces équivalents.
Définition 3.37 (Équivalence de traces observables). Deux
systèmes de transitions sont équivalents sur les traces observables si et seulement
s‘ils admettent le même ensemble de traces observables.
Exemple.
Tr-Obs (P)={?Monnaie !Cafe, ?Monnaie !The}
Tr-Obs ()={?Monnaie !Cafe, ?Monnaie !The}
  =  (). Alors on dit que les systèmes  et  sont équivalents
dans les traces observables.
?Monnaie
!Cafe
!The
τ
!The
?Monnaie
?Monnaie
P

!Cafe
τ
?Monnaie
!Cafe
!The
!Cafe
!The
?Monnaie
?Monnaie
P


Chapitre 3 : Les modèles de spécification
32
Définition 3.38 (Bisimulation). Deux systèmes de transitions  =
(,0,,) et  = (,0,, ) sont bisimilaires si et seulement s‘il existe une
relation  telle que :
 0  0
 pour tout état 1, 2 tels que 12,
 pour toute transition 1  1, il existe une transition 2   2 et 1 2
 pour toute transition2  2, il existe une transition 1 1 et 1  2
Intuitivement : À partir de l'état initial, en chaque état,  peut mimer chaque
transition de  dans l'état correspondant et inversement.
Propriétés.
 Un système de transitions et son arbre d'exécution sont bisimilaires.
 Deux systèmes de transitions bisimilaires sont traces-équivalents.
 Mais : Deux systèmes de transitions traces-équivalents ne sont pas
nécessairement bisimilaires.
 Deux systèmes de transitions qui ne sont pas traces-équivalents ne seront
pas non plus bisimilaires.
Définition 3.39 (Bisimulation faible vs forte). Deux systèmes de
transitions  et  sont faiblement bisimilaires,   , si à partir de l'état initial, en
chaque état accessible par une action observable,  peut mimer chaque action
observable de  et inversement.
Deux systèmes de transitions  et  sont fortement bisimilaires, ~, si à partir de
l'état initial, en chaque état accessible par une action observable /non observable, P
peut mimer chaque action observable/non observable de  et inversement.
Exemple.
-P et  ne sont pas ni faiblement ni fortement bissimilaires
Justification :
P (exécutant ?Monnaie) peut se transformer soit en !The soit en !Cafe.
 (exécutant ?Monnaie) peut se transformer en τ; !The ;stop seulement ou en τ ; !Cafe ;stop
seulement selon l‘action ?Monnaie choisi en premier;
Ensuite
P (exécutant !Cafe) peut se transformer dans le comportement stop et là  peut ne pas
être capable d’exécuter l’action !Cafe et cela dépend du choix de l‘action interne τ à
exécuter.
?Monnaie
!Cafe
!The
τ
!The
?Monnaie
?Monnaie
P

!Cafe
τ

Chapitre 3 : Les modèles de spécification
33
Remarque.
La bisimulation permet de montrer qu'un produit de sous-systèmes est équivalent au
système global. Ce qui aide dans la vérification des propriétés du système.
Exercice 3.5.
Soit les STE P et  suivant, étudier la trace équivalence, et la bisimulation.
A retenir.
– Les systèmes de transitions étiquetées représentent un modèle de description de
comportement des SCs. Ils servent à modéliser n‘importe quel système discret
dynamique.
– Graphe où les nœuds représentent des états, et les arcs représentent des
transitions du modèle.
– La bisimulation est la capacité de deux STE à mimer chacun l‘autre.
1
3
4
5
2







1
3
2


Chapitre 3 : Les modèles de spécification
34
III. Modèles des Algèbres de Processus
Basic et Full LOTOS
Introduction.
L‘algèbre de processus (Process algebras ou process calculi) est une famille de
langages utilisés pour décrire les systèmes concurrents réactifs dont les plus célèbres
sont : CCS (Calculus of Communicating Systems) développé par Milner en 1980
[Milner 80], CSP (Communicating Sequential Systems) développé par Hoar en 1985
[Hoare 85] et ACP (Algebra of Communicating Processes) développé par Bergstra et
Klop [Bergstra et Klop 84] en 1984. Le principe de base de ces langages est de décrire
le comportement des processus pouvant être créé à partir de sous-processus en
utilisant un nombre de combinateurs. Ici l‘ensemble des processus décrivent le
comportement du système.
Dans le présent chapitre on aborde le langage LOTOS qui est un langage algébrique
de spécification qui utilise le formalisme des types de données abstraits (abstract data
types, ADT) en s'inspirant largement du langage ActOne, et un langage de l‘algèbre de
processus (CSP ou CCS). Le chapitre se focalise sur la spécification des systèmes
concurrents en insistant sur les aspects communication et synchronisation.
Définition 3.40 (Langage LOTOS). LOTOS pour Language Of Temporal
Ordering Specification est un langage formel de spécification qui permet de décrire le
comportement d‘un composant d‘un système interactif en décrivant ses propriétés
importantes de façon abstraite et sans détails inutiles. En LOTOS, un système
concurrent est représenté par un ensemble de processus communicants.
Définition 3.41 (Basic LOTOS). Dans sa version basique, seuls les
comportements sont spécifiés, pas de spécification de données. Le comportement
d'un processus détermine, à tout moment, les actions possibles à exécuter.
Définition 3.42 (Processus). En LOTOS, un processus est considéré comme
une boite noire capable d'interagir avec son environnement et d'effectuer des actions
(internes, externes). Les événements sont produits par des « points d'interaction »
appelés portes. L'environnement d'un processus est composé des autres processus
LOTOS, de l'utilisateur, ou d'autres systèmes externes à LOTOS. On définit un
processus en spécifiant son comportement qui est représenté par une séquence
d‘actions qui peuvent se produire. Ci-dessous la syntaxe de définition d‘un processus.
process <process_id> <parameter_part> :=
<behaviour_expression>
where
local-definitions
endproc
Exemple illustratif.
Nous utilisons l‘exemple du système distributeur de boissons tout au long du cours.

Chapitre 3 : Les modèles de spécification
35
process Distributeur [Monnaie, Cafe] :=
Monnaie; Cafe; stop
endproc
Définition 3.43 (Expression de comportement). Une expression de
comportement est créée en appliquant un opérateur du langage à d‘autres
expressions de comportement. Elle peut contenir une/des instance(s) d‘autres
processus qui sont définis à l‘intérieur de la clause Where.
Syntaxe.
En Lotos les lettres majuscules et minuscules sont identiques. Les identificateurs sont
composés de lettres, de chiffres et du caractère ‗_‗. Dans le reste du document nous
utilisons les identificateurs B1, B2, etc., pour désigner les expressions de
comportements. 1,2, etc., pour désigner les noms de ports, P, Q, etc., pour désigner
les noms de processus.
Types d’action. On peut distinguer 2 types d‘actions.
Actions internes. Elles sont appelées également les actions silencieuses. Ce sont les
actions qu'un processus peut effectuer de façon interne et indépendante : une action
interne est notée par i.
Actions de synchronisation. Ce sont celles qui nécessitent une synchronisation avec
l'environnement pour être effectuées : elles sont alors offertes sur des points de
synchronisation appelés portes (gates).
Opérateurs du langage.
Processus élémentaire. Stop est le processus qui ne peut rien faire. Il permet de
représenter un comportement où aucun événement ne sera jamais observé. Comme il
peut être utilisé pour exprimer qu‘un processus a terminé son exécution ou encore
pour exprimer un état d‘inter-blocage ‗deadlock‘. Alors, il désigne une terminaison
sans succès d‘une exécution.
Terminaison avec succès. Le processus exit est un processus qui ne fait rien et qui
retourne une terminaison avec succès. Il offre un événement spécial ∂ et se
transforme en stop. ∂ ce n‘est pas un évènement qui peut être explicitement offert;
Exemple.
process Inaction [a, b] :=
stop
endproc
préfixage (séquence) noté par « ; », exemple a ; B où a est une action atomique et B
est une expression de comportement.

Chapitre 3 : Les modèles de spécification
36
Exemple.
process Distributeur [Monnaie, Cafe] :=
Monnaie; Cafe; stop
endproc
Ici le distributeur ne distribue qu‘un seul type de boissons qui est le café alors le
processus exécute l‘action Monnaie ensuite l‘action Cafe avant d‘exécuter un stop.
Remarque : syntaxiquement, ―;‖ ne peut pas être précédé par une expression de
comportements mais plutôt une action. Par exemple :
(Cafe ; The [ ] The ; Cafe) ; Change ; stop n‘est pas une expression de comportement
correcte.
Choix non déterministe. Le choix entre deux expressions de comportement B1 et B2
est noté par B1 [] B2 tel que la nouvelle expression de comportement B1 [] B2 qui se
comporte comme B1 ou comme B2 selon le comportement de l'environnement du
processus ou de façon non-déterministe. Si l'environnement offre l'action initiale de
B1, alors B1 est sélectionnée et si l'environnement offre l'action initiale de B2, alors
B2 est sélectionnée.
Exemple.
Ici, notre distibuteur offre deux types de boissons, à savoir le café (action Cafe) et le
thé (action The). Alors, le processus Drink_Choix offre au client la possibilité de
choisir leur boisson.
process Drink_Choix [Cafe, The] :=
Cafe ; stop
[]
The ; stop
endproc
Propriétés. L‘opérateur de choix non déterministe est :
 Commutatif : B1 [] B2 = B2 [] B1
 Associatif : B [] B = B
 Idempotent: B1 [] (B2 [] B3) = (B1 [] B2) [] B3
Instanciation de processus. Un processus peut instancier un autre processus comme
il peut instancier lui même. L‘instanciation en Lotos ressemble à l‘appel d‘une
procédure ou une fonction ou encore à un appel récursif dans un langage
algorithmique.
Exemple. Ici, nous revenons à l‘exemple du distributeur de café qui après avoir
exécuté les deux actions Monnaie et Cafe séquentiellement il instancie lui-même par
un appel récursif.
process Distributeur [Monnaie, Cafe] :=
Monnaie; Cafe; Distributeur [Monnaie, Cafe]
endproc

Chapitre 3 : Les modèles de spécification
37
Parallélisme.
En Lotos nous distinguons 3 opérateurs exprimant les différentes situations de
parallélisme d‘actions qui sont : le parallélisme sans synchronisation, le parallélisme
avec synchronisation totale et le parallélisme avec synchronisation partielle.
Parallélisme sans synchronisation (Interleaving). L‘opérateur de composition parallèle
avec entrelacement noté ‗|||‘ est utilisé pour exprimer des situations d‘exécution dans
lesquelles les comportements se déroulent de manière complètement indépendante
en parallèle. Nous disons que les événements des deux expressions de comportement
sont entrelacés.
Propriétés.
 L‘opérateur d‘entrelacement est commutatif. B1 ||| B2 = B2 ||| B1
 Il est également associatif. B1 ||| (B2 ||| B3) = (B1 ||| B2) ||| B3
 L‘entrelacement d‘une expression B et le processus stop revient à exécuter
l‘expression B : B ||| stop = B
 Comportments équivalents : (a; B1) ||| (b; B2) = a; (B1 ||| (b; B2)) [] b; ((a; B1)
||| B2)
Exemple.
Ici nous avons modélisé le comportement du distributeur de boissons et 2 clients
simultanément, et comme le distributeur ne peut servir qu‘un client à la fois, les deux
clients doivent synchroniser sans interaction avec le distributeur sur toutes les portes
(Monnaie, Cafe, The).
process Distributeur_2Clients [Monnaie, Cafe, The] :=
Monnaie; Cafe; stop ||| Monnaie; The; stop
endproc
Exercice 3.6.
Donner une expression équivalente à chacune des expressions de comportement
suivantes
1. b ; c ; stop ||| c ; stop.
2. a ; b ; c ; stop || c ; a ; b ; stop.
3. a; b; c; stop||a; b; c; stop.
Parallélisme avec synchronisation totale (Full Synchronization). L‘opérateur de
composition parallèle de synchronisation total noté || est utilisé quand les
événements nécessitent de se synchroniser; dans ce cas les événements qui occurrent
dans les deux expressions de comportement sont obligés de se synchroniser. Les
événements établissent un RDV et dès que le RDV est assuré ils s‘exécutent
simultanément.

Chapitre 3 : Les modèles de spécification
38
Exemple.
Dans le présent exemple, nous avons modélisé le comportement du distributeur de
boissons et d‘un client où ils synchronisent sur toutes les portes d‘interactions
(Monnaie, Cafe, The).
process Distributeur_Client [Monnaie, Cafe] :=
Monnaie; Cafe; stop || Monnaie; Cafe; stop
endproc
Ce qui est équivalent à
process Distributer_Client [Monnaie, Cafe] :=
Monnaie; Cafe; stop
endproc
Remarque.
a ; b ; c ; stop || c ; a ; b ; stop est équivalent à stop (deadlock).
Parallélisme avec synchronisation partielle (Partial Synchronization). Dans le cas où
certains événements seulement nécessitent une synchronisation on parle d‘une
synchronisation partielle et on la note par |[ 1, ..,]|. Ici les actions 1, .., sont les
actions de synchronisation. Soit B1 et B2 sont des expressions de comportement.
l‘expression B1 |[ 1, ..,]| B2 se comporte en synchronisant chaque action ai de B1
avec l'action ai de B2. Ceci dit que chaque ai de B1 est exécutée simultanément avec
l'action ai de B2 (et inversement).
Propriétés.
 B1 |[]| B2 = B1 ||| B2
 B1 |[L]| B2 = B2 |[L]| B1
 (a; B1)|[L]| (b; B2) = a; (B1 |[L]| (b; B2)) [] b; ((a; B1)|[L]| B2)si a, b  L
 (a; B1) |[L]| (b; B2) = stop a, b  L
Exemple.
Dans le présent exemple, nous avons modélisé le comportement du distributeur de
boissons et d‘un client qui ne consomme que du café. Alors le distributeur
synchronise avec le client sur les deux actions (Monnaie et Cafe) et ils s‘entrelacent
sur l‘action The.
process Dist_Client [Cafe, The] :=
Monnaie;
( Cafe ; stop [] The ; stop )
|[ Monnaie, Cafe]|
Monnaie; Cafe; stop
endproc

Chapitre 3 : Les modèles de spécification
39
La figure 3.7 résume les différents types de synchronisations.
Figure 3.7 Synchronisation
Masquage (Hiding). LOTOS supporte la décomposition de comportements, c.à.d. les
processus peuvent être décomposés de manière progressive en processus plus simple.
Cependant, il est important que les détails de cette décomposition soient invisibles à
un niveau élevé l‘opérateur ‗hide ... in‘ est utilisé ainsi pour cacher les événements
dits internes au comportement du système.
hide 1, .., in B B est une expression de comportement, 1, ..,sont des actions
offertes par B et cachées à l'environnement de B, ces actions ne peuvent pas se
synchroniser avec des actions de l'environnement. On dit que 1, .., sont internes à
B
Propriétés.
 hide a, b in B = hide a in (hide b in B)
 hide a in a ; B = i ; hide a in B
Exemple.
Ici, après avoir exécuté l‘action MONNAIE, le client fait le choix du boisson à acheter
le système exécute l‘action CHOIX qui est cachée à l‘environnement ensuite le
distributeur sert le boisson selon le choix du client(CAFE;stop []THE;stop ).
process Dist_Client [MONNAIE , CAFE, THE, CHOIX] : =
hide CHOIX in
MONNAIE; CHOIX;
(CAFE;stop [] THE;stop )
endproc
Composition séquentielle. L‘opérateur de composition séquentielle noté par >>
permet la mise en séquence de deux expressions de comportement ou de deux
processus. L‘expression B1>>B2 signifie que B1 est exécutée en premier; quand B1
termine avec succès, on exécute B2. B2 est exécuté si et seulement si B1 termine avec
succès (en exécutant un exit)
11,2,,2
Cas général
Synchronisation partielle
1||2
Cas particulier
Synchronisation totale
1||| 2
Cas particulier
Entrelacement

Chapitre 3 : Les modèles de spécification
40
Remarque : si B1 est composée de plusieurs sous-processus en parallèles, B1 se
termine avec succès si et seulement si tous ses sous-processus se terminent avec
succès.
Propriétés.
 B1 >> (B2 >> B3) = (B1 >> B2) >> B3
 stop >> B = stop
 (a ; B1) >> B2 = a ; (B1 >> B2)
Exemple.
Dans cet exemple le systeme ne se met en attente d‘une nouvelle commande qu‘après
avoir distribué la commande en cours avec succès (exit).
process Dist_Client [MONNAIE, CAFE, THE, CHOIX] : =
hide CHOIX in
MONNAIE; CHOIX;
(CAFE;exit []THE;exit )
>> Dist_Client [MONNAIE , CAFE, THE, CHOIX]
endproc
Interruption. L‘opérateur d‘interruption de processus noté par [> permet à un
processus/expression de comportement d‘interrompre l‘exécution d‘un autre
processus/expression de comportement à tout moment. L‘expression B1 [>B2 signifie
que B1 peut être interrompue à tout moment par B2, et là B2 continue à s'exécuter
sans reprise de B1.
Exercice 3.7.
Donner une expression équivalente à l‘expression de comportement suivante :
– (a; i; b; exit) >> ( (c; stop) [] (d; i; exit) )
Propriétés.
 B1 [> (B2 [> B3) = (B1 [> B2) [> B3
 stop [> B = B
 B [> stop = B
 (a; B1) [> (b; B2) = (a ; B1 [> (b; B2)) [] (b; B2)
Exemple.
Nous supposons dans cet exemple que le distributeur comporte un bouton
d'annulation (interaction CANCEL). Donc le client peut annuler sa commande en
pressant sur le bouton d'annulation.
process Dist_Client [MONNAIE , CAFE, THE, CHOIX, Cancel] : =
hide CHOIX in
MONNAIE; CHOIX;
[> Cancel; stop
endproc

Chapitre 3 : Les modèles de spécification
41
Définition 3.44 (Full LOTOS). Full Lotos est la version du langage enrichis
par la spécification des données. Full LOTOS utilise le sous langage ACT ONE pour le
typage de données, ce qui permet l‘utilisation de variables et des expressions de
valeurs.
Définition 3.45 (Action Full LOTOS). Une action en full LOTOS est
spécifiée par l'identification d'une porte, une liste de valeurs requises (avec
éventuellement des contraintes) ou/et une liste de valeurs soumises aux autres
processus et éventuellement une garde.
Définition 3.46 (Variable LOTOS). En LOTOS, une variable ressemble
aux variables mathématiques. Il s‘agit d‘attacher un nom à une valeur.
Définition 3.47 (Expression de valeur). Une expression de valeur
comporte des constantes, des variables, et des opérations.
Définition 3.48 (Sort). Un sort est un ensemble de valeurs; les sorts
communs en Full LOTOS sont :
 Bool_ Sort: comprend les valeurs booléennes (true, false)
 Int_ Sort comprend les valeurs entières (..., -1, 0, +1, ...)
 Nat0_ Sort comprend les valeurs entières positives ou nul (0, 1, ...)
 Nat_ Sort comprend les valeurs entières positives (1, 2, ...)
Exemple.
L‘action : p ?x: nat !1 [x>=0] attend de l'environnement sur la porte p un entier
positif ou nul, placé dans la variable x, puis émet la valeur 1.
L‘action : p ?x: nat !0 [x<0] attend de l'environnement sur la porte p un entier
négatif, placé dans la variable x, puis émet la valeur 0.
Opérateurs du langage.
Préfixage. Nous l‘avons déjà défini un peu plus haut (voir la définition x), et afin de
l‘expliquer mieux nous présentons un exemple ci-dessous.
a ?x: t ; B : cette expression exprime un comportement qui place dans une variable x
une valeur de type t compatible avec les messages reçus sur la porte a, puis il exécute
une expression de comportement B.
Synchronisation. La synchronisation entre processus peut s‘effectuer si certaines
conditions sont vérifiées. Tout d‘abord, les deux processus communicants doivent
utiliser le même identificateur de porte ; ensuite il faut assurer que les données en
correspondance sont du même type ; et que les contraintes sur les données sont
satisfaites.
Types de synchronisation. Nous distinguons trois types de synchronisation :
Synchronisation par appariement de valeurs, par passage de valeur et la
synchronisation par génération de valeurs.
Synchronisation par appariement de valeurs, dans ce premier cas, la synchronisation
n'a lieu que si les deux valeurs émises par les deux processus sont égales.
Exemple.

Chapitre 3 : Les modèles de spécification
42
Monnaie !v1 peut synchroniser avec Monnaie !v2 si et seulement si : value (v1)=value
(v2).
Synchronisation par passage de valeur (value passing). Ici, la synchronisation n'a lieu que
si identificateur de porte et les données en correspondance ont le même type.
Exemple*.
L‘action Monnaie !5 peut synchroniser avec : Monnaie ?x :nat les données échangées
par les 2portes Monnaie ont le même type.
Synchronisation par génération de valeurs (value generation), dans ce cas la
synchronisation n'a lieu que si les deux variables de réception reçoivent une valeur
identique.
Exemple
Monnaie ?x : nat peut synchroniser avec Monnaie ?y : nat si et seulement si : x=y=v
telle que v est une valeur quelconque de la sorte nat.
Prédicat et garde. Lotos permet d‘associer des conditions aux actions et aux
expressions de comportement. Le rendez-vous n'a lieu sauf si la (les) condition(s)
définie (s) est (sont) satisfaite(s).
Syntaxe.
 g ?x: t [P(x)] : Le prédicat P est associé à l‘action de réception d‘une valeur par
la porte g et qui sera rangée dans la variable x. P(x) impose une restriction sur
les valeurs possibles de x.
 [P(x)] -> B : l‘expression de comportement B est précédée par une garde [P(x)]
->. B ne peut être exécuté que si P(x) est vrai.
Exemple 1.
Monnaie ?x: nat [x>1] ;
Ici, le prédicat [x>1] exige que les valeurs reçues par la porte Monnaie et qui seront
rangées dans la variable x doivent être supérieurs ou égales à 1.
Exemple 2. Revenons à l‘exemple du distributeur de boissons, et nous supposons que
le système ne distribue que du café et qu‘il ne rend pas la monnaie. Alors, Dès qu‘il
reçoit la monnaie par la porte Monnaie il la range dans la variable ?Dinar, et il ne
distribue le café (action CAFE ) sauf si la garde [?Dinar =?COUT] est satisfaite, c.à.d
le montant reçu est strictement égal au prix ( ?Cout) .
Process Distributeur [MONNAIE , CAFE] : =
MONNAIE ?Dinar:NAT;
[?Dinar =?COUT] -> CAFE; stop
Distributeur [MONNAIE, CAFE]
endproc
Types abstraits de données. C‘est un cadre formel pour la définition des
types, leur ensemble de données, et leurs opérations. La définition d‘un type inclut 3
sections : Sorte (sorts), opérations (opns) et équations (eqns).
Sorte : nom donné à un domaine de valeurs. La section Sorts fournit la déclaration
des ensembles de valeurs. Par exemple BOOL dénote la sorte des valeurs booléennes
et NAT celle des entiers naturels.

Chapitre 3 : Les modèles de spécification
43
Opération, est nom donné à une fonction qui à n arguments (n > 0) fait
correspondre un résultat. Par exemple false, true, not, and, or, +, *, etc. La section
opns permet de construire les valeurs de la sorte.
Équation, sert à définir la sémantique des sortes et des opérateurs. La section
eqns fournit la définition des opérations par un ensemble d'axiomes. Les équations
permettent de définir une relation d'équivalence entre les termes de la sorte.
Exemple.
sorts nat
opns
succ : nat -> nat
0 : -> nat
_+_: nat -> nat
eqns forall x, y : nat
x+0 = x
x+succ(y) = succ(x+y)
Ici, la section opns permet de construire l'ensemble des termes de l'algèbre, c'est-à-
dire des valeurs de la sorte nat suivant : 0, succ(0), 0+0, 0+succ(0), succ(succ(0)),
etc.
La section eqns définit les opérations par un ensemble d'axiomes, et décrit une
relation d'équivalence entre les termes de la sorte, par exemple la valeur 1 correspond
à la classe d‘équivalence : {succ(0), succ(0)+0, 0+succ(0), succ(0+0), (succ(0)+0)+0,
… }
Remarque.
Un type abstrait peut hériter des sortes, des opérations et des équations d‘un autre
type abstrait.
Exercice 3.8.
Nous voulons modéliser le comportement simultané de 2 clients et un distributeur de
boissons (thé, café, chocolat chaud). La machine ne peut servir qu'un seul client à la
fois, le groupe de 2 clients doit être synchronisé avec le distributeur sur toutes les
portes (MONNAIE, THE, CAFE et CHOCOLATE).
Le distributeur effectue successivement les interactions suivantes:
1) Acquisition d'une somme d'argent (interaction MONNAIE) en dollars
( ?Dollars); au moyen d'une garde on interdit le rendez-vous si cette somme
?Dollars est inférieur au prix attendu (Cout).
2) Distribution d'une tasse de thé ou de café ou du chocolat chaud (interactions
THE, CAFE et CHOCOLATE) selon le choix du client. Après avoir payé
(interaction MONNAIE), chaque client sélectionne la boisson qu'il désire, en
appuyant sur un bouton. Par exemple s'il choisit le café, l'interaction CAFE est
imposée au distributeur.
3) Restitution de la monnaie (interaction CHANGE) si ?Dollars est supérieur au
prix (Cout).
4) Servir la boisson.

Chapitre 3 : Les modèles de spécification
44
 Spécifier le comportement du système en Full LOTOS.
A retenir.
LOTOS est un langage de spécification formelle développé à partir d'une base
théorique solide (les algèbres de processus), il permet d‘effectuer des manipulations
symboliques formelles.
Lotos permet également d‘exprimer des comportements de systèmes dynamiques
(concurrence, non déterminisme, communication synchrone et asynchrone).

Chapitre 4 : Vérification des Systèmes Concurrents
45
Chapitre 4. Vérification des Systèmes
Concurrents
Introduction.
Les techniques de spécification formelle de façon générale et les algèbres de
processus plus particulièrement ont considérablement contribué par leurs
méthodologies de conception et de vérification à la maîtrise de la complexité des
systèmes concurrents/distribués. Cependant, la limite majeure de ces techniques
réside dans la difficulté de spécifier en une seule étape et avec tous les détails, tout ce
que doit réaliser un système. La solution proposée était d‘effectuer un des
raffinements successifs de la spécification initiale (plus abstraite et moins détaillée)
jusqu‘à l‘aboutissement de l‘implémentation (plus détaillé et moins abstraite) en
passant par des spécifications intermédiaires.
Définition 4.1 (Vérification formelle). Le but de la vérification formelle
est d‘assurer qu‘un système (ou programme) satisfait un certain nombre de
propriétés. Elle se déroule généralement en trois phases : Une phase de modélisation,
qui consiste à modéliser le système étudié, et souvent à l‘abstraire, pour cela de
nombreuses structures ont été proposées : structures de Kripke, automates, réseaux
de Petri, STE, etc., une phase de spécification, qui exprime, sous différentes formes
possibles les propriétés que le modèle devra vérifier à travers les différents langages
de spécification: logiques temporelles du temps linéaire ou du temps arborescent, μ-
calcul, etc. et une phase de vérification, qui s‘assure que le système vérifie certaines
propriétés en fonction du modèle et du langage de spécification et avec des
algorithmes qui permettent de vérifier qu‘un modèle satisfait sa spécification comme
le model checking, le model checking symbolique.
Points de vérification.
La vérification s‘articule autour des points suivants
 Vérification de la validité : une fois ses besoins explicités, il se peut qu‘un
acteur revienne sur ses déclarations et ré-exprime ses besoins différemment.
 Vérification de la cohérence : les besoins exprimés dans le cahier des charges
ne doivent pas être contradictoires.
 Vérification de la complétude : le cahier des charges doit, tant que possible,
contenir la totalité des besoins des acteurs.
 Vérification du réalisme : on doit vérifier que les besoins peuvent être
effectivement satisfaits à l‘aide de la technologie existante et en respectant le
budget et les délais.

Chapitre 4 : Vérification des Systèmes Concurrents
46
 Vérifiabilité : on doit s‘assurer que les besoins sont exprimés sous une forme
vérifiable, avec le moins d‘ambigüités possible, de façon à ce que le document
puisse faire office de contrat.
Approches de vérification.
Nous pouvons distinguer trois grandes approches de vérification à savoir : l‘approche
logique, l‘approche comportementale, et l‘approche test formel.
L‘approche logique. Dans cette approche, les propriétés attendues du système sont
exprimées par des assertions dans une logique avancée, par exemple la logique
modale ou la logique temporelle. Dans ce contexte on distingue deux approches : une
basée sur la preuve de théorèmes (theorem proving ou proof checking) et une autre
basée sur le contrôle du modèle (évaluation ou test) tel que le model checking. Selon
cette approche, deux systèmes sont équivalents s‘ils satisfont les mêmes propositions
logiques. Nous nous focalisons dans ce cours sur la logique Modale (HML), la logique
temporelle linéaire (LTL) et la logique temporelle arborescente (CTL).
Logique modale.
Les concepts de logique modale, furent développés par les philosophes Prior,
Meredith et Kripke autour des années 1960. Elle utilise des opérateurs logiques
conventionnels en plus des opérateurs additionnels pour spécifier des modalités qui
sont : l‘opérateur de nécessité et l‘opérateur de possibilité. Nous intéressons par la
suite à la logique modale HML introduite par Hennessy et Milner en 1980.
Opérateurs principaux.
L‘ensemble M des formules Hennessy-Milner sur un ensemble d‘actions  est
donné par: , : =  |  |    |    | < >  | []
– Avec   ,  = , = .
– Un processus P satisfait    ssi P satisfait F ou P satisfait G.
– Un processus P satisfait    ssi P satisfait F et P satisfait G.
– Un processus P satisfait <> si et seulement s‘il existe une transition  à
partir de P menant à un processus satisfaisant F.
– Un processus P satisfait   si et seulement si toute transition  partant de P
mène à un processus satisfaisant F.
Propriétés.
– | = ¬   | = 
– ¬ = 
– ¬ = 
– ¬(  ) = ¬  ¬
– ¬(  ) = ¬  ¬
– ¬[] = < > ¬
– ¬< > = [] ¬
Satisfaction de propriétés. La sémantique des opérateurs est paramétrée par un STE
(,
/  )

Chapitre 4 : Vérification des Systèmes Concurrents
47
On dénote [[]] l‘ensemble de processus dans  satisfont la formule F tel que :
– [[]] = 
– [[ ]] = 
– [[  ]] = [[]]  [[]]
–   =   [[]]
– <>= <. . > [[]]
– [  ]= [. . ][[]]
Tel que :
<. . > = {  |    
 } et
[. . ]= {  |
      }
Exemple. Le STR ci-dessous modélise le comportement d’un distributeur de
boissons :
La proposition « Le client est prêt à boire le café » peut être représentée en HML par
la formule <café> tt ; maintenant nous voulons rechercher les états qu‘elle
satisfait <é > =<. é. > tt=<. é. >  =P alors seul l‘état P
satisfait le formule.
La proposition « Le client ne peut pas boire du thé » peut être représentée en HML
par la formule Théff, puisque aucun processus ne satisfait ff donc seuls les processus
n‘ayant pas de transition thé satisfont la formule :
=..=..=| é


     =p|p thé


=
P
1, P2, P3
Limites de HML. HML manque d'expressivité pour exprimer des propriétés ‖infinies‖
ou ‖récursives‖ comme : il est toujours possible de faire a, il n'est jamais possible de
faire b, à chaque fois qu'il est possible de faire a alors il est un jour possible de faire b,
etc. ces limitations peuvent être surmontées par la logique temporelle.

Collecter
1
2
1$
Thé
3
Café
2$

Chapitre 4 : Vérification des Systèmes Concurrents
48
Logique temporelle.
La logique temporelle est une extension de la logique propositionnelle, elle a été
introduite par Arthur Prior en 1957 afin de traiter des informations temporelles dans
un cadre logique. Elle intègre de nouveaux opérateurs qui expriment la notion du
temps. En logique temporelle on distingue deux notions principales liées à l‘aspect
temporel à savoir le temps linéaire LTL (Linear Temporal Logic) et le temps
arborescent CTL (Computation Tree Logic).
Logique du temps linéaire (LTL).
La logique du temps linéaire défini par Pnueli en 1977, 1981 [Pnueli 77,81] permet
d‘exprimer des propriétés sur une exécution d‘un système concurrent. Une telle
exécution est représentée par la suite des états dans lesquels se trouve ce système au
cours du temps qui se déroule linéairement. Une telle suite est appelée « chemin ». Le
temps linéaire LTL il permet de représenter le comportement des systèmes réactifs au
moyen des propriétés qui décrivent le système pour lesquels le temps se déroule
linéairement.
Syntaxe de LTL
Les formules de la logique temporelle linéaire LTL sont définies par la grammaire
suivante :
Les propositions atomiques : , =  |  | . . .|  | /,   .
Les connecteurs booléens : Soit ,  , toutes formules de la forme
 |  󰂭  |  󰂮  |    |    appartiennent à LTL.
Les connecteurs temporels : Soit ,  , Toutes formules de la
forme   |   |   |   appartiennent à LTL
Sémantique des opérateurs de LTL
– X (suivant ou Next): la proposition logique   signifie que  est vérifiée à
l‘état suivant":
– F (éventuellement ou eventually) : la proposition logique   signifie qu‘il
existe un état sur le chemin d‘exécution pour lequel  est vrai.
– G (toujours ou always) : la proposition logique   signifie que a est toujours
vérifiée dans le futur" :
Dans le futur
˥a
˥a
˥a
a
Quelconque
Fa
Suivant
Quelconque
a
Quelconque
Quelconque
Quelconque

Chapitre 4 : Vérification des Systèmes Concurrents
49
– U (jusqu‘à ou until): la proposition logique    signifie que a est vérifiée
jusqu'à ce que b le soit :
Exercice 4.1.
Exprimer en LTL le changement correct des couleurs d‘un feu de signalisation.
Computation Tree Logic (CTL)
La logique LTL ne permet pas d‘exprimer des propriétés du type «il est possible dans
le futur que ...». Il faut pour cela avoir plusieurs futurs possibles dans le modèle de la
logique. Donc, la logique CTL défini par Clarke et Emerson en 1981 [Clarke et
Emerson 81] permet de considérer plusieurs futurs possibles à partir d‘un état du
système plutôt que d‘avoir une vue linéaire du système considéré. Il permet
d‘exprimer des propriétés sur l‘arbre d‘exécution du système.
Syntaxe de CTL
Les connecteurs temporels : || || || | appartiennent à
CTL.
Les formules de la logique temporelle linéaire CTL sont définies par la grammaire
suivante :
1. Les propositions atomiques : , =    /,  
2. Les connecteurs booléens : Soit ,  , toute formule de la forme
 |  󰂭  |  󰂮  |    |    appartient à CTL.
3. Les connecteurs temporels : Soit a, b  CTL, toute formule de la forme
  |   |  