Une approche basée transformation de graphes pour la génération

Transcription

RÉPUBLIQUE ALGÉRIENNE DÉMOCRATIQUE ET POPULAIRE
MINISTÈRE DE L'ENSEIGNEMENT SUPÉRIEUR ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITÉ CONSTANTINE 2
FACULTÉ DES SCIENCES DES NOUVELLES TECHNOLOGIES DE L’INFORMATION ET DE LA
COMMUNICATION
DÉPARTEMENT D’INFORMATIQUE FONDAMENTALE ET SES APPLICATIONS
LABORATOIRE MISC
Année : 2013
N° d’ordre : 003/DR.LMD/2013/UC2
Série : 003/DR.LMD/NTIC
Thèse
Pour l’obtention du diplôme de Docteur 3ème cycle LMD en Informatique
Option : Systèmes distribués
Thème :
Une approche basée transformation de graphes pour la génération de
modèles de réseaux de Petri analysables à partir de diagrammes UML
Présentée par : Mouna Bouarioua
Date de soutenance: 24/ 04 /2013
Composition du Jury
Pr Saidouni Djamel Eddine
Université Mentouri Constantine
Président
Pr Chaoui Allaoua
Rapporteur
Pr Kimour Mohamed Tahar
Université Badji Mokhtar Aannaba
Examinateur
Dr Merniz Salah
Examinateur
Dr Amirat Abdelkrim
Université Mohamed Chérif Messaadia Souk-Ahras
Examinateur
Dédicace
À mes parents…
Remerciements
J’exprime toute ma gratitude au Pr Allaoua Chaoui, professeur à l’université Mentouri
Constantine, pour son encadrement et ses conseils précieux.
Je remercie Monsieur Djamel Eddine Saidouni, professeur à l’université Mentouri
Constantine, d’avoir accepté de présider le jury.
Je remercie également Messieurs : Pr. Kimour Mohamed Tahar, Dr. Merniz Salah et
Dr. Amirat Abdelkrim d’avoir accepté d’examiner ce travail.
Je tiens à remercier également tous ceux qui m’ont soutenu et qui ont contribué de
près ou de loin à l’élaboration de ce travail.
‫ملخص‪:‬‬
‫العمل المنجز في هذه المذكرة يعتبر مساهمة في مجال الهندسة بواسطة النماذج‪ .‬الهدف‬
‫األول من هذه المبادرة هو استعمال قواعد التصميم متعددة النماذج عبر طرق تحويل النماذج‬
‫لتمكين استخدام تقنيات التحليل أثناء دورة تطوير النظم المعقدة‪ .‬األعمال المنجزة في هذا‬
‫النطاق تتعلق باقتراح أدوات وبرامج تصميم تمكن من مساعدة مطوري النظم المعقدة‪ .‬يتم‬
‫تقديم أداة تمكن من استنتاج آليا الوصف الموافق في لغة ‪ UML 2.0‬انطالقا من نماذج‪ GSPN ,‬و‬
‫أداة‬
‫بواسطة‬
‫النماذج‬
‫هذه‬
‫تحليل‬
‫أخيرا‬
‫‪.TINA‬‬
‫كلمات مفتاح‪ :‬هندسة البرامج بواسطة النماذج‪ ,‬التصميم المتعدد النماذج‪ ,‬تحويل البينات‪ ,‬قواعد البينات‪,‬‬
‫الطرقالتحليلية‪ ,‬نماذج‬
‫‪.GSPN‬‬
Résumé:
Le travail présenté dans cette thèse est une contribution dans le domaine de
l’Ingénierie Dirigée par les Modèles (IDM). Son principal objectif est
l’application des techniques de la transformation de modèles, et plus
précisément les transformations de graphes, pour pouvoir appliquer des outils
d’analyse et de vérification durant le processus de développement des systèmes
complexes.
Les travaux présentés dans ce cadre consistent en une approche et un outil pour
la modélisation et la transformation des diagrammes de séquence et des
diagrammes d’états-transitions d’UML 2.0 en modèles de réseaux de Petri de
type GSPN. L’outil est conçu en langage Java sous l’environnement de
développement Eclipse. Ces librairies assistent le développeur dans ses tâches
de conception et de modélisation, et permettent l’application d’outils d’analyse.
Nous présenterons d’abord ces outils de modélisation des différents diagrammes
UML 2.0 et des réseaux de Petri GSPN, ensuite nous présenterons un outil pour
la transformation de ces modèles UML 2.0 en leurs équivalents dans le
formalisme GSPN. Nous utiliserons l’outil TINA pour analyser les propriétés
des modèles GSPN.
Mots clés : Ingénierie Dirigée par les Modèles, Modélisation multi-paradigmes,
Méta-modélisation, Transformation de Graphes, Grammaires de Graphes,
Méthodes Formelles, Réseaux de Petri, GSPN, Diagrammes de séquence,
Diagrammes d’états-transitions.
Abstract:
The work presented in this manuscript is a contribution in the field of Model
Driven Engineering (MDE). The main objective of this contribution is to use
models transformations and especially graphs transformation techniques in order
to facilitate the formal analysis in the development cycle of complex systems.
Our work consists of proposing an approach and a tool for modeling and
transforming UML2.0 sequence diagrams and statecharts to GSPN models. Our
tool is made with Java programming language under Eclipse development
environment. These libraries assist developers of complex systems. At first, we
propose tools based on meta-modeling concepts for modeling different
formalisms, in this work it concerns UML2.0 sequence diagrams, statechart
diagrams and Petri Net (GSPN), and then we develop a tool based on Graph
Grammar that provides automatic transformation of the UML2.0 diagrams to
their equivalent GSPN models. The formal analysis of GSPN is performed using
the TINA analyzer.
Keywords: Model Driven Engineering, Multi-paradigm Modeling, Metamodeling, Graph Transformation, Graph Grammar, Formal Methods, Petri Nets,
GSPN, Sequence Diagram, Statechart.
Table des matières
Introduction générale
Chapitre 1 : Ingénierie Dirigée par les Modèles et Modélisation multiparadigmes
1.1 Introduction
1.2 Les systèmes
1.3 L’ingénierie système
1.3.1 Notion de qualité pour un système
1.3.2 Ingénierie Dirigée par les Modèles (IDM)
1.3.2.1.Une méthode orientée modèles
1.3.2.2.Modèles, formalismes de modélisation et méta-modèles
1.3.2.3.Transformations de modèles
1.3.2.4.Types de transformations de modèles
1.3.2.5.Propriétés d’une transformation
1.3.2.6.Manipulation des modèles
1.3.2.7.Les approches de l’Ingénierie Dirigée par les modèles
(IDM)
1.3.3. L’Architecture Dirigée par les Modèles (ADM)
1.3.3.1.Typologie des modèles dans l’approche ADM
1.3.3.2.Transformations de modèles en ADM
1.3.3.3.Quelques standards de l’ADM
1.3.3.4.Couches de l’architecture ADM
1.3.3.5.Méta-modélisation et MOF
1.3.4. Autres approches basées sur les modèles
1.4 Systèmes complexes
1.5 Modélisation multi-paradigmes
1.5.1. Techniques de modélisation multi-paradigmes
1.5.2. Axes de la modélisation multi-paradigmes
1.6 Les transformations de graphes
1.6.1. Définitions et propriétés des graphes
1.6.2. Les relations entre les graphes
1.6.3. Principe de transformation de graphes
1.6.4. Grammaire de graphe
1.6.4.1.Principe de déroulement de règles
1.6.5. Système de transformation de graphes
1.6.6. Approches et outils de transformations de graphes
1.7. Conclusion
Chapitre 2 : Modélisation semi-formelle avec UML 2.0
2.1.Introduction
2.2.Historique des méthodes de conception
2.3.Méthode versus Langage de modélisation
2.4.Avantages de la modélisation Objet
2.5.Langage de modélisation UML
2.5.1. Les vues du langage UML 2.0
2.5.2. Interprétation de la conception et de l’analyse à travers la notation
UML2.0
1
5
6
6
7
7
8
9
9
10
11
13
15
16
16
17
18
19
20
20
22
22
24
26
28
31
32
33
34
35
36
37
38
42
43
44
44
46
46
46
47
49
2.5.3. Diagrammes UML 2.0
2.5.4. Diagrammes d’états-transitions
2.5.4.1.Caractéristiques d’un diagramme d’états-transitions
2.5.4.2.Les diagrammes d’états-transitions de Harel
2.5.4.3.État composite dans un diagramme d’états-transitions
2.5.4.4.Les transitions dans un diagramme d’états-transitions
2.5.4.5.La concurrence dans un diagramme d’états-transitions
2.5.5. Les diagrammes de séquence
2.5.5.1.Opérateurs dans les diagrammes de séquence
2.6.Conclusion
Chapitre 3 : Méthodes formelles et modèle GSPN
3.1.Introduction
3.2.Méthodes formelles
3.3.Langages formels
3.4.Techniques d’analyse
3.5.Classification des méthodes formelles
3.5.1. L’approche axiomatique
3.5.2. L’approche basée sur les états
3.5.3. L’approche hybride
3.6.Techniques de vérification formelle
3.6.1. Vérification de modèle ou Model-Checking
3.6.2. Preuve de théorèmes
3.6.3. Test d’équivalence
3.6.4. L’animation de spécifications
3.6.5. Les tests
3.7.Intégration des méthodes formelles dans l’IDM
3.8.Les réseaux de Petri
3.8.1. Historique
3.8.2. Bases et définitions des réseaux de Petri
3.8.3. Avantages et inconvénients des réseaux de Petri
3.8.4. Utilisation des réseaux de Petri
3.8.5. Outils de modélisation des réseaux de Petri
3.8.6. Définition formelle
3.8.7. Déroulement d’un réseau de Petri
3.8.7.1.Franchissement d’une transition
3.8.7.2.Séquences de franchissement
3.8.7.3.Marquages accessibles
3.8.8. Propriétés des réseaux de Petri
3.8.8.1.Propriétés génériques
3.8.8.2.Propriétés spécifiques
3.8.8.3.Graphes des marquages
3.8.9. Évolution des réseaux de Petri
3.8.10. Modélisation des systèmes complexes
3.8.11. Méthodes d’analyse des réseaux de Petri
3.9.Les réseaux de Petri Généralisés Stochastiques (GSPN)
3.9.1. Les motivations de l’introduction du temps dans les réseaux de
Petri
3.9.2. Réseaux de Petri Stochastiques
49
50
51
53
54
54
55
56
57
60
61
62
63
63
63
64
65
66
66
66
66
67
67
67
67
68
69
69
69
71
71
72
73
74
74
75
75
75
76
77
77
78
78
81
82
82
83
3.9.3. Politique d’exécution et processus stochastique
3.9.4. Le modèle SPN
3.9.5. Le modèle GSPN
3.9.5.1.Transitions temporisées
3.9.5.2.Transitions immédiates
3.9.6. Définition formelle du modèle GSPN
3.10. Les analyses effectuées
3.11. Conclusion
Chapitre 4 : Une approche de transformation des diagrammes de séquence
et des diagrammes d’états-transitions en réseaux de Petri GSPN à l’aide
des transformations de graphes
4.1.Introduction
4.2. Réalisation dans Eclipse
4.3.Les méta-modèles de notre approche
4.3.1. Méta-modèle des diagrammes de séquence
4.3.2. Méta-modèle des diagrammes d’états-transitions
4.3.3. Méta-modèle des réseaux de Petri GSPN
4.4.Transformations dans Eclipse
4.4.1. Grammaire de transformation des diagrammes de séquence vers
les réseaux GSPN (DS vers GSPN)
4.4.2. Grammaire de transformation des diagrammes d’états-transitions
vers les réseaux GSPN (SC vers GSPN)
4.5.Conclusion
84
86
86
86
87
88
90
91
92
93
94
95
95
96
97
99
105
106
109
Chapitre 5 : Cas d’utilisation
5.1.Introduction
5.2.Diagramme de séquence pour inscription à une formation E-learning
5.3. Diagramme d’états-transitions de l’objet « internaute » dans le
digramme de séquence
5.4.Implémentation du diagramme de séquence et génération du modèle
5.4.1. Application de la transformation sur le diagramme de séquence
5.4.2. Diagramme GSPN après la transformation du diagramme de
séquence
5.5.Implémentation du diagramme d’états-transitions et génération du
modèle
5.5.1. Application de la transformation sur le diagramme d’étatstransitions
5.5.2. Diagramme GSPN après la transformation du diagramme d’étatstransitions
5.6.Vérification du GSPN
5.6.1. Interprétation des résultats
5.7.Conclusion
110
111
111
113
Conclusion générale
123
Bibliographie
124
114
115
116
117
117
118
119
121
122
Table des Figures
Figure 1.1: Phases de réalisation d’un système
Figure 1.2 : Scénario d’une transformation de modèle [OMG04]
Figure 1.3 : Processus en Y d’une architecture ADM
Figure 1.4 : Transformations de modèles en ADM
Figure 1.5 : Standards de l’architecture ADM
Figure 1.6 : MOF et architecture à « 3+1 » niveaux
Figure 1.7 : Aperçu d’une partie des activités à réaliser durant la construction d’un système
Figure 1.8 : Les trois axes de la modélisation multi-paradigmes
Figure 1.9 : Abstraction et raffinement dans la modélisation multi-paradigmes
Figure 1.10 : Transformation de modèle dans la modélisation multi-paradigmes
Figure 1.11 : Graphe non orienté
Figure 1.12 : Graphe (a) et sous-graphe (b)
Figure 1.13 : Exemple de graphe orienté
Figure 1.14 : Exemple de graphe orienté et étiqueté
Figure 1.15 : Principe d’exécution des règles
Figure 1.16 : Application d’une règle de transformation
Figure 1.17 : Système de réécriture de graphe
Figure 1.18 : Environnement Eclipse
Figure 2.1 : Historique de constitution du langage UML
Figure 2.2 : Les aspects d’un système
Figure 2.3 : Différentes vues dans un concept UML 2.0
Figure 2.4 : Diagramme d’états-transitions simplifié d’une partie de jeu vidéo
Figure 2.5 : Syntaxe d’un état simple
Figure 2.6 : Syntaxe d’un état initial
Figure 2.7 : Syntaxe d’un état final
Figure 2.8 : Diagramme d’états-transitions d’un objet « Facture »
Figure 2.9 : Exemple d’un diagramme d’états-transitions de Harel
Figure 2.10 : Syntaxe d’un état composite
Figure 2.11 : Exemple d’un état composite dans l’opération de composition d’un
numéro de téléphone
Figure 2.12 : Exemple de transitions dans un diagramme d’états-transitions
Figure 2.13 : Exemple d’utilisation de transitions complexes et concurrence
Figure 2.14 : Syntaxe d’un message asynchrone
Figure 2.15 : Syntaxe d’un message synchrone
Figure 2.16 : Représentation d’un choix dans un diagramme de séquence
Figure 2.17 : Représentation d’une boucle dans un diagramme de séquence
Figure 2.18 : Exemple d’objet effectuant deux tâches en parallèle
Figure 2.19 : Exemple de l’utilisation de l’opérateur strict dans un diagramme de
séquence
Figure 3.1 : Classification des méthodes formelles
9
11
17
19
20
22
24
28
30
31
32
32
33
33
35
37
37
42
45
47
48
51
51
52
52
53
53
54
54
55
56
57
57
57
58
59
60
Figure 3.3 : Franchissement d’une transition t
65
70
74
Figure 3.4 : Graphe des marquages du réseau de Petri (a)
Figure 3.5 : Réseau de Petri avec parallélisme
77
78
Figure 3.2 : Exemple de réseau de Petri marqué
Figure 3.6 : Réseau de Petri avec synchronisation mutuelle
Figure 3.7 : Réseau de Petri avec synchronisation par signal
Figure 3.8 : Réseau de Petri avec partage de ressource
Figure 3.9 : Réseau de Petri illustrant le cas de la mémorisation
Figure 3.10 : Syntaxe d’une transition temporisée
Figure 3.11 : Transition temporisée (a) et transition immédiate (b)
Figure 3.12 : Exemple d’un GSPN avec des transitions immédiates et des transitions
temporisées
Figure 4.1 : Schéma de notre approche
Figure 4.2 : Scénario de notre transformation
Figure 4.3 : Les librairies de notre approche dans Eclipse
Figure 4.4 : Méta-modèle des diagrammes de séquence
Figure 4.5 : Méta-modèle des diagrammes d’états-transitions
Figure 4.6 : Méta-modèle du GSPN
Figure 4.7 : Relation entre diagramme de séquence et diagrammes d’états-transitions
Figure 4.8 : Transformations en GSPN
Figure 4.9 : Schéma de la première transformation des diagrammes de séquence vers
les GSPN
Figure 4.10 : Schéma de la deuxième transformation des diagrammes d’étatstransitions vers les GSPN
Figure 4.11 : Combinaison des deux transformations
Figure 4.12 : Grammaire de transformation des diagrammes de séquence vers le
modèle GSPN
Figure 4.13 : Premier ensemble de la grammaire de transformation des diagrammes
d’états-transitions vers les GSPN
Figure 4.14 : Deuxième ensemble de la grammaire de transformation des diagrammes
Figure 4.15 : Troisième ensemble de la grammaire de transformation des diagrammes
Figure 5.1 : Diagramme de séquence d’une demande de formation e-learning
Figure 5.2 : Diagramme d’états-transitions d’une instance de la classe « Internaute »
Figure 5.3 : Diagramme de séquence dans Eclipse
Figure 5.4 : Grammaire appliquée au diagramme de séquence dans Eclipse
Figure 5.5 : GSPN après transformation du diagramme de séquence dans Eclipse
Figure 5.6 : Représentation graphique du GSPN
Figure 5.7 : Diagramme d’états-transitions dans Eclipse
Figure 5.8 : Grammaire appliquée au diagramme d’états-transitions dans Eclipse
Figure 5.9 : GSPN après transformation du diagramme d’états-transitions
Figure 5.11 Partie du GSPN du système modélisé à vérifier
Figure 5.12 : GSPN dans TINA
Figure 5.13 : Analyse du GSPN
79
79
80
81
87
88
90
93
94
95
96
97
98
100
101
102
103
104
105
107
108
109
112
113
114
115
116
116
117
117
118
119
119
120
121
Tableaux
Tableau 1.1 : Les quatre niveaux de l’architecture ADM
Tableau 2.1 : Tableau comparatif entre diagrammes dans la conception et l’analyse
Tableau 3.1 : Exemples d’utilisation des réseaux de Petri
Tableau 3.2 : Les plus importants outils de modélisation des réseaux de Petri
21
49
72
73
Introduction Générale
Les systèmes logiciels sont présents, aujourd'hui, dans tous les domaines de l'activité humaine
(industrie, transports, communications, construction, etc.). Avec le temps, ces systèmes sont
devenus de plus en plus complexes, et par conséquent, leur analyse et leur vérification
représentent un enjeu capital.
UML est considéré de nos jours comme un standard pour la modélisation orientée objet des
systèmes complexes. Les diagrammes UML 2.0 sont divisés en trois catégories de classes : les
diagrammes structurels modélisent l’aspect statique du système à concevoir comme les
diagrammes de classes ou les diagrammes d’objets, les diagrammes comportementaux comme
les diagrammes d’activité ou les diagrammes d’états-transitions et les diagrammes
d’interaction ou dynamiques comme les diagrammes de séquence.
Pour la conception du logiciel, les descriptions semi-formelles telles que UML 2.0 offrent des
mécanismes d’expressions graphiques et textuelles très riches, proposant une représentation
intuitive et synthétique du système à construire. Cependant, UML 2.0souffre du manque
d’outils pour analyser et vérifier des propriétés. D’autre part, les méthodes formelles telles
que les réseaux de Petri offrent un ensemble d’outils pour analyser et vérifier les propriétés.
Les réseaux GSPN sont une extension des réseaux de Petri servant à modéliser des systèmes
qui évoluent dans des environnements stochastiques. Une approche intégrée UML-Méthodes
formelles s’avère intéressante pour palier aux insuffisances d’UML 2.0 concernant l’analyse
et la vérification des propriétés. Cette thèse s’inscrit dans le cadre de l’Ingénierie Dirigée par
les Modèles. Plus précisément, nous proposons une approche intégrée permettant de
transformer des diagrammes de séquence et des diagrammes d’états-transitions en leurs
équivalents en réseaux de Petri de type GSPN.
Notre approche est basée sur la transformation de graphes sous l’environnement de
programmation Eclipse. De nombreux travaux relatifs aux transformations de modèles, et
spécialement les transformations de graphes pour les besoins de l’analyse ont été réalisés en
utilisant les principes et les outils de méta-modélisation comme Generic Modeling
environment [GME], AtoM3 [ATOM3], MetaEdit+ [MetaEdit], et autres outils qui
proviennent du projet Eclipse Generative Modeling tools [GMT] comme Eclipse Modeling
Framework [EMF], Graphical Editing Framework [GEF] et Graphical Modeling Framework
[GMF]. Dans la plupart de ces outils, les transformations doivent être définies textuellement.
Il y a d'autres outils similaires qui manipulent les modèles en utilisant des grammaires de
graphes tels que PROGRES [PRGRES], GreAT [Balasubramanian06], FUJABA [FUJABA],
TIGER [Ehrig05] et AGG [AGG06, Taentzer03]. La transformation est faite en utilisant des
concepts de méta-modélisation pour permettre la réutilisation des formalismes afin de servir à
1
d'autres transformations que celles-ci. Cependant, aucun de ces outils n'a sa propre couche de
méta-modélisation.
Parmi les nombreux travaux existants, le travail de [Kerkouche10] traite de la transformation
entre les diagrammes d’états-transitions d’UML et les diagrammes de collaboration vers les
réseaux de Petri colorés. L’auteur a utilisé l’outil AtoM3 car l'approche est basée sur la
transformation de graphes et les deux modèles source et cible sont tous les deux des graphes.
La transformation génère un modèle graphique qui facilite la détection rapide des erreurs. Ce
dernier travail a été une étape dans un projet destiné à l'exploitation de l'outil d'analyse INA
[INA].
Dans [Holscher06], Une transformation de modèle UML (diagrammes de classes, de cas
d’utilisation, d’objet, d’états-transitions et d’interaction) vers un système de transformation de
graphes a été proposée par les auteurs. Le système de transformation de graphes est composé
de règles de transformation et d’un graphe de travail représentant l’état courant du système
modélisé. La simulation de l’exécution visuelle du système est effectuée en appliquant les
règles de transformation sur le graphe de travail. Le but de ce travail est la validation des
modèles UML dans des phases préliminaires avant l’implémentation du système.
Le travail proposé par [kuske02] présente une association des règles de transformation de
graphes avec les opérations dans le diagramme de classes et les transitions dans le diagramme
d’états-transitions. Les différentes règles de transformation sont combinées dans un même
système pour obtenir une description cohérente et unique de la sémantique.
Dans [Engels00], le diagramme de collaboration est interprété par un ensemble de règles de
transformation afin de spécifier une sémantique dynamique pour les modèles UML.
Le travail de [Baldan05] présente un cadre de la vérification des diagrammes d’activité à
l’aide des règles de transformation de graphes.
K. Ehrig présente l’outil graphique "TIGER" (Transformation based generation of modeling
environments) dans le but de générer d’autres modèles graphiques (cible) à partir d’autres
modèles graphiques (source). Les auteurs exposent l’exemple de la dérivation des réseaux de
Petri équivalents à des diagrammes d’activité. Après dérivation du modèle, l’outil propose un
moyen pour vérifier et valider les modèles obtenus. L’accent est mis sur la façon visuelle pour
spécifier les règles de transformation.
Dans [Guerra03], E. Guerra et J. De Lara proposent l’idée d'une plateforme pour vérifier une
modélisation UML. L'approche proposée consiste à établir des méta-modèles pour l'ensemble
des diagrammes UML, puis à les transformer vers plusieurs catégories des réseaux de Petri.
La syntaxe des réseaux de Petri est spécifiée par un méta-modèle. La transformation est
formellement décrite par les grammaires de graphe. Dans leur article [Guerra03], les auteurs
ont défini les règles de transformation des diagrammes de séquence vers réseaux de Petri
ordinaire.
2
Dans [Staines07], l’auteur transforme des diagrammes de séquence vers des "processors nets".
Ces derniers combinent la théorie des réseaux de Petri avec d’autres notations sous forme
d’instructions détaillées (les processors) associées aux transitions.
Nous citons également le travail de L.Guangyu et Y.Shuzhen [Guangyu09] qui ont présenté
un algorithme de translation des diagrammes de séquence vers les réseaux de Petri Objets.
Les travaux de S. Emadi, dans [Emadi09a] et [Emadi09a] consiste en la proposition d’un
algorithme de transformation d’un diagramme de cas d’utilisation et d’un diagramme de
séquence en un model exécutable basé sur différentes extensions des réseaux de Petri.
Dans [BDM02], un travail a été développé dans le but de transformer les diagrammes de
séquence en réseaux de Petri GSPN, sauf que la transformation est basée sur la syntaxe
abstraite des diagrammes de collaborations UML et sur les packages des états-transitions, et
non sur la transformation de graphes.
L’approche proposée dans le cadre de cette thèse se base sur ce dernier travail en traitant le
problème d’une autre manière. Ce travail consiste en la création d’une grammaire qui
permettra de transformer à travers son ensemble de règles des diagrammes de séquence et des
diagrammes d’états-transitions vers des réseaux de Petri GSPN. Ces derniers modèles feront
l’objet d’une vérification formelle dans l’outil de vérification TINA [TINA].
Notre travail est une contribution interdisciplinaire dans les approches visant l’utilisation
conjointe d’une méthode de spécification semi-formelle (UML 2.0) et une méthode de
spécification formelle appelée « GSPN », laquelle est une extension des réseaux de Petri dans
lesquels la notion du temps stochastique a été introduite.
Concrètement, nous avons proposé deux environnements de modélisation lesquels, dans un
premier lieu, permettront de produire des modèles pour les diagrammes de séquence et les
diagrammes d’états-transitions dans Eclipse. Ces modèles seront, par la suite, exploités par
des programmes qui procéderont à la transformation de ces deux diagrammes UML 2.0en des
réseaux de Petri de type GSPN. Les résultats de ces transformations seront exploités par
l’outil d’analyse des réseaux de Petri TINA.
Ce manuscrit est organisé comme suit :
-
Le premier chapitre présente les concepts de base de l’Ingénierie Dirigée par les
Modèles (IDM) avec ses différentes variantes, nous nous intéresserons en particulier à
l’Architecture Dirigée par les Modèles (ADM) dans le cadre des systèmes complexes.
Dans la deuxième partie de ce chapitre, nous présenterons les techniques de
modélisation multi-paradigmes et ses axes. Á la fin, nous aborderons les
transformations de graphes, leurs grammaires et les systèmes de transformation.
-
Le second chapitre est une présentation de la modélisation orientée objet, l’utilisation
du langage UML 2.0 ainsi que l’interprétation de la conception à travers la notation
UML 2.0.
3
-
Le troisième chapitre est une vue générale sur les méthodes formelles et leurs
classifications. Leur intégration à l’IDM sera ensuite étudiée. La fin de ce chapitre sera
consacrée aux réseaux de Petri stochastiques de type GSPN.
-
Dans le quatrième chapitre, nous présenterons une approche et un outil de
modélisation et des librairies Java pour la spécification et la transformation des
diagrammes de séquence et des diagrammes d’états-transitions d’UML 2.0 vers les
réseaux de Petri GSPN. Ces modèles GSPN seront par la suite exploités par l’outil
d’analyse TINA.
-
Le cinquième chapitre illustre l’application de notre approche et outil sur une étude de
cas qui consiste en un système d’inscription à une formation e-Learning. Le GSPN
généré sera exploité par TINA qui nous donnera le résultat de l’analyse.
-
Le dernier chapitre est une conclusion générale qui résume les contributions de cette
thèse, et discute des limites et des perspectives de notre travail.
4
Chapitre 1 : Ingénierie Dirigée par les
Modèles et Modélisation multiparadigmes
5
Chapitre 1
Ingénierie Dirigée par les Modèles et Modélisation multiparadigmes
1.1. Introduction
Un système est caractérisé par les propriétés qui résultent de l’interaction de ses éléments. Le
processus de conception des systèmes doit considérer la multiplication des fonctionnalités, la
diminution des coûts de développement, ou l’amélioration des performances qui ont une
influence directe, aussi bien sur la qualité du système que sur le cycle de développement. Ce
chapitre présente quelques évolutions concernant l’activité de conception dans le domaine de
l’Ingénierie Système. Nous étudierons les approches autour des modèles, en particulier
l’Ingénierie Dirigée par les Modèle (IDM) et l’Architecture Dirigée par les Modèles (ADM).
1.2. Les systèmes
Un système complexe [AFIS] est défini comme un ensemble organisé d’entités collaborant de
manière unitaire, et en interaction permanente, pour assurer une ou plusieurs fonctions du
système dans son environnement. Les propriétés d’un système résultent de l’interaction de ses
constituants. Des propriétés émergentes [Holland98] sont parfois souhaités et parfois
indésirables. Nous pouvons dans ce cas dire que l’intérêt de la conception en ingénierie
système est d’obtenir les comportements émergents attendus, en maintenant les
comportements émergents non-attendus dans les limites acceptables. L’étude
comportementale d’un système est alors incontournable.
Différents types de systèmes ont été identifiés dans la littérature : les systèmes
transformationnels, les systèmes interactifs, les systèmes réactifs, etc. Selon D. Harel et A.
Pnueli [Harel85], un système transformationnel acquière des données, les traite, produit un
résultat et se termine. Un système interactif est un système où nous pouvons observer une
interaction avec son environnement. Cette propriété des systèmes interactifs n’est pas
entièrement maîtrisable ni prévisible, de ce fait, leur conception devient systématiquement
difficile.
Les systèmes critiques sont des systèmes soumis à des contraintes extrêmement fortes.
Aucune erreur n’est alors permise, car une seule erreur de fonctionnement pourrait provoquer
des conséquences catastrophiques. Les systèmes critiques peuvent être des systèmes tempsréel, pour lesquels les contraintes de temps de réponses sont strictes.
Les systèmes distribués sont des systèmes répartis, fonctionnant généralement les uns avec les
autres dans un réseau. Les systèmes adaptatifs dits aussi reconfigurables ont la faculté de
s’adapter de manière dynamique aux changements de leurs environnements en modifiant
continuellement leur configuration.
6
La complexité est le facteur qui rend difficile la tâche de conception d’un système. Cette
complexité dépend des points suivants :

Le nombre et la nature des éléments constituant le système : dans un système
complexe, les éléments sont hétérogènes et le nombre d’éléments peut être élevé ou,
éventuellement, variable.

La nature de son organisation interne : cette organisation concerne les relations
entre les éléments du système, qu’ils soient organisées dans des réseaux ou des
hiérarchies, etc.

Le couplage avec l’environnement : plus le système interagit avec son
environnement, plus il y a des incertitudes sur son comportement.
1.3. L’ingénierie système
L’ingénierie système est l’ensemble des activités centrées autour du cycle de vie d’un système
depuis sa définition jusqu’à sa validation [INCOSE, AFIS]. Il s’agit d’un processus
coopératif, itératif et interdisciplinaire, car il consiste à intégrer des efforts de toutes les
disciplines impliquées dans le cycle de vie du système.
1.3.1. Notion de qualité pour un système
En ingénierie système, divers travaux ont défini la qualité du logiciel en termes de facteurs ou
de métriques qualitatives et quantitatives, qui dépendent du domaine de son application et des
outils utilisés. Parmi ces derniers nous pouvons citer :
 La validité : Un système doit assurer son fonctionnement exactement comme il a été
défini par le cahier des charges et les spécifications.
 La fiabilité ou la robustesse : Un système doit pouvoir fonctionner aussi dans des
conditions anormales.
 L’extensibilité (maintenance) : Un système doit se laisser maintenir, c'est-à-dire
supporter des éventuelles modifications ou une extension vers des fonctions qui lui
seront demandées.
 La réutilisabilité : Un système doit être apte à être réutilisé, partiellement ou dans son
intégralité, dans d’autres systèmes.
 La compatibilité : Un système doit être interopérable avec d’autres systèmes.
7
 L’efficacité : Un système doit pouvoir utiliser les ressources matérielles de manière
optimale.
 La portabilité : Un système doit pouvoir être facilement transféré vers différents
environnements matériels et logiciels.
 La vérifiabilité : Un système doit faciliter la préparation des procédures de test en son
sein.
 L’intégrité : Un système doit protéger son code et ses données et doit pouvoir gérer
les autorisations d’accès.
 La facilité d’emploi : Un système doit offrir une facilité d’apprentissage,
d’utilisation, de préparation des données, d’interprétation des erreurs et de rattrapage
en cas d’erreur d’utilisation.
Ces facteurs sont parfois contradictoires. Le choix des compromis doit s’effectuer en fonction
du contexte.
1.3.2. Ingénierie Dirigée par les Modèles (IDM)
L’ingénierie système est une démarche de réalisation des systèmes. Son objectif est de
dénombrer et d’organiser les différentes activités du cycle de développement, afin de gérer la
conception du système ainsi que sa complexité. Ses tâches s’occupent principalement de la
mise en œuvre d’un système jusqu’à sa réalisation en passant par sa modélisation.
Par Ingénierie Dirigée par les Modèles nous faisons référence à l’ensemble outils/langages
mis en place pour la manipulation des modèles. Cette pratique encourage l’utilisation de
plusieurs modèles exécutables de haut-niveau, et permet d’élever la productivité du
développement en séparant la ‘‘logique métier’’ des plateformes utilisées [Lavagno03].
Les modèles sont une manière intuitive et naturelle de représenter l’état et le comportement
d’un système, quelque soit son degré de complexité et à chaque étape de son cycle de vie.
L’IDM exploite les modèles en les détaillant en fonction du besoin, jusqu’à obtention d’un ou
plusieurs squelettes de codes générés de manière systématique. L'intérêt principal de cette
approche réside dans l’utilisation intensive de modèles indépendants de toute plateforme.
Nous consacrons le reste de ce chapitre aux concepts de base de l’Ingénierie Dirigée par les
Modèles (IDM) qui couvre les disciplines dans lesquelles les modèles jouent un rôle principal
[Kent02, Favre06]. Nous nous intéresserons également à l’Architecture Dirigée par les
Modèles (ADM) et à son utilisation pour le développement des systèmes complexes.
8
1.3.2.1. Une méthode orientée modèles
La séparation du modèle de l’architecture est l’un des premiers objectifs de l’IDM qui place le
modèle au centre du développement [Bézivin 04] et assure que le développement d’un
système se réalise par un processus fait de plusieurs transformations successives d’un modèle
de base, jusqu’à obtention du code final. La figure 1.1 montre les grandes phases de la
réalisation d’un système.
Cahier des charges
Expression des besoins
Décrire les besoins du système
Analyse
Conception
Comment le système doit-il être construit ?
Codage du résultat de la conception
Implémentation
Test
Ce qui doit être fait dans le système
Le système est-il conforme au cahier des charges ?
Code exécutable livré
Figure 1.1: Phases de réalisation d’un système
1.3.2.2. Modèles, formalismes de modélisation et méta-modèles
Un modèle est défini comme étant une abstraction d’un système qui se substitue à ce dernier
pour le simuler et analyser ses propriétés [Marvin68]. Les modèles servent de support pour
véhiculer la représentation mentale du système entre les différents acteurs impliqués dans son
développement.
Le modèle contient les données nécessaires à la production et à l’évolution du code. Les
modèles sont considérés comme des éléments de production et doivent être assez complets
pour répondre à la place du système qu’ils représentent.
En plus des caractéristiques liées à la qualité, comme la maintenabilité, la traçabilité des
modifications ou encore l’évolutivité, le modèle doit avoir les propriétés suivantes
[Lavagno03]:
9
 Abstrait : Cette qualité permet de cacher certains détails inutiles à un moment donné
de la conception.
 Compréhensible: Le modèle doit être facile à assimiler et à manipuler par tous les
acteurs entrant dans l’élaboration du système.
 Fidèle et précis : Le modèle doit représenter fidèlement les propriétés et les
caractéristiques du système lorsqu’il est observé dans une optique spécifique.
 Prédictif : Le modèle doit fournir assez d’informations pour permettre de prédire les
propriétés du système.
 Economique : Les coûts de construction et de tests sur le modèle doivent être limités
et ne doivent pas dépasser les coûts de construction d’un prototype du système.
L’IDM se base sur des formalismes ou des langages de modélisation. Le langage de
modélisation est défini par : une syntaxe abstraite qui définit les concepts de base du langage,
une syntaxe concrète qui définit le type de notation (graphique, textuelle ou mixte), des
concepts abstraits, et une sémantique pour permettre l’interprétation des concepts par les
acteurs et les machines.
Un modèle est dit productif s’il est exploitable par une machine qui pourra interpréter sans
confusion le langage dans lequel il a été formulé. L’idée d’utiliser les modèles pour définir un
langage de modélisation s’appelle La Méta-modélisation. Nous définissons un méta-modèle
comme le modèle qui sert à exprimer (modéliser) le langage d’expression d’un modèle, avec
ses entités, ses relations et ses contraintes.
À son tour, le méta-modèle est aussi spécifié dans un langage de méta-modélisation par le
méta-méta-modèle. Arrivé à ce niveau d’abstraction méta-circulaire, le langage est assez
puissant pour spécifier sa propre syntaxe abstraite.
1.3.2.3. Transformations de modèles
L’IDM considère les opérations de transformations de modèles comme le moteur de
développement, que ce soit pour l’analyse, l’optimisation ou la génération de code.
Cette procédure consiste à générer, à partir d’un ou de plusieurs modèles sources d’un
système, un ou plusieurs modèles cibles du même système. Les modèles sont dans tous les cas
conformes à leurs méta-modèles respectifs. Lorsque la transformation se fait dans un même
formalisme (méta-modèle source = méta-modèle cible) elle est dite endogène. Dans l’autre
cas, quand les deux méta-modèles source et cible sont différents, la transformation est dite
exogène.
10
Ces transformations sont gouvernées par un ensemble de règles utilisées par le moteur de
transformation. Ce moteur prend en entrée le modèle source, exécute les règles de
transformation et génère le modèle cible.
La figure 1.2 présente un scénario de transformation de modèle avec ses principaux concepts.
Un modèle source en entrée et un modèle cible en sortie. Les deux modèles sont conformes à
leurs méta-modèles respectifs. Le méta-modèle exprime la syntaxe abstraite de la notation du
modèle. Une transformation respecte les méta-modèles et est réalisée par l’intermédiaire d’un
moteur de transformation.
Définition de la
transformation
Méta-modèle source
Réfère à
Conforme à
Méta-modèle cible
Réfère à
Conforme à
Exécute
Modèle source
Lit
Moteur de
transformation
Modèle cible
Ecrit
Figure 1.2 : Scénario d’une transformation de modèle [OMG04]
1.3.2.4. Types de transformations de modèles
L’IDM définit trois types de transformations de modèles, les transformations verticales, les
transformations horizontales et les transformations obliques.
 Transformations verticales
Ces transformations se jouent sur les niveaux d’abstractions. Un raffinement se
fait lorsque cette transformation descend d’un niveau, mais lorsqu’on élève le
niveau d’abstraction, la transformation est dite : une abstraction.
 Transformations horizontales
Ces transformations gardent le même niveau d’abstraction en modifiant les
représentations d’informations du modèle source (ajout, modification,
suppression ou restructuration).
 Transformations obliques
Ces transformations sont généralement utilisées par les compilateurs qui
optimisent le code source avant la génération du code exécutable. Elles sont le
résultat de la combinaison des deux premiers types de transformations.
11
Ces transformations se font par l’intermédiaire d’un processus de dérivation
des règles de transformation. À chaque règle correspondent des entités du
modèle source et leurs équivalents dans le modèle cible. Le développeur choisit
librement le langage de transformation qui correspond à ses besoins, il pourra
les spécifier de façon déclarative, impérative ou hybride.
Dans la spécification déclarative, une règle décrit, après son application, le
résultat supposé à partir des éléments du modèle. La spécification impérative
décrit en termes de suite d’actions comment le résultat sera obtenu. La
spécification hybride combine les deux spécifications, impérative et
déclarative.
Les transformations de modèles se partagent également en deux grandes
classes [Czarnecki03] : les transformations « Modèle vers Code », et les
transformations « Modèle vers Modèle » largement étudiées dans l’approche
ADM.
• Transformation Modèle vers Modèle
Ces transformations ont beaucoup évolué depuis l’apparition de l’ADM. Ce type de
transformation permet la génération de plusieurs modèles intermédiaires avant
d’atteindre le modèle de code, afin d’étudier les différentes vues du système, son
optimisation, la vérification de ses propriétés et sa validation.
Nous distinguons cinq techniques de transformation « Modèle vers Modèle » :
 Approche par manipulation directe
Cette approche est basée sur une représentation interne des modèles source et
cible, en plus des API (Application Programming Interface) pour les
manipuler.
 Approche relationnelle
Cette approche utilise les contraintes pour spécifier les relations entre les
éléments du modèle source et ceux du modèle cible en utilisant une logique
déclarative basée sur des relations mathématiques.
 Approche basée sur les transformations de graphes
Cette approche convient lorsque les modèles sont représentés par des graphes.
Elle exprime les transformations sous une forme déclarative. Les règles de
transformation sont définies sur des parties de modèle et non pas sur des
éléments basiques. Une opération de filtrage de motifs (Pattern Matching) est
12
ensuite lancée. Le moteur de transformation compare à chaque fois des
fragments du modèle source pour trouver des règles applicables. Ce fragment
est ensuite remplacé par son équivalent dans la règle appliquée. Quelques
exemples d’approches basées sur les transformations de graphes : VIATRA,
ATOM3, GreAT, UMLX, BOTL, etc.
 Approche basée sur la structure
Divisée en deux étapes, la première se charge de la création d’une structure
hiérarchique du modèle cible, la seconde ajuste ses attributs et ses références.
Le cadre de transformation fourni par OptimalJ proposé par Compuware est un
exemple d’une approche basée sur la structure.
 Approche hybride
Comme XDE et ATL, les approches hybrides sont la combinaison des
différentes techniques ou alors celle d’approches utilisant à la fois des règles à
logique déclarative et impérative.
• Transformation Modèle vers Code
Il existe deux types de transformations« Modèle vers Code »: la première est basée sur
le principe du visiteur (visitor-based) où l’on se sert du modèle et ses éléments qui
rapprochent sa sémantique du langage de programmation pour obtenir le code ;la
deuxième est basée sur le principe des patrons (Template-based) avec laquelle on
accède aux informations du modèle source en utilisant les fragments de méta-code
dans le code cible.
Il existe d’autres classifications basées sur les caractéristiques des langages de
transformation des modèles utilisés.
1.3.2.5. Propriétés d’une transformation
Une transformation est généralement caractérisée par l’ensemble de ses règles de
transformation, leur ordonnancement, leur organisation, la relation entre les deux modèles
source et cible, la traçabilité et la direction.
o Les règles de transformation
Une règle de transformation est partagée en deux parties: une partie gauche (LHS Left Hand
Side) accédant au modèle source, et une autre partie droite (RHS Right Hand Side) qui accède
au modèle cible. La partie logique (déclarative ou impérative) de la règle comporte les calculs
à effectuer sur les modèles ainsi que les contraintes appliquées.
13
Une logique déclarative spécifie les relations entre les éléments des modèles source et cible.
Une logique impérative utilise généralement des langages de programmation pour manipuler
les éléments des modèles sur des interfaces dédiées (exemple JMI).
o Les spécifications
Les spécifications représentent des relations non-exécutables, mais peuvent
exceptionnellement représenter une fonction entre les modèles source et cible et deviennent,
dans ce cas, exécutables. Certaines approches fournissent des mécanismes de spécifications
dédiés, tels que les pré-conditions et les post-conditions en OCL (Object Constraint
Language).
o La relation entre le modèle source et le modèle cible
La relation entre le modèle source et le modèle cible dépend du type de la transformation.
Nous parlons de transformation endogène lorsque le modèle source et le modèle cible sont
exprimés dans le même formalisme. La transformation est exogène lorsque les deux modèles
sont exprimés dans deux formalismes différents.
o L’organisation des règles
C’est une organisation qui définit la stratégie selon laquelle les règles seront appliquées. Ces
règles peuvent être organisées de façon modulaire avec importation. Les règles peuvent
utiliser le principe de réutilisation en passant par le mécanisme d’héritage entre les règles, ou
la composition en passant par l’ordonnancement explicite. Les règles peuvent être organisées
aussi selon une structure dépendante du modèle source ou du modèle cible.
o L’ordonnancement des règles
C’est l’ordre d’application des règles. Si l’algorithme d'ordonnancement est défini par l’outil
de transformation, l'ordonnancement est dit implicite. Si d’autres mécanismes spécifient
l’ordre d’exécution des règles, nous parlons alors d’ordonnancement explicite. L’ordre peut se
baser sur des conditions, des itérations ou sur une séparation d’étapes lorsque certaines règles
ne peuvent s’appliquer que dans des phases bien définies.
o La traçabilité
Les corrélations entre les éléments des modèles de la transformation peuvent être archivées.
La traçabilité est implémentée comme n’importe quel autre lien dans un modèle lorsque
l’approche utilisée n’offre aucun mécanisme pour la supporter.
14
o L’incrémentalité
Cette propriété est liée à l’aptitude des modèles cibles à s’adapter aux changements des
modèles sources.
o La direction
La transformation est unidirectionnelle lorsque le modèle cible est généré sur la base du
modèle source uniquement, et elle est bidirectionnelle lorsqu’une synchronisation entre les
deux modèles source et cible est possible.
1.3.2.6. Manipulation des modèles
Il existe plusieurs activités liées à la manipulation des modèles dans l’IDM. Chacune
appartient à un contexte spécifique. Nous pouvons citer :
 La réalisation des modèles
Une bonne maîtrise du langage utilisé dans la modélisation et une expertise technique sont
nécessaires pour la réalisation des modèles. Plus les systèmes sont complexes, plus leurs
modèles le deviennent et plus leurs tailles deviennent importantes. Une bonne stratégie
technique (outils et supports) s’avère une tâche délicate pour réaliser et manipuler les
modèles.
 Le stockage des modèles
Cette activité concerne les formats de stockage, l’organisation du stockage et la gestion des
métadonnées des modèles.
 L’échange des modèles
Pour une bonne communication entre eux, les acteurs d’un projet doivent procéder à
l’échange de leurs modèles. Ces derniers doivent être compréhensibles par tous, au risque
d’exposer le système implémenté à des dégâts. L’échange de modèles prend en considération
les contraintes du format (sérialisation, transport, etc.), les contraintes de traduction ainsi que
celles d’interprétation de la sémantique pour leur interopérabilité.
 L’interrogation des modèles
L’interrogation des modèles est l’activité qui permet de rechercher et de récupérer des
informations dans les modèles.
15
 L’exécution des modèles
Cette étape va de la simulation du système à son exécution en temps-réel, en passant par
l’exécution symbolique et la génération du code.
 La vérification des modèles
La vérification d’un modèle consiste à vérifier ses propriétés propres par rapport à ce que l’on
attend de lui. Cette vérification est syntaxique et sémantique. La vérification sémantique est la
plus complexe. Il existe différentes techniques pour procéder à la vérification d’un modèle,
avec chacune ses avantages et ses inconvénients. Nous citons: la technique de preuves qui
s’appuie sur les représentations formelles du système basées sur la logique, les automates, les
réseaux de Petri, etc. Une autre technique est le ‘’model-cheking’’ qui vise à analyser le
comportement du système tout en vérifiant des propriétés telles que la sûreté, l’atteignabilité
ou la vivacité. Cette technique apporte avec elle un risque d’explosion combinatoire du
nombre d’états dans le cas des systèmes complexes. Le test complète le model-cheking dans le
cas où ce dernier n’a pas été particulièrement efficace (cas de système très complexe).
 La validation des modèles
La validation affirme ou non que le système implémenté répond aux besoins initiaux.
Certaines techniques de tests sont utilisables pour la vérification mais également pour la
validation. Les modèles génèrent des scénarios et des vecteurs de test de façon automatique
[Bernot91].
 La gestion de l’évolution des modèles
Les modèles évoluent tout au long du cycle de développement du système. Ils peuvent être
corrigés ou modifiés en recevant d’autres fonctionnalités. Ces modifications sont
automatiquement répercutées sur les autres modèles impliqués.
1.3.2.7. Les approches de l’Ingénierie Dirigée par les Modèles (IDM)
L’IDM est un domaine basé sur les modèles et les technologies liées à leurs manipulations.
Pour la pratique, il existe plusieurs manières d’utiliser les modèles dans le processus de
développement d’un système. L’approche la plus développée et la plus utilisée est
L’Architecture Dirigée par les Modèles (MDA : Model Driven Architecture).
1.3.3. L’Architecture Dirigée par les Modèles (ADM)
L’Architecture Dirigée par les Modèles (ADM) est une approche de développement proposée
et soutenue par l’OMG (Object Management Group) [OMG04]. Pour des raisons de
productivité, l’approche ADM préconise l’utilisation de plusieurs modèles indépendants des
16
détails techniques de l’implémentation. Cette méthode consiste en l’élaboration et la
transformation de modèles tout au long du processus de développement d’un système. Ces
modèles ont pour objectif de simplifier la gestion de la complexité des systèmes en spécifiant
différents niveaux d’abstraction, aussi bien pour la vue globale du système que pour les
protocoles et les algorithmes. Ces modèles sont reliés par des liens de traçabilité et peuvent
être exprimés de façon textuelle ou graphique.
Le cycle de développement de l’approche ADM suit un processus en Y [Roques00] dont les
branches représentent les spécifications fonctionnelles du système et les spécifications
techniques de la plateforme. L’implémentation est la branche qui rassemble les deux
spécifications comme le montre la figure 1.3.
Branche technique
Branche fonctionnelle
CIM
Modèle de
plateforme
PIM
PSM
Figure 1.3 : Processus en Y d’une architecture ADM
1.3.3.1. Typologie des modèles dans l’approche ADM
L’approche ADM appelle à la réalisation de trois types de modèles [Bézivin02]: les modèles
d’exigences (CIM) qui sont indépendants de toute informatisation, les modèles d’analyse et
conception (PIM) qui sont indépendants de la plateforme et les modèles de code (PSM) qui
dépendent d’une plateforme cible.
17
 Modèles d’exigences CIM (Computation Independent Model)
La réalisation de ce modèle est la première étape dans le développement d’un système
puisqu’elle va permettre de modéliser toutes les exigences du client et définir les différentes
interactions qui impliqueront le système dans ses environnements interne ou externe. De ce
fait, le CIM sera considéré comme référence pour vérifier la conformité du système avec les
exigences du client.
Le CIM ne donne aucun détail sur la façon de la réalisation ou le fonctionnement du système
mais exprime clairement des liens de traçabilité avec les modèles futurs.
 Modèle d’analyse et conception abstraite PIM (Platform Independent
Model)
Les modèles d’analyse et conception doivent être indépendants de toute plateforme
d’implémentation mais aussi contenir assez de détails pour permettre la génération
automatique du code. Ces modèles organisent le futur système en modules et sous-modules et
relient le premier modèle d’exigence CIM avec le code.
 Modèle de description de plateforme PDM (Platform Description
Platform)
Les modèles PDM fournissent l’ensemble de concepts techniques liés à la plateforme
d’exécution et à ses services. Ils contiennent toutes les informations nécessaires à sa
manipulation.
 Modèle de code PSM (Platform Specific Model)
Ces modèles facilitent la génération du code à partir de la combinaison des modèles d’analyse
et conception PIM et les modèles de plateforme PDM. Les PSM expriment, par exemple, les
événements, les composants, les instructions, les conditions, etc.
1.3.3.2. Transformations des modèles en ADM
L’ADM considère le processus de développement du système comme une suite successive et
stratégique de transformations de modèles. Ces transformations établissent de manière
automatique des liens de traçabilité entre les trois types de modèles discutés précédemment,
des transformations CIM vers PIM et PIM vers PSM dans cet ordre, ou inversement
[Czarnecki06]. La figure 1.4 montre ces transformations.
18
PDM
Transformation
PIM - PSM
PIM
Raffinement de PIM
PSM
Transformation
PSM - code
Code
Raffinement de PSM
Figure 1.4 : Transformations de modèles en ADM
1.3.3.3. Quelques standards de l’ADM
L'approche ADM est liée à de nombreux standards, en 2013 nous pouvons citer :
■
■
■
■
■
■
■
■
■
UML (Unified Modeling Language) [OMGa] : Un langage visuel semi-formel pour la
modélisation des systèmes. Il permet de schématiser l’architecture, les solutions et les
vues avec des diagrammes augmentés de texte.
MOF (Meta-Object Facility) [OMGb] : Un standard de méta-modélisation constitué
d’un ensemble d’interfaces standards pour définir la syntaxe et la sémantique d’un
langage de modélisation, créé principalement pour définir la notation UML.
XMI (XML Metadata Interchange) [OMGe] : Un standard d’échange de métadonnées.
OCL (Object Constraint Language) [OMGd] : Un langage qui, intégré à UML, lui
permet de formaliser l’expression des contraintes.
SPEM (Software Process Engineering Metamodel) [OMGs] : Un processus de métamodélisation défini comme un profil UML.
CWM (Common Warehouse Metamodel) [OMGc] : Une interface basée sur UML,
MOF et XMI pour faciliter l’échange de métadonnées entre outils, plateformes et
bibliothèques de métadonnées dans un environnement hétérogène.
MOFM2T (MOF Model-to-Text language) [OMGm] : Une spécification utilisée pour
exprimer des transformations de modèles en texte.
QVT [QVT] : Un langage standard pour exprimer les transformations de modèles.
EDOC (Enterprise Distributed Object Computing) [OMGedc] : Une plateforme
standard basée sur UML pour simplifier le développement des composants dans un
environnement distribué.
19
1.3.3.4. Couches de l’Architecture ADM
L’OMG a organisé l’architecture ADM sur quatre couches de standards comme le montre la
figure 1.5. Le langage UML (Unified Modeling Language) se trouve au centre avec MOF
(Meta-Object Facility) et CWM (Common Warehouse Metamodel). Dans la couche qui suit
se trouvent des standards tels que XMI (XML Metadata Interchange) pour le dialogue entre
les plateformes (Java, CORBA, .NET et web services). La troisième couche se charge de la
gestion des évènements, la sécurité, les répertoires et les transactions. La dernière couche
concerne les plateformes spécifiques selon les domaines (télécommunication, commerce
électronique, etc.).
Finance
E-commerce
Industrie
Espace
Télécommunication
Transport
Santé
Plus..
Figure 1.5 : Standards de l’architecture ADM
1.3.3.5. Méta-modélisation et MOF (Meta Object Facility)
L’objectif de la notion de méta-modélisation est de représenter les concepts des formalismes
utilisés lors de la modélisation. Pour l’ADM, la méta-modélisation joue un rôle fondamental
dans le processus de transformation de modèle d’un langage vers un autre : il s’agit de décrire
les constructions du langage source et leurs équivalents dans le langage cible, de manière
abstraite et indépendante.
D’autre part, l’OMG a défini la notion de méta-méta-modèle et a standardisé une architecture
générale décrivant les liens entre modèles, méta-modèles et méta-méta-modèles.
20
L’OMG [OMG04] a organisé cette architecture en « 3+1 » niveaux comme montré sur le
tableau 1.1 :
Méta-méta-modèle
Langage de spécification des méta-modèles.
Méta-modèle
Définition du langage utilisé pour exprimer le modèle.
Modèle
Système réel
Abstraction du système.
Informations et flux de contrôle d’un domaine.
Tableau 1.1 : Les quatre niveaux de l’architecture ADM
 Niveau M3 (MMM)
Dans l’approche ADM, le niveau M3 (ou méta-méta-modèle) est composé d’une seule
entité réflexive (auto-descriptive) appelée le MOF (MetaObject Facility [OMGf]),
permettant de décrire la structure des méta-modèles, d’étendre ou de modifier les
méta-modèles existants.
 Niveau M2 (MM)
Le niveau M2 (ou méta-modèle) définit le langage de modélisation et la grammaire de
représentation des modèles M1. Ce niveau contient le méta-modèle UML qui définit la
structure interne des modèles UML ainsi que les profils UML qui étendent le métamodèle. Les concepts définis par un méta-modèle sont des instances des concepts du
MOF.
 Niveau M1 (M)
Le niveau M1 (ou modèle) est composé de modèles d’informations. Il décrit les
informations de M0. Ce niveau contient les modèles UML, les PIM et les PSM. Les
éléments d’un modèle (M1) sont des instances des concepts décrits dans un métamodèle (M2).
 Niveau M0
Le niveau M0 (ou instance) correspond au monde réel. Il ne s’agit pas d’un niveau de
modélisation proprement dit. Ce niveau contient les informations réelles de
l’utilisateur, c’est une instance du modèle du niveau M1.
21
M3 : Méta-méta-modèle
MOF
M2 : Méta-modèle
Méta-Modèle (en UML)
M1 : Modèle
Modèle (en UML)
M0 : Monde réel
Système réel
Figure 1.6 : MOF et architecture à « 3+1 » niveaux
La figure 1.6 illustre l’utilisation de cette hiérarchie dans le cas de modèles décrits en UML.
Remarque : Dans la version 2.0 du standard MOF, il est indiqué que le nombre de niveaux de
modélisation utilisables est fléxible sur la base d’au moins 2 niveaux.
1.3.4. Autres approches basées sur les modèles
Il est à noter que l’approche ADM, bien qu’elle soit la plus importante, elle n’est pas la seule
à concentrer son activité sur l’utilisation des modèles. Nous pouvons trouver l’approche
CASE (Case Aided Software Engineering), l’approche MIC (Model-Integrated Computing)
[Davis03], les Software Factories [Greenfield04], etc, qui concentrent également leurs
activités sur les modèles.
1.4. Systèmes complexes
Un système complexe est un système composé d’un grand ensemble cohérent d’entités
hétérogènes, en interaction continue et simultanée. L’évolution et le comportement de ces
systèmes ne sont pas prédicables de façon directe, mais adoptent plutôt un comportement
dynamique dans le temps.
Un système complexe est caractérisé par les nombreuses relations qui s’établissent entre ses
éléments sur plusieurs niveaux hiérarchiques (le système est divisé en plusieurs soussystèmes). La complexité du système est dans la plupart des cas transparente pour l’utilisateur
final.
Un système complexe est caractérisé par les propriétés générées après l’interaction de ses
éléments. Des nouvelles propriétés, dites émergentes, peuvent alors se former.
22
La difficulté dans la conception de ce type de systèmes réside dans le niveau de sûreté de leur
fonctionnement. D. Harel et A. Pnueli [Harel85] décrivent les systèmes complexes comme
étant des systèmes transformationnels et réactifs. Les systèmes réactifs sont les plus
compliqués à cause de leur interaction permanente avec un environnement qui impose sa
vitesse, et rend le système difficile à concevoir.
La complexité du système dépend du nombre et de la nature de ses éléments qui peuvent être
très nombreux et variables au cours du temps. Elle dépend également de la nature de son
organisation interne, variable à son tour et liée aux relations entre ses éléments. Le dernier
point concerne le couplage avec l’environnement. Plus l’interaction du système avec son
environnement est forte, plus il dépend de ses propriétés incertaines et imprévisibles.
La figure 1.7 présente un aperçu de l’ensemble d’activités et leur entrelacement dans un
système complexe. Cette figure montre la complexité rencontrée lors de la construction d’une
application. La figure montre qu’il y a beaucoup d’activités à réaliser dans un ordre qui n’est
pas précisé.
23
Besoin
Réutilisation
Analyse
Evolution
Architecture
Séparation du
développement
Impact
Réalisation
Test de montée
en charge
Intégration
Maintenance
Solution
Mise en pré-production
Tests
Mise en production
Figure 1.7 : Aperçu d’une partie des activités à réaliser durant la construction d’un système
1.5. Modélisation multi-paradigmes
Dans un système complexe, les composants et les aspects qui décrivent la structure et le
comportement sont toujours exprimés dans plusieurs formalismes. L’idée multi-paradigmes
est née du besoin de traitement de l’hétérogénéité des modèles dans ces systèmes. Cette
hétérogénéité des modèles se décline selon quatre axes : hétérogénéité des domaines,
hétérogénéité des niveaux d’abstraction, hétérogénéité des vues et hétérogénéité des activités.
Nous appelons modélisation multi-paradigmes [Vangheluwe02] ou modélisation hétérogène
la discipline qui a pour objectif de faciliter l’automatisation et l’utilisation conjointe de
modèles hétérogènes pendant le cycle de développement, de manière à rendre possible un
raisonnement global sur l’ensemble de ces modèles. Il est important de savoir que par rapport
au cycle de développement, la modélisation multi-paradigmes est une tâche transversale,
c’est-à-dire qu’elle s’applique aux différentes activités du cycle de développement telles que
la spécification, la simulation, la vérification, la génération de code ou encore le test.
24
La notion de paradigme de modélisation désigne une façon de représenter le monde réel à
travers un ensemble de concepts. La notion de formalisme est différente de celle de paradigme
car le formalisme de modélisation est beaucoup plus précis. Un formalisme augmente
l’ensemble de ses concepts par une sémantique précise et un ensemble de règles d’écriture
(syntaxe concrète). Le formalisme désigne une convention de notation, et peut s’appuyer sur
un ou plusieurs paradigmes de modélisation. Un paradigme de modélisation à son tour peut
avoir différents formalismes associés.
Plusieurs approches sont disponibles pour traiter la diversité de formalismes :

L’approche super-formalisme
Cette approche ne peut être appliquée dans le cas des systèmes complexes. Elle
consiste à utiliser un seul formalisme générique pour un ensemble de langages de
modélisation et de formalismes nécessaires à la description d’un système. Parmi les
exemples de super-formalisme, nous trouvons Bond Graphs pour les domaines de la
mécanique et les domaines éclectiques et hydrauliques.

L’approche co-simulation
La co-simulation est une simulation simultanée de différents composants d’un système
et leurs interactions. Les aspects et les composants du système sont modélisés en
utilisant le formalisme et l’outil d’analyse adéquat. L’évaluation et la vérification du
comportement global du système sont effectuées généralement par une technique de
co-simulation. Chaque modèle de composants est simulé avec un simulateur
spécifique et l’interconnexion est assurée via des fonctions d’interface. L’échange de
données d'entrée/sortie s’effectue à travers l’environnement de co-simulation. Dans
cette approche, l'évaluation des propriétés globales d'un système ne peut se faire qu’au
niveau des entrées/sorties entre ses composants. Par conséquent, il est impossible
d’analyser le comportement global du système en utilisant les techniques des
méthodes formelles qui pourraient être effectuées pour chaque composant séparément.

L’approche multi-formalismes
La modélisation multi-formalismes englobe les deux autres approches: superformalisme et co-simulation. Dans cette approche, chaque composant est modélisé
dans le formalisme adapté mais le comportement global du système est évalué en
transformant les modèles des composants vers un formalisme unique.
Le choix du formalisme cible dépend des propriétés du système que nous souhaitons
étudier, et des propriétés qui doivent être préservées par les transformations.
Pour pouvoir appliquer la modélisation multi-formalismes, nous devons résoudre le
problème de l’interopérabilité et l’interconnexion des différents outils conçus pour les
25
formalismes utilisés dans le processus de conception. Dans certains cas, nous sommes
contraints d’utiliser des formalismes spécifiques au domaine, avec leurs outils de
modélisation et d’analyse de comportement. La réalisation de ces outils est
relativement complexe et coûteuse en termes de temps et d’argent. C’est à partir de ce
constat que les chercheurs ont été amenés à développer la méta-modélisation.
Pour la méta-modélisation, des outils d’une nouvelle génération ont été mis au point
pour que les formalismes de modélisation soient soumis eux-mêmes aux techniques de
modélisation. Ces outils sont appelés des méta-outils, ils permettent de générer des
outils personnalisés pour les formalismes, en se basant sur les informations de leurs
méta-modèles. En résumé, développer un outil pour supporter un formalisme revient à
définir son méta-modèle.
1.5.1. Techniques de modélisation multi-paradigmes
Le but de la modélisation multi-paradigmes est de faciliter et automatiser l’utilisation
conjointe de modèles pendant le cycle de développement. La modélisation multi-paradigmes
est traitée selon les approches suivantes :

Approches spécifiques
Plusieurs approches combinent des paradigmes particuliers afin de résoudre les
problèmes liés à l’hétérogénéité des temps et des modes de synchronisation. Nous
appelons ces approches « approches spécifiques » car elles permettent de résoudre le
problème de l’hétérogénéité de manière adaptée, en permettant la combinaison de
quelques paradigmes de modélisation particuliers.

Hétérogénéité des temps
Les approches de modélisation des systèmes hybrides ont incité à l’étude des
combinaisons basées sur le temps continu et le temps discret dans les modèles.

Hétérogénéité des modes de synchronisation
Plusieurs approches adressent les problèmes liés aux systèmes globalement
asynchrones ou localement asynchrones.
Dans le cadre de l’Ingénierie Dirigée par les Modèles, le nombre des langages et des
paradigmes de modélisation différents tend à croître exponentiellement. De ce fait,
nous ne pouvons considérer ces approches comme généralistes ou flexibles.
26

Spécification de la syntaxe et de la sémantique des langages de modélisation
Afin de pouvoir traiter un ensemble variable de langages de modélisation différents, il
est nécessaire de pouvoir capturer facilement la syntaxe et la sémantique des langages
de modélisation. La méta-modélisation est la clé de cette problématique car elle
permet de manipuler des langages de modélisation, et décrit en même temps la syntaxe
abstraite. Pour définir ensuite la sémantique des concepts ainsi spécifiés, il existe
différentes approches :

Kermeta
La technique Kermeta permet d’attribuer au langage une sémantique
exécutable en définissant des méthodes avec une sémantique impérative sur les
éléments du méta-modèle. Ainsi, chaque élément du méta-modèle est pourvu
d’une méthode d’exécution.
La méthode d’exécution d’un élément peut contenir des appels aux méthodes
d’exécution d’autres éléments avec lesquels il est en relation. Ces opérations,
définies au niveau méta permettent alors d’exécuter n’importe quel modèle qui
est conforme au méta-modèle du langage.

Semantic Units (SUs)
Littéralement « unité de sens », une Semantic Unit permet de donner une
sémantique opérationnelle à un langage lorsqu’elle est associée au métamodèle représentant la syntaxe abstraite de ce langage.
Une Semantic Unit est composée d’un modèle de données abstrait et un
ensemble de règles opérationnelles manipulant les éléments définis dans le
modèle de données.

Modèles de calcul (Models of Computation – MoCs)
Un modèle de calcul est un ensemble de primitives sémantiques communes à
plusieurs langages de modélisation.
Par exemple, les langages basés sur le principe des processus séquentiels
communiquant par rendez-vous font appel au même modèle de calcul
(Communicating Sequential Processes – CSP), même s’ils présentent des
variantes. De même, les langages basés sur le principe des flots de données
synchrones font appel à un autre modèle de calcul (Synchronous DataFlow –
SDF). En résumé, chaque modèle de calcul permet de caractériser une classe de
langages de modélisation.
27
L’avantage majeur de cette approche pour la modélisation multi-paradigmes
est que la syntaxe abstraite utilisée est unique : c’est donc la même pour tous
les modèles, la sémantique d’un modèle étant donnée par le domaine qui lui est
associé. Ainsi, deux modèles M1 et M2 syntaxiquement identiques pourront
avoir deux sémantiques différentes s’ils sont associés aux directeurs de deux
domaines différents D1 et D2.
Dans les approches que nous avons vues, un méta-modèle différent (une syntaxe abstraite
différente) peut être défini pour chaque langage de modélisation différent. Dans le contexte de
la modélisation multi-paradigmes, la composition de langages ainsi définie devra donc se faire
à la fois au niveau de la syntaxe et aussi au niveau de la sémantique. Le fait d’avoir une
syntaxe abstraite commune pour tous les langages facilite grandement la composition.
1.5.2. Axes de la modélisation multi-paradigmes
La modélisation multi-paradigmes est une activité multidisciplinaire dans sa définition. Elle
implique des intervenants dans multiples domaines tels que l’automatique, le traitement de
signal, l’ingénierie des langages de modélisation, la vérification formelle, etc. Dans cette
section, nous passons en revue les trois directions de recherche (figure 1.8) qu’occupe la
modélisation multi-paradigmes ainsi que le lien entre ces directions.



Modélisation multi-abstractions: La relation entre des modèles à des niveaux
d’abstraction différents.
Modélisation multi-formalismes: Le couplage et la transformation entre des modèles
décrits dans plusieurs formalismes.
Méta-modélisation: La description des formalismes et des langages de modélisation.
Niveaux Métas
Méta-méta- modèle
MétaMéta-modèle
modèle
Modèle
Bas
Haut
Niveaux d’abstraction
Formalisme1
Formalisme2
Formalismes
Figure 1.8 : Les trois axes de la modélisation multi-paradigmes
28

Modélisation multi-abstractions
Un système peut être défini par un nombre indéfini de modèles, chacun utilisé pour
aider à répondre à une question particulière sur le système. Les systèmes sont alors
représentés sous plusieurs aspects et à différents niveaux d’abstraction ou de détails.
Les différents niveaux d’abstraction sur lesquels les différents composants du système
sont distribués dépendent principalement des besoins des concepteurs. Un niveau
d’abstraction est désigné par les informations qu’il offre sur le système, les questions
auxquels il peut répondre, le degré de précision et les compétences des concepteurs
eux-mêmes.
Il ne faut pas confondre niveau d’abstraction et niveau de précision. Le niveau
d’abstraction est le fait de pouvoir masquer dans une vue certaines informations
inutiles pour les besoins de ce niveau. Par exemple, il n’est pas intéressant de montrer
les détails techniques de l’implémentation dans la vue des données.
Il est important de savoir que l’abstraction ne dégrade pas la complexité du système,
elle permet uniquement de la contourner pour appréhender des préoccupations
particulières. Les changements de niveaux d’abstraction impliquent l’utilisation de
différents formalismes. Ces changements peuvent être vus comme un processus de
transformation qui préserve certaines propriétés du système, généralement
comportementales.
Automatiser le processus de changement de niveaux d’abstraction est une nécessité
pour le développeur contraint à basculer d’un niveau d’abstraction à un autre pour
maîtriser et comprendre tous les détails du système. Pour atteindre ce but, il faut
modéliser ces transformations, puis utiliser ces modèles de transformation pour
automatiser les opérations d’abstraction ou de raffinement.
La figure 1.9 illustre l’opération de changement de niveaux d’abstraction dans la métamodélisation multi-paradigmes.
29
Niveaux Métas
Méta-méta-modèle
Méta- modèle
Modèle
Formalisme1
Bas
Haut
Abstraction
Raffinement
Formalismes
Figure 1.9 : Abstraction et raffinement dans la modélisation multi-paradigmes

Modélisation multi-formalismes
Il est très difficile, voire impossible de modéliser tous les aspects et tous les
composants d’un système avec un seul formalisme ou un seul modèle [Milner93]. Au
contraire, pour couvrir tous les aspects d’un système, nous avons besoin de construire
plusieurs modèles exprimés dans plusieurs formalismes différents.
Nous pouvons introduire plusieurs catégories de formalismes dans le processus de
développement. Le choix d’un formalisme adapté à un objectif spécifique est
orthogonal à la sélection du niveau d'abstraction dans lequel le modèle sera décrit. Les
changements de formalismes peuvent provoquer un changement de niveau
d’abstraction.
Les formalismes choisis dépendent des points suivants:
 Niveau d’abstraction.
 Disponibilité des données utilisées pour construire le modèle.
 Disponibilité d’analyseurs et simulateurs associés au formalisme.
 Objectif de la modélisation.
L’intérêt de la modélisation multi-formalismes est de permettre l’utilisation de
plusieurs formalismes pour gérer plusieurs modèles écrits dans ces formalismes [De
Lara02].
La figure 1.10 illustre l’opération de transformation de modèles dans la modélisation
multi-paradigmes.
30
Niveaux Métas
Méta-méta-modèle
Méta- modèle
Modèle
Formalisme1
Bas
Haut
Transformation
Formalisme2
Formalismes
Formalisme2
Figure1.10 : Transformation de modèle dans la modélisation multi-paradigmes

La méta-modélisation
La méta-modélisation est l’activité qui consiste à définir le méta-modèle d’un langage
de modélisation. Le méta-modèle est une représentation dans un niveau supérieur des
différents concepts utilisés dans les différents formalismes ou langages de
modélisation.
Les environnements de méta-modélisation permettent de définir des méta-modèles
pour les formalismes ou les langages de modélisation, et ensuite d’exploiter ces métamodèles pour générer des outils pour la modélisation.
La modélisation multi-paradigmes peut être interprétée comme une généralisation de
la modélisation multi-formalismes, augmentée par la méta-modélisation. Elle a pour
but de faciliter l’utilisation conjointe de modèles des systèmes décrits dans plusieurs
formalismes ou langages.
1.6. Les transformations de Graphes
Les graphes représentent un outil graphique et direct pour la visualisation de la structure
complexe d’un système. C’est un outil pratique et intuitif pour la modélisation. Les
diagrammes UML ou les réseaux de Petri sont des exemples très pratiques de graphes de
modélisation.
31
1.6.1. Définitions et propriétés des graphes
Un graphe est constitué d’un ensemble de sommets reliés par des arêtes. Deux sommets reliés
par une arête sont adjacents.
L'ordre d'un graphe est le nombre de ses sommets.
Le degré d'un sommet est le nombre d'arêtes dont ce sommet est une extrémité.
La figure 1.11 illustre un exemple de graphe non orienté, d’ordre 5.
Figure 1.11 : Graphe non orienté
Un sous-graphe d'un graphe G est un graphe G' composé de certains sommets de G, ainsi que
de toutes les arêtes qui relient ces sommets. La figure 1.12 illustre un exemple où le graphe
(b) est un sous-graphe du graphe (a).
a
c
c
b
e
d
f
f
(a)
e
d
(b)
Figure 1.12 : Graphe (a) et sous-graphe (b)
Un graphe orienté est un graphe dont les arêtes sont munies de directions : nous parlons alors
de l'origine et de l'extrémité d'une arête. Dans un graphe orienté, une arête est appelée« arc ».
La figure 1.13 illustre un exemple de graphe orienté.
32
1
3
2
4
Figure 1.13 : Exemple de graphe orienté
Un graphe étiqueté est un graphe orienté, dont les arcs sont munis d'étiquettes. Si toutes les
étiquettes sont des nombres positifs, on parle de graphe pondéré. La figure 1.14 illustre un
exemple de graphe orienté étiqueté.
Figure 1.14 : Exemple de graphe orienté et étiqueté
Un graphe attribué est un graphe qui peut contenir un ensemble prédéfini d’attributs.
1.6.2. Les relations entre les graphes

Homomorphisme
Un homomorphisme d’un graphe L vers un graphe G est une application
H : L → G qui préserve les arcs et les étiquettes.

Isomorphisme
Un isomorphisme entre deux graphes G et G’ est un homomorphisme bijectif
I: G → G’ (I-1 existe).
33

Homomorphisme de sous graphe
Pour les deux graphes L et G, un homomorphisme de sous graphe est un
homomorphisme totale de L vers G (tous les éléments de L sont tracés à des éléments
dans G)

Isomorphisme de sous graphe
Un isomorphisme de sous graphe de L vers G est un homomorphisme de sous graphe
total et injectif. Dans ce cas, L est un sous graphe de G et nous écrivons : L ⊆ G.

Occurrence
Il existe une occurrence de L dans G s’il existe un homomorphisme ou un
isomorphisme de sous graphe de L vers G.

Voisinage
L’expression voisinage de L est utilisée pour se rapporter aux nœuds et aux arcs reliant
l’occurrence de L et G.

Graphe de contexte
Un graphe de contexte est le graphe obtenu en enlevant l’occurrence de L et tous les
arcs de son voisinage à partir de G. De même, les arcs et les sommets de contexte sont
les arcs et les sommets du voisinage de L.
1.6.3. Principe de transformation de graphes
Les approches de réécriture classiques comme les grammaires de Chomsky ou la réécriture de
termes manquent d’expressivité. Les transformations de graphes ont évolué pour y remédier.
Le processus de transformation de graphes [Karsai04, Andries99, Rozenberg99] consiste en
l’application itérative d’une règle à un graphe. Chaque application de règle remplace une
partie du graphe par une autre suivant la définition de la règle. La mécanique de la
transformation de graphe fonctionne de la façon suivante : sélectionner une règle applicable
de l’ensemble des règles ; appliquer cette règle au graphe d’entrée ; rechercher une autre règle
applicable (réitération) jusqu'à ce qu’aucune règle ne puisse plus être appliquée. Cette
opération est basée sur un ensemble de règles respectant une syntaxe particulière, appelé
modèle de grammaire de graphe.
Un modèle de grammaire de graphe est une généralisation des grammaires de Chomsky. C’est
une composition de règles où chaque règle possède deux parties : une partie gauche (LHS :
Left Hand Side) et une partie droite (RHS : Right Hand Side). La partie gauche LHS
correspond au graphe d’entrée (appelé aussi Host Graph) [Rozenberg99]. La règle compare à
34
chaque fois qu’elle est invoquée son LHS avec le graphe sur lequel nous appliquons la
transformation. La règle remplace l’équivalent de son LHS dans le graphe à transformer par
sa partie droite RHS. Le RHS décrit la modification du host graph.
La figure 1.15 illustre le principe de déroulement de la grammaire dans le processus de
transformation de graphes.
Règle1
1
Règle2
2
Action initiale
Déroulement
Action finale
Règle n
N
Figure 1.15 : Principe d’exécution des règles
1.6.4. Grammaire de graphe
Une grammaire de graphe [Andries99] est généralement définie par un triplet:
GG = (P, S, T)
Où :



P : ensemble de règles.
S : un graphe initial.
T : ensemble de symboles.
Une grammaire de graphes distingue les graphes non terminaux, qui sont les résultats
intermédiaires sur lesquels les règles sont appliquées, des graphes terminaux sur lesquels on
ne peut plus appliquer aucune règle. Ces derniers sont dans le langage engendré par la
grammaire de graphe [Kerkouche08, Kerkouche09a]. Pour vérifier si un graphe G est dans le
langage engendré par une grammaire de graphe, il doit être analysé. Le processus d’analyse
va déterminer une séquence de règles dérivant G.
35
1.6.4.1. Principe de déroulement de règles
Une règle de transformation de graphe est définie par :
R= (LHS, RHS, K, glue, emb, cond)
• LHS graphe de partie gauche.
• RHS graphe de partie droite.
• Un sous graphe K de LHS.
• Une occurrence glue de K dans RHS qui relie le sous graphe avec le graphe de partie
droite.
• Une relation d’enfoncement emb qui relie les sommets du graphe de la partie gauche
et ceux du graphe de la partie droite.
• Un ensemble cond qui indique les conditions d’application de la règle.
L’application d’une règle R= (LHS, RHS, K, glue, emb, cond) à un graphe G produit en
résultat un graphe H suivant les cinq étapes suivantes :
1. Choisir une occurrence du graphe de partie gauche LHS dans G.
2. Vérifier les conditions d’application d’après cond.
3. Retirer l’occurrence de LHS (jusqu’à K) de G ainsi que les arcs pendillés (tous les arcs
ayant perdu leurs sources et/ou leurs destinations). Ce qui fournit le graphe de
contexte D de LHS qui a laissé une occurrence de K.
4. Coller le graphe de contexte D et le graphe de partie droite RHS suivant l’occurrence
de K dans D et dans RHS, c’est la construction de l’union de disjonction de D et RHS,
et pour chaque point dans K, identifier le point correspondant dans D avec le point
correspondant dans RHS.
5. Enfoncer le graphe de partie droite dans le graphe de contexte de LHS suivant la
relation d’enfoncement emb : pour chaque arc incident retiré avec un sommet v dans D
et avec un sommet v’ dans l’occurrence de LHS dans G, et pour chaque sommet v’’
dans RHS, un nouvel arc incident est établi (même étiquette) avec l’image de v et le
sommet v’’ à condition que (v’, v’’) appartient à emb.
L’application de R à un graphe G pour fournir un graphe H est appelée une dérivation directe
depuis G vers H à travers R, elle est dénotée par G ⇒ H.
Plusieurs formalismes permettent de représenter les règles de transformation. Une
transformation visuelle est illustrée dans la figure 1.16.
36
R1
LHS
RHS
Application de R1
Figure 1.16 : Application d’une règle de transformation
1.6.5. Système de transformation de graphes
On définit un système de transformation de graphes [Rozenberg99] comme un système de
réécriture de graphe qui applique les règles de la grammaire de graphe sur son graphe initial
de façon itérative jusqu’à ce que plus aucune règle ne soit plus applicable. La figure 1.17
illustre le principe du système de réécriture de graphes.
Règles de
transformation
Input
Graphe source
Input
Système de
transformation
Output
Graphe cible
Figure 1.17 : Système de réécriture de graphe
Parmi les avantages de cette approche :
 Les grammaires de graphes sont un formalisme visuel, formel et de haut-niveau pour
décrire les transformations.
 Les fondements théoriques des systèmes de réécriture de graphes aident à vérifier
certaines propriétés des transformations telles que la terminaison ou la correction.
37
En donnant les notions de règles et de dérivations directes comme étant les concepts de base
de la transformation de graphes, nous pouvons définir les systèmes de transformation de
graphes, les grammaires de graphes et la notion de langages engendrés.



Un système de transformation de graphes : Un ensemble P de règles.
Une grammaire de graphe : Un ensemble P de règles muni d’un graphe initial
S et d’un ensemble T de symboles terminaux.
Langage engendré : Soit un ensemble donné de règles P et un graphe G0 : Une
séquence de transformations de graphe successive : G0⇒ G1⇒ … ⇒ Gn est une
dérivation de G0 vers Gn par les règles de P. G0 est le graphe initial et Gn est le
graphe dérivé de la séquence de transformation. L’ensemble des graphes
dérivés à partir d’un graphe initial S en appliquant les règles de P qui sont
étiquetées par les symboles de T, est dit langage engendré par P, S et T, noté L
(P, S, T).
1.6.6. Approches et outils de transformations de graphes
Actuellement, plusieurs approches et outils ont été développés pour la transformation de
graphes, nous citons : VIATRA, ATOM3, GreAT, UMLX, BOTL, plugins d’Eclipse, etc.
Elles permettent toutes la génération d'un graphe orienté étiqueté cible à partir d’un autre
graphe source en utilisant une grammaire bien définie.

AToM3
AToM3 (A Tool for Multi-formalism and Meta-Modelling) [DeLara02] est un outil de
transformation de modèles écrit en Python. Cet outil sert pour la modélisation, la
méta-modélisation et la transformation de modèles en utilisant les concepts des
grammaires de graphes. La spécification de formalisme présente des règles qui
construisent les modèles. Ces modèles sont représentés dans un éditeur graphique.
AToM3 [AToM3] possède donc une couche de méta-modélisation qui lui permet une
modélisation graphique des différents formalismes. À partir de la méta-spécification
(établie dans le modèle entité-association), AToM3 génère un outil pour la
manipulation des différents modèles décrits dans le formalisme spécifié.

PROGRES
PROGRES [Schürr99, Ranger08] (Programmed Graph Rewriting Systems) figure
parmi les premiers outils à avoir permis les transformations de graphes. Il a été
développé en Allemagne à l’université d’Aachen. Cet outil repose sur l’approche
orientée logique des grammaires de graphes. Les règles sont décrites de manière
visuelle par une partie gauche et une partie droite.
38

FUJABA
FUJABA [Burmester04], (From UML to Java and Back Again) utilise UML comme
langage de modélisation visuel, et a pour but de fournir un environnement de
génération de code Java et de rétro-conception. FUJABA s’est développé et est devenu
actuellement une base pour plusieurs activités de recherche, notamment dans le
domaine des applications distribuées, les systèmes de bases de données ainsi que dans
le domaine de la modélisation et de la simulation des systèmes mécaniques et
électriques.

VIATRA2
VIATRA2 (Visual Automated model TRAnsformations) [Varró06] est un plugin
Eclipse développé en 2005 à Budapest. Le logiciel utilise un langage de modélisation
particulier pour représenter les modèles appelé VPM [Varró03]. Le développeur utilise
des motifs récursifs et des motifs de négations représentant les conditions
d’application négatives pour définir les règles de transformation. Cet outil permet
l’ordonnancement dans l’application des règles à l’aide d’une machine à états.

GReAT
GReAT (Graph Rewriting and Transformation) [Balasubramanian06] utilise
principalement une notation graphique pour définir les règles de transformation. Ces
transformations sont unidirectionnelles de plusieurs modèles sources vers plusieurs
modèles cibles. Ces modèles sont conformes à des méta-modèles spécifiés, et peuvent
être créés avec l’outil de méta-modélisation GME.
Cependant, certaines parties sont spécifiées textuellement comme les expressions
d’initialisation des attributs et les conditions d’application.

AGG
AGG (Attributed Graph Grammar system) [AGG06, Taentzer03] est un outil réalisé à
l'Université Technique de Berlin (Technische Universität Berlin) et développé depuis
1997.C’est l’un des outils de transformation de graphes les plus aboutis et les plus
cités dans la littérature.
AGG est écrit en langage de programmation Java. Il offre une interface graphique
permettant de construire les graphes et les règles de transformation, et de réaliser des
simulations pas à pas et quelques vérifications élémentaires. Les graphes considérés
sont orientés et possèdent des nœuds et des arcs étiquetés par des objets Java.
39

GME (Generic Modeling Environment)
GME [GME] pour Environnement de Modélisation Générique est une suite d’outils
pour la création de langages de modélisation et de modèles. La configuration se fait à
travers des méta-modèles qui spécifient le paradigme de modélisation du domaine
d’application.
Le méta-modèle est basé sur le diagramme de classe UML et la notation OCL.
GME s’intègre à l’environnement de développement Visual Studio et .NET 2003 de
Microsoft. La définition de la sémantique des langages de modélisation, et donc la
sémantique des modèles manipulés, n’est pas supportée directement : l’interprétation
sémantique des modèles doit être réalisée dans une phase aval.

GMT (Generative Modeling Technologies)
Le but du projet « Technologies de modélisation générative » [GMT] d’Eclipse est de
produire un ensemble de prototypes dans le domaine de l'Ingénierie Dirigée par les
Modèles (IDM).
Le projet de modélisation Eclipse concentre son activité sur l'évolution et la promotion
des technologies de développement basées sur les modèles au sein de la communauté
Eclipse, en proposant un ensemble unifié de plateformes de modélisation, d’outils et
des contrôle des normes.

EMF (Eclipse Modeling Framework)
Le projet EMF [EMF] est un plugin Eclipse. C’est une plateforme de modélisation et
de génération de code pour la construction d’outils et d'applications basés sur un
modèle de données structurées. À partir d'un modèle décrit dans la spécification XMI,
EMF fournit des outils et un support d'exécution pour produire un ensemble de classes
Java pour le modèle, avec un ensemble de classes particulières qui permettent de
visualiser et commander l’édition du modèle, et un éditeur de base.

GEF (Graphical Editing Framework)
La plateforme d’édition graphique GEF [GEF] appartient à Eclipse. GEF fournit une
technologie pour créer des éditeurs graphiques riches et des vues pour l’interface
utilisateur Eclipse Workbench.

GMF (Graphical Modeling Framework)
Le Runtime GMF [GMF] est une plateforme d'application pour créer des éditeurs
graphiques en utilisant EMF et GEF.
40
Le Runtime GMF offre de nombreuses fonctionnalités que l'on aurait à coder à la main
si nous utilisions EMF et GMF directement.





Un ensemble de composants réutilisables pour les éditeurs graphiques, tels que
l'impression, l’exportation d'images, les actions et les barres d'outils, etc.
Un modèle standardisé pour décrire les éléments des diagrammes qui séparent la
sémantique (domaine) de la notation des éléments (diagrammes).
Une infrastructure de commande qui lie les différentes commandes de la
plateforme utilisée par les EMF et GEF.
Une plateforme extensible qui permet aux éditeurs graphiques d’être ouverts et
extensibles.
ATL (Langage de Transformation ATLAS)
ATL est un outil et un langage de transformation de modèles sous l’environnement
Eclipse. Dans le cadre de l’Ingénierie Dirigée par les Modèles (IDM), ATL propose
une méthode pour produire un ensemble de modèles cibles à partir d’un ensemble de
modèles sources. Le programme de transformation est composé de règles qui
définissent la manière dont les éléments du modèle source sont traités et analysés afin
d’obtenir des éléments du modèle cible.

Java et l’environnement Eclipse
Le langage de programmation Java est un langage orienté objet où les codes et les
données sont manipulés dans une même classe. Cette manière de programmer facilite
l’écriture et la maintenance du code. On peut développer une partie d’un programme
sans qu’il soit nécessaire de connaître les détails d’implémentation des autres parties.
La sémantique du langage Java est indépendante de la plateforme et donc un
programme écrit en Java fonctionne de manière indépendante de l’architecture
matérielle. Le compilateur Java, dans notre cas Eclipse, compile le code source à
moitié pour obtenir un code intermédiaire bytecode. Le bytecode sera compilé en
langage machine lors de l’exécution par la machine virtuelle JVM (Java Virtual
Machine).
Pour développer l’outil de notre approche, nous avons utilisé Eclipse qui est un
environnement de développement multi-langages, extensible et polyvalent. Cet outil
est défini comme un EDI (Environnement de Développement Intégré) ou comme une
plateforme.
La figure 1.18 présente un aperçu de l’environnement Eclipse.
41
Figure 1.18 : Environnement Eclipse
1.7. Conclusion
Ce chapitre nous place dans le contexte de cette thèse. Nous avons défini les principes de base
de l’IDM et le rôle central des modèles. Nous avons également discuté les difficultés
concernant leur manipulation, leur qualité et leur adaptation. Nous avons survolé les
techniques de transformation et de traitement de ces modèles. Nous avons également présenté
la méta-modélisation dans le domaine IDM et précisément l’approche ADM, avec ce qu’elle
apporte aux systèmes complexes. Dans la deuxième partie de ce chapitre, nous avons étudié
les concepts de la modélisation multi-paradigmes et les transformations de graphes. À la fin,
nous avons passé en revu quelque approches et outils pour la transformation de modèles.
42
Chapitre 2 :
Modélisation semi-formelle avec UML 2.0
43
Chapitre 2
Modélisation semi-formelle avec UML 2.0
2.1. Introduction
La tâche de conception des systèmes a toujours besoin d’un langage ou d’une méthode de
spécification et de modélisation pour créer et analyser des modèles et communiquer avec les
collaborateurs et les clients.
L’approche orientée objet considère le logiciel comme une collection d’objets dissociés et
identifiés, définis par des propriétés. Une propriété est soit un attribut soit une entité
élémentaire comportementale de l’objet. La fonctionnalité du système émerge alors de
l’interaction entre les différents objets qui le constituent. L’une des particularités de cette
approche est qu’elle encapsule les données et leurs traitements associés au sein d’un unique
objet. Un objet est caractérisé par plusieurs notions, et c’est dans ce contexte que nous
présentons quelques éléments du langage UML 2.0 (Unified Modeling Language) [UML2],
qui s’est imposé comme un standard que rencontrent tous les développeurs dans l’industrie du
génie logiciel.
2.2. Historique des méthodes de conception
De nombreuses méthodes de développement ou d’analyse de logiciel ont été développées
depuis les années 80. Ces méthodes apportent à chaque fois des progrès considérables et des
solutions à des problèmes ou des contraintes différentes.
Ces méthodes correspondent à un ou plusieurs moyens (plus ou moins formels) de notation ou
représentation des résultats. Ceux-ci peuvent être graphiques (diagrammes synoptique, plans
physique d’un réseau, organigrammes..) ou textuels (expressions d’un besoin en langage
naturel, listings du code source..).
Dans les années 90, un certain nombre de méthodes orientées objet ont émergé, en particulier
les méthodes :
– OMT de James RUMBAUGH [Rum96].
– BOOCH de Grady BOOCH [Boo94].
– OOSE (Object Oriented Software Engineering) de Ivar JACOBSON à qui on doit
les diagrammes de cas d’utilisation [JCJO92].
44
En 1994, on comptait plus de 50 méthodes orientées objet. C’est dans le but de remédier à
cette dispersion que les chercheurs de la méthode orientée objet ont décidé de se regrouper
autour d’un standard.
En octobre 1994, Grady Booch et James Rumbaugh se sont réunis au sein de la société
RATIONAL dans le but de travailler à l’élaboration d’une méthode commune qui intègre les
avantages de l’ensemble des méthodes reconnues, en corrigeant les défauts et en comblant les
manques. Lors de la conférence OOPSLA’95 (Object Oriented Programming Systems,
Languages and Applications, la grande conférence de la programmation orientée objet), ils
présentent UNIFIED METHOD V0.8. En 1996, Ivar Jacobson les rejoint. Leurs travaux ne
visent plus à constituer une méthode, mais un langage.
Leur initiative a été soutenue par de nombreuses sociétés, que ce soit des sociétés de
développement (dont Microsoft, Oracle, Hewlet-Packard, IBM – qui a apporté son langage de
contraintes OCL, etc.) ou des sociétés de conception d’ateliers logiciels.
Un projet a été déposé en janvier 1997 à l’OMG en vue de la normalisation d’un langage de
modélisation. Après amendement, celui-ci a été accepté en novembre 97 par l’OMG sous la
référence UML-1.1. La version d’UML en cours à la fin 2006 est UML 2.0 et les travaux
d’amélioration se poursuivent.
On ne peut donc considérer UML comme étant uniquement un outil intéressant, mais il est
également une norme et un standard en technologie à objets à laquelle se sont liés tous les
grands acteurs du domaine, qui ont d’ailleurs contribué à son élaboration.
La figure 2.1 montre l’historique de constitution du langage UML.
Temps
Fin 2004
UML 2.0
Révision 9/97
UML 1.1
Soumission à l’OMG 1/97
UML 1.0
Version béta OOPSLA 96
UML 0.9
OOPSLA95
OCL (IBM)
Unified Method 0.8
…
Booch’93
OMT-2
Booch
OMT
OOSE
Figure 2.1 : Historique de constitution du langage UML
45
2.3. Méthode versus Langage de modélisation
Une méthode de conception est définie comme une démarche d’organisation qui a pour
objectif de résoudre un problème spécifique. La méthode de conception utilise un formalisme
ou un langage pour exprimer le résultat.
UML n’est pas une méthode, mais un langage. Il peut donc être utilisé sans prendre en compte
la méthode de conception adoptée par l’entreprise.
La société RATIONAL (principale actrice d’UML) propose son propre processus de
conception appelé OBJECTORY [JBR97a] qui est entièrement basé sur UML. UML facilite
donc la communication entre clients et développeurs, ainsi qu’entre équipes de développeurs.
De plus, sa sémantique semi-formelle accélère le développement des outils graphiques
d’atelier de génie logiciel, permettant ainsi d’aller de la spécification (haut-niveau) en UML
vers la génération de code (JAVA, C++, ADA, ...). Cela autorise l’échange électronique de
documents qui deviennent des spécifications exécutables en UML.
UML ne se contente pas de composer des formalismes déjà existants, mais apporte également
de nouvelles approches telles que la modélisation d’architectures distribuées ou la
modélisation d’applications temps-réel avec gestion du multitâches, etc.
2.4. Avantages de la modélisation Objet
La différence entre une approche fonctionnelle et une approche objet n’est pas d’ordre logique
mais d’ordre pratique. L’approche objet est une approche orientée donnée. Elle peut
également être vue comme fonctionnelle car les méthodes d’un objet sont des fonctions.
L’évolution des besoins dans une approche structurée engendre des situations chaotiques dans
le système. Une modification de données implique une modification d’un nombre important
de fonctions éparpillées et difficiles à identifier dans la hiérarchie de cette composition.
Contrairement à l’approche structurée, dans l’approche objet une évolution des besoins se
traduit par un changement de l’interaction des objets. S’il faut apporter des modifications aux
données, seul l’objet correspondant sera affecté avec ses méthodes.
Nous pouvons aussi citer d’autres avantages tels que :
-La qualité du système qu’offre l’aspect orienté objet et la modularisation qui permet de
maîtriser sa production et son évolution.
-La conception objet assure une continuité et une traçabilité entre les différents modèles. De
plus, la génération de code résulte de façon naturelle.
2.5. Langage de modélisation UML
UML est un langage de modélisation utilisant une représentation graphique basée sur les
diagrammes. L’usage d’une représentation graphique est un atout car les diagrammes effacent
les ambigüités dans les modèles. Un dessin exprime de manière plus naturelle et plus lisible
ce qu’un texte peine à réaliser même lorsqu’il est bien commenté. Cependant, UML souffre
46
d’un manque de sémantique formelle. Ceci empêche la vérification de la cohérence des
composants du système et du comportement de ce dernier.
2.5.1. Les vues du langage UML 2.0
Il est impossible de donner une représentation graphique complète d’un logiciel, ou de tout
autre système complexe, mais il est possible de donner sur un tel système des vues partielles,
comme montré dans la figure 2.2, pour avoir une idée utilisable en pratique sans risque
d’erreur grave.
Modèle fonctionnel
Q
Que fait le système
Aspect fonctionnel :
Diagrammes de cas
d’utilisation
Aspect dynamique :
Diagrammes d’interactions
Séquencement des
actions dans le système
Modèle structurel (objet)
Q
Modèle temporel
Sur quoi agit le système
Aspect statique : Diagrammes de
classes et d’objets
Q
Figure 2.2 : Les aspects d’un système
Les vues UML [FrB05] permettent de mettre en évidence les différents aspects d’un système
que nous souhaitons réaliser. UML 2.0 comporte ainsi treize types de diagrammes
représentant autant de vues distinctes mais complémentaires pour représenter des concepts
particuliers du système d’information. Ils se répartissent en trois grands groupes :
a - La vue structurelle, ou statique : Cette vue modélise la structure des différentes classes
d’une application orientée objet, elle réunit :
o
o
o
o
o
o
Diagramme de classes.
Diagramme d’objets.
Diagramme de composants.
Diagramme de déploiement.
Diagramme de paquetages.
Diagramme de structures composites.
47
b - La vue comportementale: Cette vue est fonctionnelle, elle est plus algorithmique et
orientée « traitement », et vise à décrire l’évolution (la dynamique) des objets complexes du
programme tout au long de leur cycle de vie. De leur création à leur destruction, les
changements d’états des objets sont guidés par les interactions avec les autres objets. Cette
vue est présentée avec les diagrammes suivants :
o Diagramme de cas d’utilisation.
o Diagramme d’activités.
o Diagramme d’états-transitions.
En général, les diagrammes d’états à eux seuls ne permettent pas de faire apparaître les
problèmes spécifiques posés par la synchronisation des processus en concurrence pour assurer
la cohérence du comportement et l’absence d’inter-blocage.
c- La vue dynamique ou d’interaction : Pour montrer l’interactivité, des diagrammes
traitent les interactions entre les différents acteurs/utilisateurs et le système sous forme
d’objectifs à atteindre d’un côté, et sous forme chronologique de scénarios d’interaction
typiques de l’autre. Ces diagrammes sont les suivants :
o
o
o
o
Diagramme de séquence.
Diagramme de communication.
Diagramme global d’interactions.
Diagramme de temps.
La figure 2.3 montre un concept UML 2.0 avec le lien entre les différentes vues et les
abstractions.
Vues
Structure
Comportement
Fonctionnalités
Cohérence
Abstraction
Code
Figure 2.3 : Différentes vues dans un concept UML 2.0
48
2.5.2. Interprétation de la conception et de l’analyse à travers la notation UML 2.0
UML 2.0 n’offre pas une méthode pour l’analyse et la conception, mais un langage qui permet
d’exprimer le résultat de ces étapes. Il est à noter que UML 2.0 ne doit pas être considéré
comme un outil graphique pour les applications Java ou autres, il doit au contraire être
considéré comme un langage à part entière, car il définit sa propre sémantique orientée objet.
Les différences entre l’analyse et la conception en UML 2.0 ne sont autres que les différences
de niveau de détails dans les diagrammes utilisés. Le tableau 2.1 présente ces différences.
Diagramme de classes de conception
Diagramme de classes d’analyse
Nous trouvons les classes qui décrivent des Les seules classes servent à décrire des objets
objets concrets du domaine modélisé, et aussi concrets du domaine modélisé.
toutes les classes utilitaires destinées à
assurer le fonctionnement du logiciel.
Tous les attributs et toutes les méthodes
doivent apparaître de façon détaillée, avec
tous les types de paramètres et les types de
retour.
Nous pouvons nous contenter de faire
apparaître juste la dénomination des classes,
avec parfois le nom de quelques attributs et
méthodes
quand
ceux-ci
découlent
naturellement du domaine modélisé.
Diagramme de séquence de conception
Diagramme de séquence d’analyse
Les échanges entre classes sont exprimés Les communications entre les principaux
sous forme d’appels de méthodes dont les objets sont écrites sous forme textuelle, sans
signatures sont totalement explicites.
se soucier de la forme que prendront ces
échanges lors de la réalisation du logiciel.
Tableau 2.1 : Tableau comparatif entre diagrammes dans la conception et l’analyse
2.5.3. Diagrammes UML 2.0
UML 2.0 n’est pas une méthode mais un langage graphique qui permet de représenter et de
communiquer les divers aspects d’un système d’information par le biais de diagrammes et
commentaires. Pour une modélisation, ces diagrammes ne sont pas nécessairement tous
produits. Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes d’activités, de cas
d’utilisation, de classes, d’objets, de séquence et d’états-transitions. Les diagrammes de
composants, de déploiement et de communication sont surtout utiles pour la maîtrise d’œuvre,
ils permettent de formaliser les contraintes de la réalisation et la solution technique.
49
 Diagramme de cas d’utilisation
Ce diagramme a pour objectif d’assurer le lien entre l’utilisateur et les objets du système. Ce
diagramme représente la structure des grandes fonctionnalités nécessaires aux utilisateurs du
système.
 Diagramme de classes
Ce diagramme est considéré comme le diagramme le plus important dans le développement, il
représente l’architecture conceptuelle du système : il décrit les classes que le système utilise,
ainsi que les liens d’héritage ou d’agrégation.
 Diagramme d’objets
Le diagramme d’objets complète un diagramme de classes en le justifiant par des exemples
d’utilisation. Il est par exemple utilisé pour vérifier l’adéquation d’un diagramme de classes à
différents cas possibles.
 Diagramme d’états-transitions
Le diagramme d’états-transitions représente l’évolution des objets appartenant à une même
classe. La modélisation du cycle de vie est essentielle pour représenter la dynamique du
système.
 Diagramme d’activités
Le diagramme d’activités est un diagramme comportemental pour la représentation de
l’enchaînement et la modélisation du flot de contrôle entre les activités.
 Diagramme de séquence et de communication
Les diagrammes de séquence sont la représentation graphique des interactions entre les
acteurs du système. Ils représentent le séquencement chronologique des opérations réalisées
en indiquant les objets que l’acteur va invoquer. On peut représenter les mêmes opérations par
un diagramme de communication. Un diagramme de séquence et un diagramme de
communication sont considérés comme deux vues différentes mais logiquement équivalentes
(on peut construire l’une à partir de l’autre) d’une même chronologie. Ce sont des
diagrammes d’interaction.
2.5.4. Diagrammes d’états-transitions
Le diagramme d’états-transitions décrit à travers un automate à états finis le comportement
interne d’un objet. Il présente les séquences possibles d’états et d’actions qu’une instance de
classe (objet) peut prendre au cours de son cycle de vie en réaction à des événements discrets
(de type signaux, invocations de méthode).
Le diagramme d’états-transitions est l’unique diagramme UML 2.0 qui offre une vision
complète et non-ambiguë de tous les comportements de l’élément qu’il représente. De ce fait,
50
on ne peut obtenir une vision globale du système à travers ce type de diagrammes car ils ne
s’intéressent qu’à un seul élément du système, indépendamment de son environnement.
Dans la figure 2.4, un exemple d’un diagramme d’états-transitions nous permet de visualiser
les différents états d’une partie de jeu vidéo.
Figure 2.4 : Diagramme d’états-transitions simplifié d’une partie d’un jeu vidéo
2.5.4.1. Caractéristiques d’un diagramme d’états-transitions
Un diagramme d’états-transition rassemble et organise des états et des transitions avec les
événements correspondants aux changements d’états.
 Les états : Durant son cycle de vie, un objet passe par une série d’états. Un état peut
être vu comme une période dans laquelle l’objet attend un événement ou accomplit
une activité.
o Les états simples sont représentés comme suit (figure 2.5) :
État simple
Figure 2.5 : Syntaxe d’un état simple
Le nom de l’état est unique et doit être spécifié dans le rectangle.
o Les états initiaux et les états finaux : Les états initiaux et les états finaux sont
des pseudos états qui indiquent le début et la fin du diagramme d’étattransition. Ils sont représentés comme suit (figures2.6 et2.7) :
51
Figure 2.6 : Syntaxe d’un état initial
Figure 2.7 : Syntaxe d’un état final
 Les événements : L’événement est une tâche qui s’exécute dans le système. Les
réactions par rapport à cet événement doivent être modélisées dans le diagramme
d’états-transitions. Les événements sont classés en quatre types :
o
o
o
o
Des événements de signal.
Des événements d’appel (call).
Des événements de changement (change).
Des événements temporels.
 Les transitions : Une transition traduit la réaction d’un objet à l’occurrence d’un
événement. Elle indique qu’un objet dans un état peut entrer dans un autre état et
exécuter des activités.
Le même événement peut être le déclencheur de plusieurs transitions quittant un même
état. Chaque transition avec le même événement doit avoir une condition de garde
différente (à cause de l’indéterminisme).
La figure 2.8 montre un exemple d’un diagramme d’états-transitions d’un objet
« Facture » avec tous les états et transitions provoquant le changement de ses états à
travers des événements.
52
Passer commande()
Créée
Paiement()
Réglée
Envoyer_Facture()
Imprimée
Envoyée
Imprimer_Facture()
Figure 2.8 : Diagramme d’états-transitions d’un objet « Facture »
2.5.4.2. Les diagrammes d’états-transitions de Harel
Les diagrammes d’états-transitions de Harel [Harel 85] permettent la modélisation des superétats, régions orthogonales et les activités dans le cadre d’un état. Les diagrammes d’étatstransitions de Harel offrent un nouveau type d’états appelés les états composites ou les
superclasses.
Cette structure évite les situations d’explosions combinatoires du nombre d’états dans le cas
des systèmes complexes. Les diagrammes de Harel permettent de modéliser plusieurs
diagrammes d’états-transitions inter-fonctionnels. Chacune de ces machines peut avoir des
transitions internes sans impliquer la totalité du diagramme.
La figure 2.9 montre un exemple de diagramme d’états-transitions, où l’état S est un état
composite.
Figure 2.9 : Exemple d’un diagramme d’états-transitions de Harel
53
2.5.4.3. État composite dans un diagramme d’états-transitions
Un état composite contient plus d’une région, et c’est pour cela que nous l’appelons état
orthogonal. Un état composite ne contenant qu’une seule région et un état non orthogonal.
Lorsqu’un état orthogonal est actif, un sous-état de chaque région est automatiquement actif.
L’objectif de cette composition par états composites permet le développement d’une
spécification par raffinement. Nul besoin de représenter les états simples à chaque fois que
l’état composite est invoqué. Il existe une manière dans la notation pour indiquer que l’état est
composite, présentée dans la figure 2.10.
Composer
numéro
Figure 2.10 : Syntaxe d’un état composite
La figure 2.11 présente un exemple d’un état composite pour la modélisation de la
composition d’un numéro de téléphone.
Composer numéro
Début
Numéroter
Chiffrer(n)
Numéro_valide()
Figure 2.11 : Exemple d’un état composite dans l’opération de composition d’un numéro de
téléphone
2.5.4.4. Les transitions dans un diagramme d’états-transitions
Une transition atteint un état composite en ciblant son état initial. Si la transition démarre d’un
état composite, elle implique automatiquement tous les états qu’elle contient. Cette relation
est transitive : la transition est franchissable depuis tous les états contenus dans l’état
composite, quelle que soit sa profondeur. Ceci n’empêche pas que des transitions ciblent des
états de différents niveaux d’imbrication, en traversant les limites des états composites.
Nous présentons dans la figure 2.12 un exemple de configuration complexe de transitions.
Depuis l’état ‘’ état1 ‘’, la réception de l’événement ‘’ event1 ‘’ produit la séquence
54
d’activités :‘’QuitterE11, QuitterE1, action1, EntrerE2, EntrerE21, Initialiser(), EntrerE22 ‘’,
et place le système dans l’état ‘’ état22 ‘’.
Event/action1
Initialiser ()
Figure 2.12 : Exemple de transitions dans un diagramme d’états-transitions
2.5.4.5. La concurrence dans un diagramme d’états-transitions
Les diagrammes d’états-transitions permettent de décrire la concurrence d’une manière très
efficace grâce à l’utilisation des états orthogonaux (chaque région de l’état orthogonal
représente un flot d’exécution). Graphiquement, dans un état orthogonal, les différentes
régions sont séparées par un trait horizontal en pointillé dans l’état composite.
Chaque région peut posséder un état initial et un état final. Une transition qui atteint la limite
d’un état composite orthogonal est équivalente à une transition qui atteint les états initiaux de
toutes ses régions concurrentes.
Pour que l’état composite soit considéré comme terminé, toutes les régions concurrentes
doivent atteindre leurs états finaux.
La figure 2.13 montre un exemple de concurrence dans un état composite orthogonal. La
préparation de boissons dans un distributeur se fait en parallèle au rendu de monnaie.
55
Servir boisson et rendre monnaie
Préparer boisson et rendre monnaie
Préparer
Terminer
Goblet attente
Rendre monnaie
Figure 2.13 : Exemple d’utilisation de transitions complexes et concurrence
2.5.5. Les diagrammes de séquence
Les diagrammes de séquence contiennent des informations concernant les messages échangés
entre les entités du système dans le temps. La notion de temps est représentée dans le
diagramme de séquence de manière explicite, sur des lignes verticales, s’écoulant du haut en
bas pour montrer l’ordre chronologique des échanges. Ces lignes sont appelées des lignes de
vie.
Une ligne de vie est représentée par un rectangle étiqueté par un nom de classe suivi d’une
ligne verticale. Les messages quant à eux, définissent la communication établie entre les
lignes de vie. Ils peuvent communiquer un envoi de signal, une invocation d’une opération ou
la création ou la destruction d’une instance d’une classe.
Les messages dans un diagramme de séquence sont par défaut asynchrone, mais ces
diagrammes permettent aussi de représenter des messages synchrones. Dans le cas synchrone,
l’émetteur reste bloqué le temps que dure l’opération.
Les messages synchrones et asynchrones sont représentés graphiquement comme montré dans
les figures 2.14 et 2.15.
56
Obj1 :
Obj2 :
Figure 2.14 : Syntaxe d’un message asynchrone
Obj1 :
Obj2 :
Figure 2.15 : Syntaxe d’un message synchrone
La réception d’un message est généralement suivie de l’exécution d’une méthode d’une
classe. La syntaxe du message permet de véhiculer un argument aux méthodes en cas de
besoin.
2.5.5.1. Opérateurs dans les diagrammes de séquence
 Opérateur alt
L’opérateur alternative ou alt est un opérateur conditionnel à plusieurs opérandes.
Chaque opérande a une condition de garde, et l’absence de condition de garde
implique une condition vraie. La condition Sinon est vraie si aucune autre condition
n’est vraie. Lorsque plusieurs opérandes prennent une valeur « vrai », nous sommes
confrontés à une situation indéterministe.
La figure 2.16 montre un exemple d’un diagramme de séquence avec l’opérateur alt.
SD_banque
bank : Bank
ob : Ob
Login ()
alt
Deconnecte()
Passwok
else
assert
Compte>0
NumCompte()
Figure 2.16 : Représentation d’un choix dans un diagramme de séquence
57
 Opérateur opt
L’opérateur option, ou opt comporte un opérande et une condition de garde associée.
Le sous fragment ne s’exécute que si la condition de garde est vraie (true).
 Opérateur loop
Un fragment étiqueté de loop contient un sous-fragment, une information sur la valeur
minimum et maximum des itérations, ainsi qu’une condition de garde. Dans la figure
2.17, nous montrons un exemple d’utilisation de l’opérateur de boucle dans un
diagramme de séquence.
SD_démarrer_train
:Conducteur
:Train
Porte(i) :Porte
Fermer_porte()
Loop(1,n)
Fermer ()
Figure 2.17 : Représentation d’une boucle dans un diagramme de séquence
 Opérateur par
L’opérateur parallèle dans un diagramme de séquence nécessite au moins deux sousfragments exécutés simultanément. La figure 2.18 illustre le parallélisme dans un
diagramme de séquence.
58
SD_microwave
Per1 :Personne
open :MicrowaveOpen
CookFood()
Par
Cook()
Rotate()
Food()
Figure 2.18 : Exemple d’objet effectuant deux tâches en parallèle
 Opérateur strict
L’opérateur strict sequencing ou strict implique au moins deux sous-fragments qui
s’exécutent selon leur ordre d’apparition dans un fragment combiné. Ceci est surtout
utile dans le cas de deux parties qui n’ont pas de ligne de vie commune dans un
diagramme.
La figure 2.19 montre un exemple de l’utilisation de l’opérateur strict.
59
SD_décollage_avion
:TourDeControle
Strict
: Pilote
: Avion
ref
Contrôler check list
ref
Procédure de décollage
Figure 2.19 : Exemple de l’utilisation de l’opérateur strict dans un diagramme de
séquence
Remarque : On appelle « utilisation d’une interaction » le fait de référencer des
interactions déjà définies. Cela permet de réutiliser les définitions dans des contextes
différents.
2.6. Conclusion
Dans ce chapitre, nous avons parlé de la modélisation orientée objet comme une approche
ayant fait ses preuves. Nous avons rappelé les différences entre une méthode de conception et
un langage de modélisation en mettant l’accent sur UML 2.0 qui est souvent confondu avec
les méthodes de conception. Les vues UML 2.0 ont été montrées à travers les treize
diagrammes faisant d’UML 2.0 le langage de modélisation de référence. Les deux
diagrammes qui intéressent le sujet de cette thèse, et qui sont les diagrammes de séquence et
les diagrammes d’états-transitions, ont été détaillés dans la deuxième partie de ce chapitre.
60
Chapitre 3 : Méthodes formelles et modèle
GSPN
61
Chapitre 3
Méthodes formelles et modèle GSPN
3.1. Introduction
La dernière décennie a été marquée par une percée technologique importante dans
l’informatique et dans les réseaux de communication. Elle a poussé à la mise en place
d’applications de plus en plus complexes et de plus en plus sophistiquées. Ces dernières se
basent sur des systèmes distribués qui prennent en compte des aspects "temps-réel", dont il est
important de garantir et le comportement, en termes de propriétés et de performances
fonctionnelles, mais également la sûreté de fonctionnement. L’obtention de cette garantie
passe inévitablement par l’utilisation de modèles formels qui permettent d’exprimer et
d’analyser les mécanismes fondamentaux des systèmes distribués (parallélisme,
synchronisation, choix, partage de ressource, etc.).
Maîtriser la complexité qui s'accroît au fur et à mesure de l’avancement du développement
des systèmes complexes n’est pas une tâche facile. Une modélisation inappropriée peut
engendrer des dysfonctionnements aux conséquences dangereuses sur la sûreté et sur le
fonctionnement du système. Les modèles devront, de ce fait, être vérifiés ensuite validés. La
modélisation par niveaux présente l’avantage de créer la séparation des différentes
préoccupations impliquées dans le cycle de développement et ainsi, pouvoir exprimer à
chaque niveau et selon les besoins relatifs à sa conception, autant d’informations que
nécessaires.
Avant de valider chaque modèle, le développeur se doit d’assurer des propriétés de sûreté du
fonctionnement du système, en particulier lors des premières phases de la conception. C’est
pour cette raison qu’il fait appel, pour l’analyse, aux techniques formelles afin de comparer
les résultats issus de ces modèles aux exigences émises par le client.
L’IDM introduit les méthodes formelles dans la conception des systèmes en définissant des
langages de méta-modélisation, ces derniers décrivent tous les aspects structurels du système
voulu. La transformation de modèles combine ces aspects pour générer des modèles formels.
Ce sont au final ces modèles qui serviront, par des techniques formelles, à la vérification et la
validation.
Ce chapitre est une introduction aux méthodes formelles employées pour prévenir des erreurs
de conception des systèmes complexes. Ici, l’utilisation des méthodes formelles est vivement
encouragée. Leur intégration à l’Ingénierie Dirigée par les Modèles (IDM) sera discutée plus
loin, en mettant l’accent sur les réseaux de Petri, une technique formelle couramment utilisée.
62
3.2. Méthodes formelles
Les méthodes formelles [Wing90] sont des techniques de raisonnement mathématique
utilisées pour démontrer la validité des systèmes. Ces méthodes sont basées sur des
descriptions mathématiques formelles, donc sur des sémantiques claires et rigoureuses.
L’avantage de ces méthodes réside dans le fait qu’elles permettent d’obtenir des niveaux
d’évaluation d’assurance élevés (absence d’incohérences, de contradictions et de failles). Ces
méthodes sont généralement coûteuses, en temps et en ressources, et c’est d’ailleurs pour cela
qu’elles sont réservées aux systèmes critiques où l’utilisation de tels outils est incontournable.
3.3. Langages formels
Pour définir une spécification d’un système, une méthode formelle utilise un langage formel
doté d’une sémantique mathématique rigoureuse [Petit99, Benzaken91], basée sur des règles
d’interprétation et des règles de déduction.
Les règles d’interprétation garantissent l’absence d’ambigüité d’interprétation (dans un
langage informel ou semi-formel, une description peut avoir plusieurs interprétations). Les
règles de déduction raisonnent sur des spécifications afin de détecter les manques et les
inconsistances, et aussi pour vérifier des propriétés attendues.
3.4. Techniques d’analyse
Il existe plusieurs méthodes d’analyse des systèmes complexes, elles permettent de garantir
leur bon fonctionnement ou alors limiter les risques liés à leur performance. Parmi ces
méthodes nous citons :
 La vérification
La vérification comprend l’ensemble des activités d’inspection, de test, de simulation, de
preuve automatique ainsi que les autres techniques qui permettent d’affirmer ou non la
question «Le système a t-il été conçu correctement?». Elle est définie selon l’ISO comme "la
confirmation par examen et apport de preuves tangibles (informations dont la véracité peut
être démontrée, fondée sur des faits obtenus par observation, mesures, essais ou autres
moyens) que les exigences spécifiées ont été satisfaites" [ISO 8402].
 La validation
La validation compare le système réalisé aux besoins exprimés par ses utilisateurs. Cette tâche
permet d’évaluer le système développé en répondant à la question : «Sommes-nous en train de
développer le bon système?». L’ISO définit la validation comme "La confirmation, par
examen et apport de preuves tangibles, que les exigences particulières pour un usage
spécifique prévu sont satisfaites. Plusieurs validations peuvent être effectuées s’il y a
différents usages prévus" [ISO 8402].
63
 La qualification
La qualification assure que le modèle peut être utilisé dans la communication sans ambigüité
d’interprétation entre les activités du projet et les acteurs.
 La certification
La certification nécessite l’intervention d’un organisme indépendant qui assurera le respect
des normes par le modèle, et qui reconnaîtra sa pertinence, sa rigueur et ses qualités pour une
éventuelle réutilisation, voire pour l’établissement d’un référentiel générique à son domaine.
3.5. Classification des méthodes formelles
Selon J.M. Wing [Wing90], les méthodes formelles peuvent être classées en trois types:
 Méthodes orientées données: Ces méthodes décrivent les états du système.
 Méthodes orientées opérations: Ces méthodes décrivent le fonctionnement et le
comportement du système par le biais d’axiomes.
 Méthodes Hybrides: Ces méthodes combinent les deux premiers types de méthodes.
La figure 3.1 donne une classification des méthodes formelles selon le type d’approche
qu’elles utilisent, axiomatique, basée sur les états ou bien hybride.
64
Les méthodes formelles
Approche basée sur
les états
Approche axiomatique
Approche
algébrique
Approche
logique
Approche
par modèle
abstrait
Approche hybride
ACT ONE
Approche
dynamique
CCS
LOTOS
OBJ
PVS
LPG
Isabelle/HOL
VDM
Réseaux de Petri
CASL
Coq
Z
Automate temporel
…
…
B
CSP
…
…
…
Figure 3.1 : Classification des méthodes formelles
3.5.1. L’approche axiomatique
Cette approche traite de façon indirecte le comportement du système. Elle est basée sur la
construction d’une axiomatisation qui permet d’obtenir les propriétés comportementales.
Nous procédons à cette axiomatisation par approches algébriques ou logiques [Attiogbé07].
L’approche logique exprime des systèmes transformationnels avec la logique temporelle. Elle
exprime des propriétés dynamiques de sûreté et de vivacité des systèmes réactifs. Dans cette
approche, nous nous intéressons à la démonstration de programmes en utilisant les théories de
la démonstration automatique ou semi-automatique de théorèmes. Parmi les langages de
spécification logiques nous citons: PVS [owreg93], Isabelle/HOL [smith02] et Coq
[behrmann04].
L’approche algébrique définit des types abstraits de données en spécifiant pour chaque
opération le type de valeurs de ses paramètres et le type de résultat. Les expressions sont
précisées à l’aide de variables appelées termes, les propriétés des opérations sont décrites sous
forme d’équivalences entre ces termes (axiomes). L’application des axiomes à des termes
permet d’obtenir d’autres expressions d’équivalence [truong06]. Parmi les langages de
spécification algébrique connus, nous citons: OBJ [goguen96], LPG [Bert95] et Larch
[Guettag85].
65
3.5.2. L’approche basée sur les états
Cette approche s’intéresse aux données du système. Elle construit un modèle en termes de
structures mathématiques tout en gardant les propriétés du système. Le modèle obtenu servira
à l’étude du fonctionnement du système, en lui appliquant des approches dynamiques et des
approches par modèle abstrait.
Les approches dynamiques sont basées sur le principe des processus. Elles utilisent les
automates, les réseaux de Petri et les algèbres de processus pour spécifier les systèmes de
transitions.
Les approches ensemblistes, ou approches par modèle abstrait fournissent une sémantique et
une syntaxe du modèle abstrait en utilisant la logique du premier ordre, la théorie des
ensembles ou la théorie des types. Parmi les langages de spécification ensemblistes nous
trouvons VDM [cliff86], Z [attiogbé07] et B [truong06].
La différence entre les approches ensemblistes et les approches algébriques réside dans
l’utilisation des types abstraits prédéfinis pour la modélisation des états dans l’approche
ensembliste. Chaque opération possède sa propre spécification et son impact sur le système.
3.5.3. L’approche hybride
L’approche hybride combine l’axiomatisation avec le modèle de données [attiogbé07].
LOTOS [Turner07] est un bon exemple de cette approche. LOTOS est un langage algébrique
car ses expressions de contrôle sont caractérisées par une algèbre dont les termes sont des
processus, en même temps, ses données sont caractérisées par une algèbre de type abstrait
dont les termes sont des expressions fonctionnelles [Truong06]. CCS [Milner 80] et ACT
ONE [Charles97] sont des prédécesseurs de LOTOS.
3.6. Techniques de vérification formelle
La validation et la vérification peuvent être réalisées à l’aide des preuves de théorèmes, la
vérification de modèles et les tests d’équivalence. Il est aussi possible de pratiquer des tests
sauf que ces derniers ne présentent pas une garantie d’exhaustivité.
3.6.1. Vérification de modèle ou Model-Checking
Tous les outils de modélisation des réseaux de Petri se basent sur la technique de vérification
de modèles. Le Model-Checking est une technique de vérification automatique des propriétés
d’exactitude dans un espace d’états fini. Les propriétés sont exprimées dans une logique
(généralement temporelle) ; le modèle est exprimé dans un langage formel ; et un algorithme
vérifie si un modèle ou une abstraction du système satisfait une spécification.
66
L’aspect automatique du Model-Checking facilite la décidabilité. La vérification de modèle se
termine par une réponse positive ou par une indication d’erreur. Le principal inconvénient du
Model-Checking est l’impossibilité de faire appel à cette technique dans le cas des systèmes
non-finis.
Les premiers travaux sur le Model-Checking de formules de logique temporelle ont été dirigés
par Edmund M. Clarke et E. Allen Emerson en 1981[EC82], et Jean-Pierre Queille et Joseph
Sifakis en 1982[QS82a].
3.6.2. Preuve de théorèmes
Dans cette technique, le développeur construit une partie de la preuve, au moins. Cette
technique exprime les spécifications en termes de logique ou de spécifications algébriques.
Cette logique est un système formel constitué d’axiomes et de règles de déduction. La preuve
de théorème vise à prouver certaines propriétés à partir des axiomes du système, des règles de
déduction et des lemmes qui ont été dérivés.
L’avantage de cette technique par rapport au Model-Checking réside dans sa prise en compte
des données complexes, ce qui lui permet d’être appliquée sur des espaces d’états non-finis.
L’inconvénient majeur est que la preuve de théorème reste une technique plus ou moins lente.
3.6.3. Vérification d’équivalence
Comme pour la technique du Model-checking, il est nécessaire que les systèmes soient finis
même si nous pouvons trouver des techniques où la vérification se fait en parallèle à la
conception du système.
Pour vérifier que deux modèles partagent une propriété donnée, les outils de test
d’équivalence utilisent des relations d’équivalence particulières. Il s’agit dans la plupart des
cas de prouver une propriété relativement abstraite sans avoir assez de données.
3.6.4. L’animation de spécifications
Dans le contexte des systèmes dynamiques, l’animation de spécifications permet de valider
une séquence. Pour les spécifications algébriques, elle permet de valider une construction.
L’animation de spécifications permet aussi d’avoir une sorte de prototype de la spécification
ou du système spécifié. Il existe de nombreux outils dédiés à l’animation de spécifications tels
que CPNTools pour les réseaux de Petri Colorés.
3.6.5. Les tests
Si le formalisme a une sémantique opérationnelle (interaction avec des outils d’animation), les
tests peuvent être effectués à un niveau abstrait ou à un niveau d’implémentation, c'est-à-dire
avec un prototype généré.
67
3.7. Intégration des méthodes formelles dans l’IDM
L’utilisation des méthodes formelles et de plus en plus courante dans le développement des
systèmes depuis que la complexité de ces derniers a évolué, surtout dans le cas des systèmes
critiques, là où aucune erreur n’est tolérée.
Depuis que l’IDM est devenue une démarche de conception qui couvre le cycle de
développement dans son intégralité, des études ont démontré que cette approche peut être
combinée avec les méthodes formelles, en minimisant les inconvénients de chacune et tirant
profit des avantages des deux [Gargantini09].

Les avantages des méthodes formelles
Il est aujourd’hui trivial pour un développeur de passer par les méthodes formelles pour la
validation des systèmes critiques. Un modèle formel sert de support pour l’analyse formelle
qui assurera ou non sa validité par rapport aux exigences du client, par simulation ou par tests.
Cette analyse formelle garantira certaines propriétés comportementales.

Les inconvénients des méthodes formelles
La difficulté de leur apprentissage et le manque de supports outillés pour assister les
développeurs dans la conception n’encourage pas ces derniers à adopter les méthodes
formelles facilement. Un autre inconvénient concerne les notations complexes comparées à
d’autres langages comme UML.

Les avantages de l’IDM
Cette approche concentre son activité sur l’automatisation du processus de développement par
l’utilisation des modèles comme abstraction du système. L’IDM applique à ces modèles, de
manière automatique, des opérations de maintenance, de raffinement et de transformation
dans le but de générer le code exécutable. Le concept de méta-modélisation permet de générer
l’éditeur du langage de modélisation grâce aux notations abstraites qu’il lui attribue. Cette
technique réduit considérablement la complexité et exprime tous les concepts du domaine.

Les inconvénients de l’IDM
Pour le moment, les environnements de méta-modélisation manquent de supports rigoureux
qui permettraient de fournir la sémantique des méta-modèles. La sémantique est exprimée en
langage naturel, ce qui empêche l’analyse formelle des modèles du langage défini par la métamodélisation.
L’IDM permet, grâce à la méta-modélisation et aux transformations de modèles, de mettre en
place des plateformes pour les méthodes formelles et de conserver leur interopérabilité.
68
3.8. Les réseaux de Petri
Les systèmes dynamiques sont caractérisés par leur comportement permanent. Ce
comportement est décrit par une séquence d’états qui peut être infinie. Pour cette raison, ces
systèmes ne peuvent être décrits que sur la base de leurs états initiaux et états finaux.
Différents paradigmes pour la description des systèmes dynamiques ont été développés mais
ils sont peu nombreux à intégrer des méthodes d’analyse dans leur propre description, comme
c’est le cas des réseaux de Petri.
Le réseau de Petri est un outil graphique pour la description formelle des systèmes dont la
dynamique est caractérisée par la concurrence, la synchronisation, l’exclusion mutuelle et le
conflit des choix multiples. Ces attributs sont propres aux environnements distribués. La
facilité des réseaux de Petri à s’adapter facilement élargit leur champ de pratique jusqu’aux
protocoles de communication, architectures des ordinateurs, etc. Leur aspect mathématique
leur permet l’analyse des propriétés comportementales et structurelles essentielles à la
validation du système.
L’étude d’un système par utilisation de réseau de Petri se fait suivant ces trois étapes :
 Modéliser le système en termes de places et de transitions du réseau de Petri.
 Analyser le modèle obtenu et déduire des propriétés dont les propriétés de sûreté et de
vivacité.
 Révision des propriétés pour valider le système.
Cette analyse qualitative du système est une approche très importante pour obtenir une bonne
évaluation.
3.8.1. Historique
Les réseaux de Petri ont été introduits par Carl Adam Petri en 1962 [AD 68] dans sa thèse de
doctorat, intitulée « Communication avec des Automates », en Allemagne. Ce travail a ouvert
un champ d’étude et a été exploité par Anatol W. Holt, F. Commoner, M. Hack et leurs
collègues dans le groupe de recherche de Massachussetts Institute OF Technology (MIT) dans
les années 70. Le premier livre traitant des réseaux de Petri a été publié par J. Peterson.
3.8.2. Bases et définitions des réseaux de Petri
Un réseau de Petri est un graphe biparti orienté composé de places, de transitions et d’arcs.
Les places sont représentées graphiquement par des cercles et les transitions par des
rectangles. Un arc ne peut relier deux places ou deux transitions.
69
Les places décrivent les états possibles du système ou des conditions, et les transitions
permettent de modéliser les événements ou les actions qui font basculer le système d’un état à
un autre.
Les jetons sont des éléments ajoutés aux places pour le déroulement du système simulé par le
réseau de Petri. L’état du système est donné par son marquage qui est défini par la distribution
des jetons sur les différentes places du réseau de Petri.
Chaque place contient un nombre entier positif ou nul de marques ou jetons. Le marquage M
définit l'état du système décrit par le réseau à un instant donné. C’est un vecteur colonne de
dimension égale au nombre de places dans le réseau. Le iéme élément du vecteur correspond
au nombre de jetons contenus dans la place Pi. L’ensemble de changements d’états possibles
du système est conclu à partir de l’ensemble des transitions franchissables.
La figure 3.2 montre un exemple de réseaux de Petri.
Figure 3.2 : Exemple de réseau de Petri marqué
L’aspect dynamique du système est donné par les transitions. Une transition est franchissable
lorsque toutes les places qui lui sont juxtaposées (ou toutes les places d'entrée de la transition)
contiennent autant de jetons que nécessite la condition de franchissement.
Le franchissement consiste à retirer les jetons de chacune des places d'entrée et à ajouter les
jetons à chacune des places de sortie d’une transition. Une transition franchissable n'est pas
toujours franchie immédiatement.
Une transition sans place d'entrée est toujours franchissable : c'est une transition source. Le
franchissement d'une transition source consiste à ajouter un jeton à chacune de ses places de
sortie.
Une transition sans place de sortie est une transition puits. Le franchissement d'une transition
puits consiste à retirer un jeton de chacune de ses places d'entrée.
70
3.8.3. Avantages et inconvénients des réseaux de Petri
Le formalisme des réseaux de Petri présente les avantages suivants :
 Définition formelle : Cette caractéristique efface toute ambigüité dans la
spécification, car chaque modèle possède une sémantique bien définie.
 Les réseaux de Petri sont exécutables : Il existe des programmes construits sur la
définition formelle de la notation qui permettent d’interpréter les modèles en réseaux
de Petri et de simuler le fonctionnement du système en cours de spécification. Ceci
permet une vision dynamique du système.
 Expression puissante : Les réseaux de Petri sont adaptés pour décrire des
comportements complexes, réactifs ou concurrents.
 Support de vérification : Les réseaux de Petri disposent de nombreuses techniques
de vérification automatique des propriétés génériques du système, comme la vivacité,
ou des propriétés spécifique, comme l’existence d’invariants.
 Représentation graphique : cette qualité facilite l’interprétation et la compréhension
des modèles.
Malgré ces multiples qualités, les réseaux de Petri souffrent de certains points négatifs :
 Manque de structuration : Plus le système est complexe et plus la taille du modèle
produit est importante, et plus leur maîtrise est compliquée.
 Structure de données : Les réseaux places/transitions ne permettent pas de décrire la
structure des données manipulées par le système.
Ces inconvénients ont été étudiés et commencent à se résoudre graduellement depuis le
développement de la théorie des réseaux de Petri de haut-niveau.
3.8.4. Utilisation des réseaux de Petri
Dans certains cas, les réseaux de Petri ordinaires ne peuvent exprimer toutes les propriétés
que nous voudrons modéliser, et de ce fait, des extensions s’avèrent utiles afin de pallier à ces
insuffisances. Parmi les extensions les plus utilisées, nous citons :


Les réseaux de Petri généralisés: Un réseau de Petri généralisé est un réseau de Petri
dans lequel des poids (nombres entiers strictement positifs) sont associés aux arcs.
Les réseaux de Petri temporisés : C’est une extension temporelle des réseaux de Petri.
71


Les réseaux de Petri colorés : Dans un réseau de Petri coloré, on associe une valeur à
chaque jeton.
Les réseaux de Petri continus : Le nombre de jetons dans un réseau de Petri continu est
un réel positif. Le franchissement s’effectue comme un flot continu en introduisant la
notion de vitesse traduite par le nombre de marques franchies pendant une unité de
temps.
Quelques utilisations des réseaux de Petri dans les différents domaines, non seulement
informatiques, ont été résumées dans le tableau 3.1:
Réseau de Petri ordinaire
Modélisation des systèmes logiciels.
Modélisation des processus d’affaires.
Gestion des flux.
Programmation concurrente.
Génie de la qualité.
Diagnostic.
Réseau de Petri généralisé Gestion des flux complexes.
Modélisation de chaînes logistiques.
Utilisation pour les techniques quantitatives.
Réseau de Petri temporisé
Gestion du temps.
Modélisation d’attentes.
Réseau de Petri coloré
Modélisation des systèmes de collaboration.
Réseau de Petri continu
Modélisation des réactions chimiques.
Tableau 3.1 : Exemples d’utilisation des réseaux de Petri
3.8.5. Outils de modélisation des réseaux de Petri
Il existe de nombreux outils de simulation et de vérification des réseaux de Petri selon la
technique de vérification de modèles, souvent libres, et développés dans le cadre de thèses ou
de recherches scientifiques.
Le tableau suivant (tableau 3.2) récapitule les plus importants parmi ces outils par rapport à :
La présence d’un environnement graphique d’édition.
La possibilité de simulation.
La possibilité d’analyse des propriétés génériques.
La possibilité de vérification des contraintes CTL (Logique Temporelle Arborescente)
et LTL (Logique Temporelle Linéaire).
o Possibilité de supporter le format d’échange XML.
o
o
o
o
72
Outils
Interface
graphique
Simulation
Analyse
CTL
LTL
XML
CPNtools
[CPNtools]
Oui
Oui
Oui
Oui
Non
Oui
CPNAMI
[CPNAMI]
Oui
Oui
Oui
Oui
Oui
Non
PROD
[PROD]
Non
Non
Oui
Oui
Oui
Non
JARP [JARP]
Oui
Non
Oui
Non
Non
Oui
MARIA
[MARIA]
Non
Non
Oui
Oui
Oui
Non
LOLA
[LOLA]
Non
Non
Oui
Oui
Non
Non
PetriNet
Kernel [PNK]
Oui
Non
Non
Non
Non
Oui
GreatSPN
[GreatSPN]
Oui
Non
Oui
Non
Non
Non
TINA[TINA]
Oui
Oui
Oui
Oui
Oui
Oui
Tableau 3.2 : Les plus importants outils de modélisation des réseaux de Petri
3.8.6 Définition formelle
Un réseau de Petri est défini par un 5-tuple M = {P, T, I, O, M0} où :
• P : Ensemble de places du réseau.
• T : Ensemble de transitions du réseau.
• I, O : sont des fonctions input, output respectivement.
• M0 est une application de P vers N (N : Ensemble des entiers naturels) appelée marquage
initial.
Les fonctions I, O décrivent les poids portés par arcs input, output des transitions.
Soit une transition t ∈ T : La notation •t = {p ∈ P : I(t,p) > 0} et t• = {p ∈ P : O(t,p) > 0}
expriment l’ensemble des inputs et outputs d’une transition t}.
La valeur de M0 (p), p∈ P, représente le nombre de jetons dans la place p à l’état initial.
73
3.8.7. Déroulement d’un réseau de Petri
Dans un réseau de Petri, le mécanisme de changements de places est animé par le
franchissement des transitions. Le calcul du réseau de Petri se fait à travers la distribution des
jetons dans les places.
3.8.7.1. Franchissement d’une transition
Une condition de franchissement doit être vérifiée pour permettre de franchir une transition.
La règle de franchissement définit le changement de marquage provoqué par le
franchissement de la transition.
Une transition t est tirée si et seulement si toutes les places inputs (place d’entrée) contiennent
un nombre de jetons supérieur ou égal au seuil donné. Ces seuils sont définis par le poids des
arcs correspondants à la transition.
P1
P2
n
m
t
k
P3
Figure 3.3 : Franchissement d’une transition t
Dans l’exemple de la figure 3.3, la transition t est tirée si le nombre de jetons dans la place p1
est supérieur ou égal à n, et le nombre de jetons dans la place p2 est supérieur ou égal à m.
Nous pouvons adopter la définition suivante [Ajmone95] :
Une transition t est tirée dans un marquage M si et seulement si :
74
∀ p ∈ •t, M(p) ≥ O(t, p)
Lorsqu’une transition t est franchie, elle supprime de chaque place de son ensemble •t autant
de jetons indiqués dans le poids de l’arc reliant la place à t, et ajoute à chaque place de son
ensemble t• autant de jetons indiqués dans l’arc reliant t à cette place.
Le franchissement de la transition t tirée dans le marquage M, produit le marquage M’ tel
que :
M’ = M + O(t) – I(t)
Cette formule est généralement écrite de la manière suivante : M[t>M’, ce qui veut dire que
M’ est directement accessible à partir de M.
Dans la figure 3.3 le franchissement de la transition t change le marquage en supprimant n
jetons de la place p1, et m jetons de la place p2 et en ajoutant k jetons à la place p3. Pour que t
réussisse à supprimer n jetons de la place p1, au moins n jetons doivent s’y trouver, et la
même chose pour la place p2. Ceci est considéré comme une condition de tir de transition.
3.8.7.2. Séquences de franchissement
Une séquence de franchissement S est une suite de transitions Ti, Tj…Tk qui peuvent être
franchies successivement à partir d'un marquage donné. Une seule transition peut être
franchie à la fois.
La notation : Mi [S -> Mj ou Mi [S > Mj exprime que le franchissement de la séquence S à
partir du marquage Mi conduit au marquage Mj.
3.8.7.3. Marquages accessibles
L'ensemble des marquages accessibles est l'ensemble des marquages Mi qui peuvent être
atteints par le franchissement d'une séquence S à partir du marquage initial M0, Noté *M0.
3.8.8. Propriétés des réseaux de Petri
Les propriétés génériques informent le développeur sur le comportement général du réseau de
Petri. Celles-ci doivent être complétées par l’analyse des propriétés spécifiques du système
modélisé. Ces propriétés sont souvent spécifiées par des formules logiques telles que la
logique temporelle linéaire (LTL) et la logique temporelle arborescente (CTL). La vérification
des propriétés nécessite la construction du graphe d’accessibilité.
75
3.8.8.1. Propriétés génériques
La vivacité, le caractère borné et la réinitialisabilité sont les principales propriétés génériques
qui peuvent être automatiquement vérifiées dans un réseau de Petri.

Vivacité et blocage
Un réseau de Petri est vivant si et seulement si toutes ses transitions sont vivantes.
Une transition t d’un réseau de Petri ayant M0 comme marquage initial est dite vivante
si pour tout marquage M du réseau de Petri atteignable à partir de M0, nous pouvons
toujours trouver une séquence franchissable de transitions dans laquelle la transition t
figure. La vivacité d’un réseau de Petri dépend de son marquage initial M0.
Un réseau de Petri vivant garantit l’absence de blocages et de parties mortes (non
atteintes) dans la structure du réseau. Il garantit ainsi la possibilité de toujours
atteindre les services du système modélisé dans le réseau.

Réseau borné, Réseau Sauf
Un réseau de Petri est borné si et seulement si toutes ses places sont bornées.
Une place p est bornée si pour tout marquage M, le nombre de jetons dans la place est
inférieur à une constante k : ∀ M, M(p) < k.
Le caractère borné d’un réseau de Petri renseigne sur les valeurs limites des ressources
demandées par le système. Si un réseau est borné, et la borne est égale à 1, alors il est
dit sauf.

Conflit
Un conflit structurel correspond à un ensemble d’au moins deux transitions t1 et t2
avec une place d’entrée en commun. Ceci est noté comme suit :
k = < p , {t1,t2,…,tn} >
Un conflit effectif est l’existence d’un conflit structurel k, et d’un marquage M, tel que
le nombre de marques dans p est inférieur au nombre de transitions de sortie de p qui
sont validées par M.

Réinitialisabilité
Un réseau de Petri est réinitialisable si et seulement si pour tout marquage M, il existe
une séquence de transitions qui permet de revenir au marquage initial M0.
76
Cette propriété renseigne sur le fonctionnement répétitif, ce qui est pertinent pour la
majorité des systèmes interactifs.
3.8.8.2. Propriétés spécifiques
Les propriétés spécifiques sont regroupées en quatre types: Les propriétés d’accessibilité, de
sûreté, de vivacité et d’équité.

L’accessibilité (reachability) : détermine si une situation est accessible ou non à partir
du graphe d’accessibilité.

La sûreté (safety) : certaines situations ne devront jamais être atteintes.

La vivacité (liveness) : une situation finira tôt ou tard par avoir lieu.

L’équité (fairness) : une situation aura lieu une infinité de fois.
3.8.8.3. Graphes des marquages
Le graphe des marquages accessibles de N depuis M0, noté G(N,M0) est le graphe dont les
états sont les marquages accessibles tel qu’il existe un arc entre deux sommets M1 et M2 si et
seulement si M1 [ t>M2.
La figure 3.4 montre un exemple du graphe des marquages du réseau de Petri (a).
(1,0)
(1,0)
t2
t1
(0,1)
t1
t2
P2
P1
t2
(1,0)
(0,1)
t1
(a)
t1
(b)
(c)
Figure 3.4 : Graphe des marquages du réseau de Petri (a)
77
3.8.9. Évolution des réseaux de Petri
Malgré les facilités qu’il offre, le formalisme des réseaux de Petri classique souffre d’un
certain manque de structuration et d’expressivité lorsqu’il s’agit de distinction entre les jetons,
ou l’expression de dimension temporelle. Dans ce cas, l’utilisation des réseaux de Petri tels
qu’ils ont été définis par Adam Petri produirait des modèles de taille significative, qui
croissent rapidement avec la complexité du système. De ce fait, la manipulation et l’analyse
de ces grands modèles devient très difficile, voire impossible.
Pour y remédier et ainsi augmenter le niveau d’expressivité, les réseaux de Petri ont connu
plusieurs extensions. Les plus connues sont les réseaux de Petri colorés [Jensen 97, Jensen98],
les ECATNets [Bettaz92, Bettaz93], les réseaux de Petri algébriques, les réseaux de Petri
Prédicats/Transitions [Genrich81], les G-Nets [Deng93] et les GSPN [Ajmone95] qui seront
présentés et étudiés par la suite.
3.8.10. Modélisation des systèmes concurrents
L’avantage des réseaux de Petri réside dans leur capacité à modéliser un grand nombre de
comportements dans les systèmes complexes. Parmi ces comportements, nous trouvons le
parallélisme, la synchronisation, le partage de ressources, la mémorisation, la lecture
d’informations, la limitation de capacité de stockage, etc.

Le parallélisme
Le parallélisme est défini comme l’évolution simultanée de plusieurs processus dans un même
système. Dans un réseau de Petri, le parallélisme est déclenché avec une transition ayant
plusieurs places de sortie, comme présenté dans la figure 3.5.
P1
t1
p2
p3
Processus1 Processus2
Figure 3.5 : Réseau de Petri avec parallélisme
78
Le franchissement de la transition t1 met un jeton dans la place P2, et un jeton dans la place
P3, ce qui marque le déclenchement du processus 1 et du processus 2 en parallèle.

La synchronisation
Il existe deux types de synchronisation : la synchronisation mutuelle (rendez-vous) et la
synchronisation par signal (sémaphores).
 Synchronisation mutuelle : Cette synchronisation permet de synchroniser les
opérations de deux processus comme le montre la figure 3.6.
P2
P1
t1
P4
P3
Processus1
Processus2
Figure 3.6 : Réseau de Petri avec synchronisation mutuelle
Pour que la transition t1franchisse, il faut que la place P1 qui correspond au processus1
et la place P2 qui correspond au processus 2 contiennent chacune au moins un jeton.
Autrement, si par exemple la place P1 ne contient pas de jetons, le processus2 reste
bloqué sur la place P2; il attend que le processus 1 réussisse à obtenir un jeton dans la
place p1 au cours de son évolution.
 Synchronisation par signal : Les opérations du processus 2 se poursuivent à condition
que le processus 1 ait atteint un certain niveau dans son évolution. Ceci n’est pas le cas
du processus 1 qui ne dépend pas de l’avancement des opérations du processus 2. Un
exemple est illustré dans la figure 3.7.
Attente
Signal
Processus1
Processus2
79
Figure 3.7 : Réseau de Petri avec synchronisation par signal
Lorsque la place "Signal" est marquée et la place "Attente" ne l’est pas, ceci se traduit
par un processus 1 qui a envoyé le signal que le processus 2 n’a pas encore reçu. Si, à
l’inverse, la place "Signal" n’est pas marquée et la place "Attente" est marquée, cela
signifie que le processus 2 est en attente du signal.

Le partage de ressources
Il s’agit de modéliser le cas de plusieurs processus se partageant une même ressource
dans un même système, en utilisant l’exclusion mutuelle.
P1
P2
t2
t1
P0
t4
Processus1
t3
Processus2
Figure 3.8 : Réseau de Petri avec partage de ressource
Dans la figure 3.8, le jeton dans la place P0 représente une ressource commune entre le
processus 1 et le processus 2. Après le franchissement de la transition t1 lors de
l’évolution du processus 1, le jeton de la place P0 est alors consommé. La ressource
que constitue ce jeton n’est alors plus disponible pour l’évolution du processus 2. Lors
du franchissement de la transition t4, un jeton est placé dans la place P0, et la ressource
est de nouveau disponible.

La mémorisation
Une place sans entrée ou sans sortie peut être utilisée dans tous les modèles pour compter
le nombre de tirs d’une transition. Dans la figure 3.9, les places "Attente" et "Compteur"
peuvent indiquer combien d’instances d’un processus sont en attente.
80
Attente
Compteur
Figure 3.9 : Réseau de Petri illustrant le cas de la mémorisation
3.8.11. Méthodes d’analyse des réseaux de Petri

Analyse par graphes des marquages
Le plus simple pour analyser les propriétés d’un réseau de Petri est de construire son graphe
des marquages accessibles. Dans ce graphe, chaque sommet correspond à un marquage
accessible et chaque arc correspond au franchissement d’une transition permettant de passer
d’un marquage à un autre. Nous pouvons distinguer deux situations :
-Le graphe est fini : dans ce cas toutes les propriétés peuvent être déduites simplement en
analysant ce graphe. La situation d’un graphe fini est certainement la situation la plus
favorable.
- Le graphe est infini : dans ce cas, il faudra construire le graphe de couverture qui permettra
de déduire certaines propriétés.

Analyse par algèbre linéaire
Cette idée permet d’étudier les propriétés d’un réseau de Petri indépendamment du marquage
initial. Nous parlons alors de propriétés structurelles du réseau.
Un réseau est structurellement borné s’il est borné pour tout marquage initial fini, et si pour
tout marquage initial le réseau est vivant, nous déduiront que le réseau est structurellement
vivant.

Analyse par réduction
Lorsque la taille du réseau de Petri devient importante, l’analyse de ses propriétés s’avère
compliquée avec l’utilisation du graphe des marquages. La réduction permet d’obtenir un
81
réseau de Petri simplifié à partir d’un réseau de Petri marqué, en appliquant des règles de
réduction. Ces règles réduisent le nombre de places et de transitions.
:


Pour les propriétés étudiées, le réseau de Petri simplifié doit être équivalent au premier
réseau de Petri marqué.
Le réseau de Petri simplifié doit être suffisamment simple pour que l’analyse de ses
propriétés soit simple.
En général, le réseau de Petri simplifié ne peut pas s’interpréter comme le modèle d’un
système.
3.9. Les Réseaux de Petri Généralisés Stochastiques (GSPN)
Lorsque Carl Adam Petri a introduit les réseaux de Petri dans sa thèse pour la première fois,
ils avaient servi pour décrire un comportement concurrent dans un système en termes de
relations causes/effets, sans considérer la notion du temps.
L’introduction du temps dans le réseau de Petri a été proposée des années plus tard par les
scientifiques C.Ramchandi, P.M.Merlin, D.J.Farber et J.Sifakis avec différentes approches.
Plusieurs propositions basées sur l’utilisation d’une distribution de temps déterministe ont été
alors présentées, mais les premières à avoir introduit le temps stochastique dans les réseaux de
Petri sont F.Symons, G.Florin, S.Natkin et M.Molloy.
Ces propositions ont ouvert la possibilité de lier les réseaux de Petri aux techniques de
l’évaluation des performances et l’analyse généralement basées sur des approches de
modélisation stochastiques. Ces modèles sont appelés aujourd’hui les SPN (Stochastic Petri
Net). Une extension de cette approche a été donnée par M.Molloy où la temporisation
stochastique est mixée avec les délais nuls déterministes. De ce fait, une analyse temporelle et
logique du système peut être réalisée sur un modèle. Ce formalisme de modélisation est
appelé les GSPN [Ajmone95] (Generalized Stochastic Petri Nets).
Le franchissement d’une transition est le résultat soit d’une condition logique basculée à
« vrai » dans le système, soit de la terminaison d’une activité. Cette dernière interprétation est
la raison qui incite à associer le temps aux transitions.
3.9.1. Les motivations de l’introduction du temps dans les réseaux de Petri
Dans l’histoire de la modélisation et l’analyse des systèmes, nous constatons qu’il y a eu
d’une manière générale des modèles strictement qualitatifs comme les réseaux de Petri, et des
modèles strictement quantitatifs comme les files d’attente ou les chaînes de Markov. Plus tard,
des études ont été lancées pour l’étude d’un système avec le lien entre ce qui est évalué et ce
qui est vérifié, et donc voir apparaitre des modèles qui intègrent à la fois des éléments
qualitatifs et des éléments quantitatifs, avec des caractéristiques temporelles en particulier.
82
Les réseaux de Petri ont été reconnus comme modèles pratiques pour la modélisation des
systèmes concurrents, capables de faire face à tous les aspects du parallélisme et les conflits
dans les activités asynchrones. Le temps n’est pas important pour visualiser les relations entre
les entités du système, mais il est d’une importance primordiale lorsqu’il est question de la
dynamique du système, notamment dans les domaines de l’architecture des ordinateurs ou les
protocoles de communication.
Carl Adam Petri a intentionnellement évité l’idée d’introduire le temps dans les réseaux de
Petri à cause des conséquences que cela pourrait provoquer sur le comportement du système
réel. En effet, associer le temps aux activités représentées dans les réseaux de Petri peut
bloquer certaines transitions, ce qui remettrait en cause la possibilité de la structure des
réseaux de Petri à représenter tous les comportements d’un système.
L’introduction du concept du temps dans les réseaux de Petri rend ces derniers très puissants,
mais reste incompatible avec la philosophie de base de ces réseaux. Cette attitude est due au
fait que les réseaux de Petri ont été considérés à leurs débuts comme des automates formels
avec des propriétés de base, appliqués à des tâches qui ne nécessitent pas forcément
d’informations sur le temps.
Les réseaux de Petri stochastiques [Ajmone95] sont des extensions temporelles et
stochastiques des réseaux de Petri qui permettent l’analyse qualitative et quantitative des
systèmes. Le temps peut être attribué aux places, aux arcs ou aux transitions.
La façon la plus naturelle pour l’introduction du temps est la suivante : étant donné un
marquage M, une quantité de temps doit se consommer depuis l’entrée dans ce marquage
avant qu’un événement (tir d’une transition) ne se produise et bascule l’état du système dans
un marquage M’, et donc associer le temps aux transitions.
L'ajout des spécifications temporelles ne doit pas modifier la façon d'exprimer le parallélisme
et la synchronisation dans les réseaux de Petri. Le GSPN satisfait cela et fournit un
formalisme qui permet la construction de modèles qui peuvent être utilisés à la fois pour des
analyses comportementales basées sur la théorie classique des réseaux de Petri, et également
pour les études de performance basées sur les spécifications temporelles et les modèles
probabilistes.
Les GSPNs représentent une sorte de compromis entre les deux besoins de l’analyse
qualitative et l’analyse quantitative des systèmes, car ils incluent des extensions qui sont très
utiles dans la modélisation pratique.
3.9.2. Réseaux de Petri stochastiques
Le processus stochastique (ou fonction aléatoire) est une famille {Xt} tT de variables
aléatoires définie dans le temps t. Un modèle d’évolution dynamique dans lequel on fait
83
dépendre l’évolution future de l’état présent et du hasard est une chaîne de Markov. C’est un
processus stochastique construit sur la philosophie suivante : « conditionnellement au présent,
le futur ne dépend pas du passé.».
Les réseaux de Petri stochastiques sont des réseaux de Petri étendus temporellement dans
lesquels la notion de trajectoire temporisée [JuaGal97] a été introduite. La trajectoire
temporisée ∑t est une séquence de marquages avec la séquence de transitions et les dates
d’entrée dans les marquages :
∑ t = { (tm(0), M(0)) ; (t1, tm(1), M(1)) ; …. ; (ti , tm(i) , M(i)) ; (ti+1 , tm(i+1) , M(i+1))}
Pour chaque i, M(i) est le marquage atteint ; ti est la transition i ; tm(i) est la date d’entrée
dans le marquage. La durée de séjour dans le marquage M(i) est donnée par tm(i+1) – tm(i).
Le déroulement depuis tm(0) jusqu’à tm(i) constitue l’histoire (mémoire temporelle) notée
Z(i).
L’ensemble de trajectoires temporisées est muni d’une mesure de probabilité telle que le
couple (marquage, instant d’entrée dans le marquage) constitue un processus stochastique.
L’étude de ce processus stochastique suppose que pour tout i, Z(i) et M(i), et pour toutes les
transitions sensibilisées en M(i), nous pouvons définir de manière unique la probabilité ou le
noyau suivant :
Dk (x/Z(i), M(i)) = Prob {tk tirée, tm(i+1) – tm(i)
x/Z(i), M(i)}
Le noyau exprime la probabilité que la transition tk soit la prochaine transition tirée (limite de
Dk (x/Z(i), M(i)) lorsque x → ∞ ) ainsi que la distribution du temps de séjour dans M(i) (∑ Dk
(x/Z(i), M(i)) la somme portant sur l’ensemble des transitions sensibilisées en M(i)).
Donc, dans un réseau de Petri stochastique, d’une part nous associons à toute transition tk, une
variable temporelle aléatoire yk caractérisée par une fonction de répartition Fk(x/M(i)), et
d’autre part, nous définissons une politique d’exécution qui permet de calculer le noyau
Dk(x/Z(i), M(i)) et donc de caractériser le processus stochastique du marquage.
3.9.3. Politique d’exécution et processus stochastique
La politique d’exécution concerne la sélection de la transition à tirer dans un marquage, et la
prise en compte dès l’instant d’entrée dans un marquage de l’histoire ou mémoire temporelle.
En ce qui concerne la sélection de la transition à tirer, nous distinguons deux techniques :
 La compétition : Consiste à tirer la transition dont la variable temporelle aléatoire est
statistiquement la plus petite. Cette technique n’est pas applicable dans le cas de
transitions sensibilisées simultanément avec des distributions déterministes identiques.
84
 La présélection : Il s’agit d’attribuer aux transitions des probabilités de
franchissement.
Pour ce qui est de la prise en compte de la mémoire temporelle, nous distinguons trois
techniques :
 La réinitialisation : Il s’agit de remettre à zéro la mémoire temporelle. Après le tir
d’une transition, la fonction de répartition de toutes les transitions simultanément
sensibilisées avec cette dernière est réinitialisée.
 La mémoire de toutes les périodes de sensibilisation : La mémoire temporelle d’une
transition débute dès que cette transition est sensibilisée pour la première fois, et se
maintient jusqu’à ce qu’elle soit effectivement tirée.
 La mémoire de la dernière période de sensibilisation : Considère que la mémoire
est opérationnelle uniquement tant que la transition est sensibilisée.
Nous pouvons combiner les techniques de la sélection avec les techniques de prise en compte
de la mémoire temporelle de la manière suivante :

Combinaison de la présélection avec la réinitialisation : pour la modélisation des
activités conflictuelles qui ne peuvent se dérouler en parallèle. La combinaison de la
présélection avec les techniques de la mémoire temporelle n’est pas envisageable, cela
aboutirait, suivant la présélection, à des situations où plusieurs activités se déroulent
en parallèle, et où l’activité présélectionnée a la durée la plus longue, ce qui
empêcherait des activités plus courtes d’induire un changement de marquage.

Combinaison de la compétition avec la mémoire de toutes les périodes de
sensibilisation : pour la modélisation de la préemption (ordonnancement, sûreté de
fonctionnement).

Combinaison de la compétition avec la mémoire de la dernière sensibilisation :
pour modéliser des mécanismes de « time-out ».
La nature du processus stochastique de marquage dépend de la technique de prise en compte
de la mémoire temporelle.
Pour la réinitialisation, le processus stochastique de marquage est un processus semimarkovien car le noyau ne dépend plus de l’histoire quelles que soient les fonctions de
répartition des variables temporelles aléatoires (chaque marquage est un point de
régénération).
Dans le cas de la mémoire de toutes les périodes de sensibilisation ou de la dernière
sensibilisation où seule la technique de compétition peut être envisagée, le noyau dépendra de
85
l’histoire. Nous ne pouvons donc émettre une conclusion à ce niveau sur le type du processus
stochastique.
3.9.4. Le modèle SPN
Les réseaux de Petri de type SPN sont des réseaux dans lesquels une variable aléatoire est
associée à chaque transition. Cette variable spécifie la durée qui sépare l’instant de
sensibilisation d’une transition et l’instant de tir de celle-ci.
La politique de choix de la transition à tirer est la politique de compétition (la mémoire
temporelle n’est plus envisageable). Les fonctions de répartitions des variables aléatoires
associés aux transitions étant toutes exponentielles, nous pouvons constater que :
-Le processus de marquage est un processus markovien, et donc nous pouvons appliquer
toutes les méthodes de calcul markovien (le graphe de marquage est isomorphe à une chaîne
de Markov).
-Puisqu’il n’y a pas de mémoire temporelle de la loi exponentielle, il y a perte, à chaque
instant, de la mémoire des travaux cumulés. Cela implique que lors du tir d’une transition, les
attributs temporels des transitions en parallèle ne sont pas modifiés.
3.9.5. Le modèle GSPN
Afin d’obtenir une représentation réelle du système, nous avons besoin de modéliser son
aspect stochastique imposé par les retards aléatoires, et donc attribuer des variables aléatoires
dans la modélisation de certaines transitions. En même temps, toutes les transitions dans un
système ne modélisent pas une durée dans le temps, comme c’est le cas d’une vérification
d’une condition ou autre actions logiques. Pour cette raison, et dans le but d’avoir une vue
globale du système, le modèle GSPN (Generalized Stochastic Petri Nets) considère à la fois
des transitions avec une distribution exponentielle des durées, dites temporisées, et des
transitions avec des durées nulles, dites immédiates.
Le processus stochastique fait qu’à chaque nouvelle mesure pour un marquage M, nous
obtenons de nouvelles valeurs pour les variables aléatoires qui modélisent les retards liés à
l’exécution des activités dans les transitions temporisées. Les transitions immédiates quant à
elles modélisent les actions logiques qui ne consomment pas de temps, ou bien des durées
négligeables.
3.9.5.1. Transitions temporisées
Le franchissement d’une transition dans un réseau de Petri correspond à l’événement qui
change l’état du système. Ce changement est dû à l’une des raisons : soit la vérification d’une
condition logique dans le système, soit la terminaison d’une activité. Dans le second cas où
les transitions sont utilisées pour modéliser des activités, les temps de ces transitions
86
correspondent aux temps nécessaires pour l’exécution des activités, et les franchissements à la
fin de ces activités.
Les transitions temporisées sont représentées comme suit (figure 3.10) :
P1
Temps
t
02 :00
P2
Figure 3.10 : Syntaxe d’une transition temporisée
La figure ci-dessus montre une transition t« temporisée ». Lorsqu’un jeton est généré dans la
place p1, t devient franchissable et le chronomètre est initialisé. Le chronomètre est ensuite
décrémenté à une vitesse constante, et la transition est franchie lorsque le chronomètre atteint
la valeur zéro. Le chronomètre associé à la transition peut alors servir pour modéliser la durée
d’une activité dont la terminaison implique le changement d’état. Ce dernier est représenté par
le changement de marquage provoqué par la transition t.
Cette activité représentée par la transition t dépend du système modélisé, elle peut
correspondre par exemple à l’exécution d’une tâche par le processeur, la transmission d’un
message dans un protocole de communication, etc. Il est à noter qu’une activité est considérée
en cours d’exécution tant que la transition est active. Une interruption d’une activité peut
survenir si la transition perd sa condition de tir avant son franchissement. L’activité peut se
réactiver plus tard, et se répéter jusqu’à ce que le chronomètre atteigne la valeur zéro, et la
transition est alors franchie.
3.9.5.2. Transitions immédiates
Comme il a été vu précédemment, tous les événements qui surviennent dans un modèle de
système ne correspondent pas à la terminaison d’activités ayant consommé des unités de
temps. Prenons le cas d’un multiprocesseur modélisé à un haut niveau d’abstraction, dans ce
modèle, nous négligeons les durées des tâches de switch qui sont considérées comme
insignifiantes devant les autres tâches d’exécution. Il est donc important d’introduire ce
87
second type de transitions, dites immédiates, franchissables aussitôt qu’elles sont tirées, avec
aucun retard.
Les transitions immédiates peuvent également modéliser des actions logiques lorsque le
système se retrouve dans une situation de choix entre deux alternatives. Dans le modèle SPN,
ces actions sont modélisées de façon à ce qu’elles prennent une certaine quantité de temps, ce
qui n’est pas naturel dans le système réel.
Cet ensemble de transitions immédiates combinées aux transitions temporisées sont
exprimées dans les GSPN, et il a été convenu de leur attribuer la priorité par rapport aux
transitions temporisées.
Les transitions immédiates et temporisées sont représentées comme le montre la figure 3.11.
(a)
(b)
Figure 3.11 : Transition temporisée (a) et transition immédiate (b)
3.9.6. Définition formelle du modèle GSPN
Formellement [Ajmone95], un réseau GSPN est défini comme un 6-tuple :
MGSPN = (P, T, I, O, M0, Π, W)
Où:
M = (P, T, I, O, M0) est un réseau de Petri, W: T → R est une fonction sur l’ensemble des
transitions qui permet de définir le processus stochastique associé au modèle.
Π: T → N est une fonction qui associe un niveau de priorité à chaque transition.
Nous pouvons définir deux types de marquages :
-Les marquages tangibles dans lesquels seules des transitions temporisées sont sensibilisées.
La politique de sélection est la politique de compétition sont utilisées. La mémoire temporelle
n’est pas précisée puisque la distribution exponentielle n’a pas de mémoire temporelle.
88
-Les marquages évanescents dans lesquels au moins une transition immédiate est sensibilisée,
et dans ce cas la manière de choisir une transition à tirer est complexe, et basée sur une
politique de présélection.
Prenons l’exemple d’un GSPN [Ajmone95] illustré dans la figure 3.12 :
La transition Tnewdata décrit une activité de lecture d’une nouvelle information (avec retard
aléatoire) qui déclenche aussitôt deux processus parallèles.
Les transitions Tnewdata, Tpar1, Tpar2, Ti/o et Tcheck sont temporisées, contrairement aux
transitions tstart, tsyn, tok, et tko qui sont immédiates.
Tnewdata décrit l’activité par laquelle une suite d’informations passe en lecture, et est
temporisée à λ=0.1. Dès qu’une nouvelle information est disponible, deux processus
parallèles débutent avec l’opération décrite dans la transition Tstart dont le poids est égal à 1.
L’exécution de deux processus consomme des quantités de temps aléatoires. Lorsque les deux
processus se terminent, une synchronisation prend place dans l’opération décrite par la
transition immédiate tsync, dont le poids est aussi égal à 1.
Les deux transitions immédiates tok et tko forment un conflit de choix multiples. Si la
probabilité d’avoir un résultat inconsistant est égale à 0.1, un poids de 1 est assigné à la
transition tko et un poids de 9 est assigné à la transition tok. Si les résultats ne sont pas
consistants (tko franchit), l’exécution parallèle est répétée après un contrôle par la transition
temporisée Tcheck. Autrement, l’exécution atteint la transition Ti/o qui est temporisée.
Il est important de savoir que les valeurs des poids associés avec tstart et tsync sont
insignifiantes car ces deux transitions ne sont jamais tirées dans une situation conflictuelle
avec d’autres transitions immédiates. Dans le cas contraire, le poids de ces deux transitions est
important car elles définissent la probabilité de l’inconsistance du résultat après l’exécution
parallèle.
89
Tnewdata
tstart
Tpar1
Tpar2
Tcheck
tsyn
tko
tok
Ti/o
Figure 3.12 : Exemple d’un GSPN avec des transitions immédiates et des transitions
temporisées
3.10. Les analyses effectuées
Ce sont des analyses orientées performances, c'est-à-dire elles exploitent l’attribut
stochastique du modèle. La plus grande partie des analyses sont supportées par des réseaux de
Petri stochastiques semi-markoviens bornés dont le graphe des marquages est fortement
90
connexe. Les analyses basées sur les graphes des marquages (états) consistent en des analyses
en régime permanent (probabilité des marquages, fréquences moyennes de tir de transitions,
temps de séjour dans un marquage, …) et en régime transitoire (temps moyen de premier
passage dans un marquage). Dans le cas de graphe des marquages acycliques, nous pouvons
faire des analyses en régimes transitoire (temps moyen pour atteindre un marquage puits).
Notons que dans le cas des systèmes complexes, nous obtenons des graphes de marquages de
très grande taille, donc difficiles à analyser, ce qui a induit à des travaux pour développer des
techniques de modélisation afin de maîtriser la dimension des graphes et donc gérer la
difficulté de l’analyse.
3.11. Conclusion
Dans ce chapitre, nous avons défini les concepts de base des méthodes et langages formels et
leurs techniques d’utilisation, notamment dans le contexte IDM. Nous nous sommes
intéressés aux avantages et inconvénients qui émergent de leur combinaison. Nous avons
également présenté les réseaux de Petri de façon générale en mettant l’accent sur leur aptitude
à décrire les aspects dynamiques d’un système. Des concepts tels que la concurrence ou la
synchronisation entre interactions s’expriment aisément dans ce cadre. Les GSPN qui sont
une manière d’introduire la notion du temps dans les réseaux de Petri ont été introduits à la fin
de ce chapitre.
91
Chapitre 4 : Une approche de
transformation des diagrammes de
séquence et des diagrammes d’étatstransitions en réseaux de Petri GSPN à
l’aide des transformations de graphes
92
Chapitre 4
Une approche de transformation des diagrammes de
séquence et des diagrammes d’états-transitions en réseaux
de Petri GSPN à l’aide des transformations de graphes
4.1. Introduction
Dans ce chapitre, nous proposons une approche et un outil pour la transformation des
diagrammes d’états-transitions et des diagrammes de séquence vers les GSPN. Notre
approche est basée sur la transformation de modèles. Un diagramme d’états-transitions est
utilisé pour modéliser un objet, et un diagramme de séquence est utilisé pour modéliser les
interactions entre les objets d’un système. Le résultat de la transformation (modèle GSPN)
sera ensuite l’entrée de l’outil TINA [TINA] pour vérifier les propriétés telles que l’interblocage, l’équité, etc.
Notre approche suit le schéma suivant : (Figure 4.1)
Diagramme
d’étatstransitions
Notre outil de
transformation
GSPN
Diagramme de
séquence
TINA
Analyse des
propriétés
Figure 4.1 : Schéma de notre approche
Le passage des diagrammes UML 2.0 vers leurs équivalents en GSPN a été réalisé par une
transformation de graphes. Cette transformation est réalisée sous l’environnement de
93
programmation Java Eclipse. Les diagrammes de séquence et les diagrammes d’étatstransitions sont réalisés en conformité avec leurs méta-modèles respectifs. Le scénario de la
transformation est représenté dans la figure 4.2.
Définition de la
transformation
Méta-modèle UML 2.0
Réfère à
Conforme à
Méta-modèle GSPN
Réfère à
Conforme à
Exécute
Modèles UML 2.0
Lit
Moteur de
transformation
Modèle GSPN
Ecrit
Figure 4.2 : Scénario de notre transformation
4.2. Réalisation dans Eclipse
Ce que nous avons réalisé sous Eclipse consiste en la création de trois librairies de métamodèles et une librairie de grammaire agissant comme moteur de transformation. Il est à noter
que cet outil ne rentre pas dans le cadre des plugins Eclipse, car le moteur de transformation
ne dépend pas de l’environnement Eclipse, mais peut également s’exécuter sur le shell ou sur
n’importe quel ordinateur doté de Java. D’ailleurs, c’est pour cette raison que nous avons
intentionnellement évité l’utilisation des environnements dédiés d’Eclipse afin de permettre à
notre approche d’être générique et indépendante de l’environnement.
La figure 4.3 est une représentation de l’ensemble des librairies créées dans Eclipse.
94
Librairie de
modélisation
des
Diagrammes de
séquence
Invoque les classes
Librairies de
grammaire de
transformation
Librairie de
modélisation
des réseaux
GSPN
Invoque les classes
Librairie de
modélisation
des
Diagrammes
D’étatstransitions
Invoque les classes
Figure 4.3 : Les librairies de notre approche dans Eclipse
4.3. Les méta-modèles de notre approche
Comme nous l’avons dit précédemment, pour définir un langage de modélisation, il est
nécessaire de définir sa syntaxe abstraite et sa syntaxe concrète. Les méta-modèles
représentent pour notre approche la base de la transformation. Pour chacune de ces
transformations, chaque modèle est défini dans son propre méta-modèle. Nous avons
développé des librairies de méta-modèles pour les diagrammes de séquence, les diagrammes
d’états-transitions et les réseaux de Petri GSPN en Java sous Eclipse.
4.3.1. Méta-modèle des diagrammes de séquence
Le méta-modèle des diagrammes de séquence
« SequenceDiagram », « Objet » et « Message ».
est
composé
de
trois
classes:
 Objet
Cette classe représente les objets du diagramme de séquence. Ces objets envoient et
reçoivent des messages dans un ordre chronologique. Chaque objet est désigné par son
nom.
 Message
Cette classe représente les messages échangés entre les objets. Chaque message est
étiqueté par le nom de l'opération qui lui correspond, l’objet qui l’envoie et celui qui le
reçoit. Ces messages sont testés dans cette classe, ils peuvent être synchrones ou
asynchrones, retardés ou non-retardés.
95
 SequenceDiagram
Cette classe a pour fonction d’associer les messages aux objets qui communiquent, et
ainsi construire le diagramme de séquence final.
La figure 4.4 montre le méta-modèle des diagrammes de séquence que nous avons
implémenté en Java.
Source
-name
+toString()
Target
-Operation
-Ordre
-Async
-Delayed
+toString()
Figure 4.4 : Méta-modèle des diagrammes de séquence
4.3.2. Méta-modèle des diagrammes d’états-transitions
Le méta-modèle des diagrammes d’états-transitions comporte essentiellement trois classes,
« State », « Transition » et « Statechart » :
 State
Cette superclasse représente les états du diagramme d’états-transitions. Chaque état
possède un nom, et peut avoir ou non des activités associées. Deux classes héritent de
cette classe :
 CompState : Représente les états composites.
 SimpState : Représente les états simples.
 Transition
Cette classe représente les actions lors du changement d’états à travers les transitions.
Chaque transition est étiquetée par l’événement «event» et le nom de l’action.
96
 Statechart
Cette classe associe les transitions aux états et construit le modèle final.
La figure 4.5 montre le méta-modèle des diagrammes d’états-transitions que nous avons
implémenté en Java.
+display()
Source
-name
+ToString()
Target
-action
-event
-async
+ToString()
Figure 4.5 : Méta-modèle des diagrammes d’états-transitions
4.3.3. Méta-modèle des réseaux de Petri GSPN
Notre méta-modèle comprend trois classes « Place », « Transition » et « GSPN ». La place
initiale est la première place du GSPN dont le nom est préfixé par ‘’ini_’’ elle contient par
défaut un jeton. Nous avons implémenté en Java une contrainte qui empêche la liaison de
deux transitions ou deux places par un seul arc. Autrement dit, l’input d’une transition est
toujours une place, et l’input d’une place est toujours une transition.
97
 Place
Cette classe décrit les places du GSPN. Chaque place possède un nom et un nombre de
jetons. Une place ne peut pas être reliée à une autre place ou à elle-même comme cela
a été exprimé par la contrainte.
 Transition
Deux classes héritent de cette superclasse : Transition_i qui représente les transitions
immédiates prenant 0 unité de temps, et Transition_t qui représente les transitions
temporisées prenant une valeur aléatoire d’unités de temps. Les transitions sont
étiquetées par des noms d’actions.
 GSPN
Cette classe construit le modèle GSPN final en reliant les places aux transitions, et en
prenant en compte les contraintes sur le modèle.
La figure 4.6 montre le méta-modèle des réseaux GSPN que nous avons implémenté
en Java.
+display()
-name
-tokens
input
output
-name
T
+stoch()
Figure 4.6 : Méta-modèle du GSPN
98
4.4. Transformations dans Eclipse
Nous avons choisi Java pour implémenter les méta-modèles et la grammaire pour des raisons
de compatibilité avec les concepts orientés objet d'UML 2.0 d'un côté, et pour ses multiples
caractéristiques de simplicité, robustesse et sécurité d’un autre. Java est un langage standard et
dynamique. Le développement que nous avons réalisé permet une certaine souplesse pour des
éventuels changements ou améliorations des méta-modèles ou la grammaire. Pour ça, il suffit
de changer les classes correspondantes.
Dans un système, les objets sont caractérisés par leurs comportements. Ce comportement est
exprimé à travers un ensemble d’états que les objets peuvent adopter au cours de leurs
évolutions. Nous modélisons généralement les états d’un objet à l’aide des diagrammes
d’états-transitions [Harel85].
Par ailleurs, la dynamique d’un système est définie par l’interaction entre les objets de ce
dernier. Cette interaction est permanente. Pour notre cas, nous avons choisi les diagrammes de
séquence pour modéliser cette interaction puisqu’elle exprime le temps. Les objets du
diagramme de séquence sont eux-mêmes des diagrammes d’états-transitions. De ce fait,
modéliser cette communication revient à relier les diagrammes d’états-transitions
correspondants aux objets du diagramme de séquence, en créant des liens entre les GSPN
correspondants. Nous pourrons par la suite appliquer des outils d’analyse et de vérification au
modèle GSPN.
La figure 4.7 illustre la relation entre le diagramme de séquence, les diagrammes d’étatstransitions et le GSPN.
99
:o1
:o2
:o3
:o4
M1
M2
M3
Figure 4.7 : Relation entre diagramme de séquence et diagrammes d’états-transitions
Pour chaque objet o1, o2, o3, o4 correspond le diagramme d’états-transitions qui modélise
son ensemble d’états. Ces objets s’échangent des messages M1, M2 et M3 dans le diagramme
de séquence.
Pour automatiser la transformation, nous avons créé des librairies de grammaires de
transformations dont l’une pour la transformation des diagrammes de séquence vers les
GSPN, et la seconde pour la transformation des diagrammes d’états-transitions vers les
GSPN. Chaque grammaire est composée d’un ensemble de classes avec des méthodes pour
convertir chacun des diagrammes UML 2.0 vers son équivalent en GSPN. La figure 4.8
illustre les étapes de transformations entre les modèles.
100
Diagramme d’étatstransitions SC1
M1
M3
M2
Transformation 1 : diagramme de séquence vers GSPN
Op :m1
Transformation 2 : diagramme d’états-transitions vers GSPN
Op :m1
SC1
SC2
Figure 4.8 : Transformations en GSPN
La transformation des diagrammes de séquence en GSPN consiste en la transformation des
messages échangés entre les objets du système en leurs équivalents de transitions dans le
réseau GSPN suivant la grammaire. En considérant que les objets sont modélisés en
diagrammes d’états-transitions, ces diagrammes d’états-transitions sont transformés en
diagrammes GSPN, en faisant correspondre les transitions dans un diagramme d’états-
101
transitions aux transitions dans un GSPN. Le GSPN final sera soumis à l’outil TINA pour
l’analyse et la vérification.
a- Transformation 1 : Diagrammes de séquence vers GSPN
Il s’agit de transformer un message M (figure 4.9) échangé entre deux objets
o1 et o2. Les objets o1 et o2 sont en réalité deux diagrammes d’étatstransitions, mais dans une première transformation, on fait abstraction des
diagrammes d’états-transitions représentants les états des objets qui
communiquent, et on ne s’intéresse qu’au message échangé M. Le message M
sera transformé suivant la grammaire « DS vers GSPN » qui transforme les
diagrammes de séquence en modèle GSPN, suivant si les messages sont
synchrones ou non, retardés ou non. Les places dans le GSPN représentent les
messages prédécesseurs et successeurs, ceci pour maintenir l’enchainement et
l’ordre des messages dans le diagramme de séquence.
:o1
:o2
M
« DS vers GSPN »
M
m1,m2
Figure 4.9 : Schéma de la première transformation des diagrammes de séquence vers les
GSPN
102
b- Transformation 2 : Diagrammes d’états-transitions vers GSPN
Puisque les objets o1 et o2 sont des diagrammes d’états-transitions (figure
4.10), la deuxième étape consiste en la transformation des diagrammes d’étatstransitions relatifs aux objets o1 et o2 en leurs équivalents en modèle GSPN
suivant la grammaire « SC vers GSPN ».
:o1
:o2
:o2
M
« SC vers GSPN »
:o2
:o1
:o2
M
Figure 4.10 : Schéma de la deuxième transformation des diagrammes d’états-transitions vers
les GSPN
103
c- Combinaison de transformations et raffinement
Les actions sont ce qui lie le diagramme d’états-transitions aux messages du
diagramme de séquence. L’achèvement d’un message
représente la
terminaison d’une action relative à l’envoi du message et accomplie par l’objet
émetteur. Prenons un message M échangé entre deux objets o1 et o2. Dans le
diagramme d’états-transitions de l’objet émetteur du message (o1), il existe au
moins une action qui cause l’envoi de ce message, et dans le diagramme
d’états-transition de l’objet récepteur de M (o2), il existe au moins une
transition qui modélise la réponse à l’événement qui représente la réception du
message. Le GSPN du diagramme d’états-transitions complet sera construit en
reliant les places des événements et les places « ack_ » de l’ensemble des
diagrammes d’états-transitions, en se basant sur la nature de la communication
représentée dans le GSPN du diagramme de séquence.
:o1
:o2
e_event
ack_event
Figure 4.11 : Combinaison des deux transformations
L’aspect stochastique intervient dans ces transformations pour attribuer un temps aléatoire
aux transitions temporisées. Nous aurons besoin de modéliser également des transitions
immédiates prenant zéro unité de temps. Cette propriété de coexistence entre les deux types
de transitions représente l’aspect dit « Généralisé » dans les réseaux GSPN.
104
4.4.1. Grammaire de transformation des diagrammes de séquence vers les réseaux de
Petri GSPN « DS vers GSPN »
Cette transformation est le résultat de l’exécution d’une grammaire de graphe, exprimée en
Java dans Eclipse. Cette grammaire comporte un ensemble de règles, se déroulant dans un
ordre défini par des priorités, et de manière itérative.
La transformation des diagrammes de séquence en réseaux de Petri GSPN suit l’ensemble de
règles suivant (figure 4.12) :
Figure 4.12 : Grammaire de transformation des diagrammes de séquence vers le modèle
GSPN
Les places dans le GSPN représentent les messages prédécesseurs et les messages
successeurs.
La première règle concerne les messages asynchrones non-retardés (Asynchronous=True et
Delayed=False). Quand les conditions de l’application de cette règle sont vérifiées, la
grammaire génère un sous-diagramme GSPN de deux états et une transition immédiate
étiquetée par le nom de l’opération du message.
La deuxième règle concerne les messages synchrones et non-retardés (Asynchronous=False et
Delayed=False). Lorsque cette règle est appliquée, la grammaire génère deux transitions
immédiates pour le début et la fin de l’opération du message synchrone (Start_op et End_op)
respectivement.
La troisième règle transforme les messages asynchrones et retardés du diagramme de
séquence. Cette règle nous montre l’intervention de l’aspect stochastique dans le formalisme
105
GSPN lorsque la règle génère une transition temporisée, avec un temps aléatoire pour
l’exception. La règle génère aussi une transition immédiate pour l’opération. Ce mélange de
transitions immédiates et temporisées constitue la force du formalisme GSPN.
La quatrième règle concerne les messages synchrone et retardés (Asynchrone=False et
Delayed=True). Cette règle créé trois transitions, deux transitions immédiates pour le début et
la fin de l’opération du message, et entre ces deux transitions une transition temporisée pour
l’exception. Cette règle fait intervenir l’aspect généralisé et stochastique du formalisme GSPN
puisqu’elle créé deux transitions immédiates et une transition temporisée avec un temps
aléatoire.
Chacune des règles possède une priorité et un ordre d’exécution. La grammaire commence
son exécution du haut des lignes de vie des objets, jusqu’au dernier message à la fin des lignes
de vie. Dans cette grammaire on n’applique qu’une seule règle sur chaque message.
4.4.2. Grammaire de transformation des diagrammes d’états-transitions vers les réseaux
de Petri GSPN « SC vers GSPN »
Nous avons implémenté une grammaire de graphe qui contient 10 règles divisées en trois
ensembles :
Le premier ensemble de la figure 4.13 est composé de quatre règles (1, 3, 5, 9), et traite des
cas de transitions où les actions sont asynchrones. L’état input dans les règles 1 et 3 contient
des activités qui sont transformées en transitions temporisées en GSPN. Lorsque les actions
sont provoquées par des événements « e_event », elles l’utilisent et placent un jeton « evw »
dans une place « ack_event ».
106
Figure 4.13 : Premier ensemble de la grammaire de transformation des diagrammes d’étatstransitions vers les GSPN
Le second ensemble de la figure 4.14 traite des cas où les actions sont synchrones avec 4
règles (2, 4, 6, 10). Dans chacune de ces règles, les actions des transitions sont synchrones,
avec ou sans événement. Les actions synchrones sont modélisées par deux transitions
immédiates en GSPN, l’une pour le début de l’action et l’autre pour sa terminaison. Quand
l’action débute, un jeton est placé dans la place « e_start_action », et l’action se termine
lorsqu’un jeton est retiré de la place « ack_start_action ».
107
Figure 4.14 : Deuxième ensemble de la grammaire de transformation des diagrammes d’étatstransitions vers les GSPN
Le troisième ensemble de la figure 4.15 est consacré aux règles où il n’y a ni action ni
événement (9, 10), et donc les transitions franchissent immédiatement.
108
Figure 4.15 : Troisième ensemble de la grammaire de transformation des diagrammes d’étatstransitions vers les GSPN
Les transitions temporisées relatives aux états possédant des activités renvoient vers la
propriété stochastique des GSPN puisque ces transitions temporisées modélisent un temps
aléatoire, ainsi qu’avec les transitions immédiates, le réseau est généralisé puisqu’il contient
les deux types de transitions.
4.5. Conclusion
Dans ce chapitre, nous avons proposé une approche et un outil Java pour la modélisation et la
transformation des modèles de diagrammes de séquence et de diagrammes d’états-transitions
vers les réseaux GSPN en utilisant les techniques de transformation de graphes sur Eclipse.
Pour cela, nous avons proposé trois méta-modèles, deux pour les modèles inputs (diagrammes
de séquence et diagrammes d’états-transitions) et un autre pour le modèle output (GSPN). En
nous basant sur ces trois méta-modèles, nous avons proposé deux grammaires de graphes qui
effectuent les transformations.
109
Chapitre 5 :
Cas d’utilisation
110
Chapitre 5
Cas d’utilisation
5.1. Introduction
Dans ce chapitre, nous allons appliquer notre outil présenté dans le chapitre précédent sur un
exemple de diagramme de séquence et un diagramme d’états-transitions. Le diagramme de
séquence montre l’échange de messages entre un internaute qui souhaite s’inscrire à une
formation en ligne et le serveur. Les états de l’utilisateur sont ensuite modélisés dans un
diagramme d’états-transitions. La transformation des deux diagrammes se déroulera sous
l’environnement de développement Eclipse.
5.2. Diagramme de séquence pour inscription à une formation E-learning
La figure 5.1 montre un diagramme de séquence d’un utilisateur (internaute) souhaitant
s’inscrire à une formation en ligne suivant les étapes :
1. L’utilisateur se connecte au serveur puis procède à une demande de formation.
2. Le serveur communique avec sa base de données pour obtenir la liste des
formations disponibles.
3. La base de données fournit au serveur la liste des formations disponibles, et ce
dernier doit l’afficher à l’utilisateur.
4. L’utilisateur fait son choix et l’envoie au serveur.
5. Le serveur demande un questionnaire qu’il renvoi à l’utilisateur.
6. Au final, l’utilisateur répond au questionnaire et le serveur, selon le résultat du
test, accepte ou refuse de l’inscrire.
111
:Internaute
:Serveur
:Questionnaire
:BD
Login()
Demander_liste_formations_dispo()
Retourner_liste_formations_dispo()
Liste_formations()
Choix_formation()
Demander_questionnaire()
Envoyer_questionnaire()
Envoyer_réponses()
Test_aptitude()
Envoyer_résultat()
confirmer()
Figure 5.1 : Diagramme de séquence d’une demande de formation e-learning
112
5.3. Diagramme d’états-transitions de l’objet « Internaute » dans le diagramme de
séquence
Nous avons pris une instance de la classe « Internaute » pour modéliser les états par lesquels
l’internaute passe pour s’inscrire.
Après s’être connecté, l’internaute reçoit le questionnaire auquel il devra répondre. L’état
composite « Test_aptitude » fait passer les niveaux de l’internaute de 1 à 4. Une fois le test
terminé, l’internaute est soit admis dans la formation, soit refusé.
La figure 5.2 présente le diagramme d’états-transitions de l’internaute.
Test_aptitude
Deconnecté
Niveau1
Niveau2
Niveau4
Niveau3
Login()
Connecté
Do :
choisir_formation
notif /recep_quest
/refuser
Refusé
/confirmer
/inscrire
Admis
/confirmer
Figure 5.2 : Diagramme d’états-transitions d’une instance de la classe « Internaute »
113
5.4. Implémentation du diagramme de séquence et génération du modèle
Nous avons modélisé le diagramme de séquence de l’exemple précédent sous Eclipse de la
façon suivante (figure 5.3) :
Figure 5.3 : Diagramme de séquence dans Eclipse
114
5.4.1. Application de la transformation sur le diagramme de séquence
Après avoir lancé la grammaire de transformation sur le modèle de diagramme de séquence,
le déroulement des règles s’est fait dans l’ordre suivant (figure 5.4) :
Figure 5.4 : Grammaire appliquée au diagramme de séquence dans Eclipse
115
5.4.2. Diagramme GSPN après la transformation du diagramme de séquence
Le moteur de transformation nous a présenté le résultat en GSPN comme montré dans la
figure 5.5 (et représentation graphique dans la figure 5.6):
Remarque : Les transitions dénotées par des crochets ‘’ [ ] ‘’ dans le GSPN représentent les
transitions temporisées avec les valeurs aléatoires du temps.
Figure 5.5 : GSPN après transformation du diagramme de séquence dans Eclipse
Login()
Demander
_liste
m1,m2
retourner
_liste
m2,m3
ExcepReto Liste_form
urner_list ations
e
m3,m4
Choix_for
mations
m4,m5
Demande
_quest
m5,m6
Envoyer
_quest
m6,m7
m11,m12 m10,m11
Envoyer_rép
onse
Start_test_
(e_notif)
apti
m7,m8
m8,m9
End_test
_apti
m9,m10
Confirmer End_envo_
ExcepEnvoyer_ Start_envo
resultat
_resultat
résul
116
5.5. Implémentation du diagramme d’états-transitions et génération du modèle
La transcription du modèle de diagramme d’états-transitions dans Eclipse s’est faite de la
manière suivante (figure 5.7) :
Figure 5.7 : Diagramme d’états-transitions dans Eclipse
5.5.1. Application de la transformation sur le diagramme d’états-transitions
Les règles de transformation ont suivi l’ordre présenté dans la figure 5.8.
Figure 5.8 : Grammaire appliquée au diagramme d’états-transitions dans Eclipse
117
5.5.2. Diagramme GSPN après la transformation du diagramme d’états-transitions
Le résultat GSPN après la terminaison de la transformation du diagramme d’états-transitions
est donné par la figure 5.9 (et représentation graphique dans la figure 5.10).
Figure 5.9 : GSPN après transformation du diagramme d’états-transitions
Pour des raisons de lisibilité, nous n’avons pas fait la représentation graphique dans la figure
5.10 des transitions internes de l’état composite [Test_aptitude].
118
e_notif
Ack_notif e_start
ack_start
Ini_déco
Connecté.exit
6
Déco.entry
login
Déco.exit
7
9
8
Ini.connec choisir_form eventnotif Start_recep end_recep
té
Test_aptitude.entry
32
28
refuser
inscrire
33
29
Test_aptitude.exit
Ini_refusé
Ini_admis
Refusé.entry
Admis.entry
40
36
confirmer
41
Refusé.exit
37
Admis.exit
Etat_final
5.6. Vérification du GSPN
Pour analyser les propriétés du GSPN de la partie illustrée dans la figure 5.11, nous avons
appliqué l’analyseur TINA dans la figure 5.12.
:User
:Server
:Questionnaire
:BD
Login()
Envoyer_questionnaire()
Figure 5.11 Partie du GSPN du système modélisé à vérifier
119
Remarque : Dans l’outil TINA, les transitions immédiates sont modélisées par des transitions
où la valeur du temps est dans l’intervalle [0,0].
La figure 5.12 montre la représentation du GSPN dans l’outil TINA en faisant le lien entre la
transition dans le diagramme d’états-transition de l’objet « internaute » et l’objet
questionnaire.
Figure 5.12 : GSPN dans TINA
Après le lancement de l’outil d’analyse, nous avons obtenu le résultat dans la figure 5.13
120
Figure 5.13 : Analyse du GSPN
5.6.1. Interprétation des résultats
D’après les résultats :



Bounded = Y : Le réseau est borné.
Live = N : Le réseau n’est pas vivant.
À partir de la colonne « dead » nous déduisons qu’il existe un état mort et 10
transitions infranchissables.
Nous pouvons à présent conclure que le système contient une situation d’inter-blocage.
121
5.7. Conclusion
Dans ce chapitre, nous avons présenté une étude de cas où nous avons appliqué les outils de
transformations sous Eclipse aux diagrammes de séquence et d’états-transitions d’un système
d’inscription à une formation e-learning. Le GSPN a été exploité par TINA qui nous a donné
le résultat de l’analyse.
122
Conclusion générale
Le travail que nous avons présenté est situé dans le cadre de la modélisation et la vérification
multi-paradigmes basée principalement sur les principes de l’IDM. Cette thèse combine deux
langages de modélisation : le premier, UML 2.0, qui est considéré de nos jours comme le
langage standard de modélisation dans l'industrie du logiciel, le second est le formalisme des
réseaux de Petri GSPN, qui permet la modélisation et l’analyse du comportement des
systèmes complexes.
Dans le présent travail, nous avons montré l’intérêt ainsi que la faisabilité de l’utilisation
conjointe des diagrammes de séquence et diagrammes d’états-transitions d’UML 2.0 et les
réseaux de Petri GSPN.
Nous avons proposé une approche et un outil sous Eclipse. Ce support est un ensemble de
librairies de classes Java. La création de ces librairies constitue l’étape de méta-modélisation.
Le support qu’offrent ces librairies permet de modéliser des diagrammes de séquence et des
diagrammes d’états-transitions d’un côté, et supporter le formalisme GSPN de l’autre.
Dans Eclipse, nous avons implémenté un moteur de transformation qui effectue les différentes
transformations de graphes des diagrammes de séquence et des diagrammes d’états-transitions
en modèles GSPN. Ce moteur de transformation repose sur une grammaire de graphe
constituée d’un ensemble de règles ayant chacune une priorité préétablie. Chaque
transformation possède sa propre grammaire, nous avons implémenté une grammaire pour la
transformation des diagrammes de séquence vers le modèle GSPN, et une autre pour la
transformation des diagrammes d’états-transitions en GSPN. Les modèles GSPN résultants
ont été interprétés par l’outil d’analyse TINA.
Dans de futurs travaux, nous envisageons de transformer d’autres diagrammes d’UML 2.0
vers les réseaux de Petri stochastiques, et automatiser la génération des GSPN sous la forme
syntaxique acceptée par l’outil TINA à partir de la représentation Java des GSPN. Nous
envisageons aussi de valider notre approche par des études de cas réelles.
123
Bibliographie
[AD 68] D.A. Adams : A computational model with data-flow sequencing, Computer science
dept.. Technical report CS-117, Stanford University, California, Dec 1968.
[AFIS] AFIS: L’Ingénierie Système. http://www.afis.fr/praout/ingsys/ingsys.htm.
[AGG06] AGG home page. http ://tfs.cs.tu-berlin.de/agg, Last Consultation : October 2006.
[Ajmone95] M. Ajmone Marsan, G. Balbo, G. Conte, S. Donatelli and G.
Franceschinis Modelling with Generalized Stochastic Petri Nets Wiley Series in Parallel
Computing John Wiley and Sons ISBN: 0 471 93059 8
[Andries99] Marc Andries, Gregor Engels, Annegret Habel, Berthold Hoffmann, Hans-Jorg
Kreowski, Sabine Kuske, Detlef Pump, Andy Schürr and Gabriele Taentzer, "Graph
transformation for specification and programming", Science of Computer programming, vol
34, NO°1, pages 1-54, Avril 1999.
[AToM3] AToM3 (2006). Home page: http://atom3.cs.mcgill.ca/
[Attiogbé07] J. Christian Attiogbé, "Contributions aux approches formelles de
développement de logiciels : Intégration de méthodes formelles et analyse multifacette", In
HDR, Université de Nantes, Nantes Atlantique Université, 13 septembre 2007.
[Balasubramanian06] Daniel Balasubramanian, Anantha Narayanan, Chris vanBuskirk and
Gabor Karsai, "The Graph Rewriting and Transformation Language: GReAT", In A. Zündorf
and D. Varró, editors, Proceedings of the Third International Workshop on Graph Based
Tools (GraBaTs 2006), volume 1 of ECEASST, 2006.
[BBJ07] Bezivin, J., M. Barbero, and F. Jouault:On the applicability scope of model driven
engineering. In Proceedings of the 4th International Workshop on Model-based
Methodologies for Pervasive and Embedded Software (MOMPES 2007), at the Eu-ropean
Joint Conferences on Theory and Practice of Software (ETAPS 2007), pages 3–7. IEEE
Computer Society, March 2007.
[BDM02] Bernardi S, Donatelli S, and Merseguer J, "From UML 2.0 sequence diagrams and
statecharts to analyzable petri net models". In Proceedings of the 3rd International workshop
on software and performance (WOSP), 2002.
[Behrmann04] Gerd Behrmann, Alexandre David and Kim G. Larsen, " A tutorial on
UPPAAL", In Proceedings on the International School on Formal Methods for the Design of
Computer, Communication, and Software Systems, volume 3185 of Lecture Notes in
Computer Science, pages 200-236, Bertinora, Italy, Springer-Verlag.2004.
124
[Benzaken91] Claude Benzaken, "Systèmes Formels: Introduction à la logique et à la théorie
des langages", Editions Masson, 1991.
[Bernot91] Gilles Bernot, Marie-Claude Gaudel, and Bruno Marre, "Software testing
based on formal specifications: a theory and a tool", Software Engineering Journal,
6(6):387–405, ISSN 0268-6961, November 1991.
[Bert95] Didier Bert, Rachid Echahed, Paul Jacquet, Marie-Laure Potet and Jean-Claude
Reynaud, "Spécification, généricité, prototypage : aspects du langage LPG", In Technique et
Science Informatiques, 14(9): pages 1097-1129, Hermes 1995.
[Bettaz92] Mohamed Bettaz and Mourad Maouche, "How to specify Non Determinism and
True Concurrency with Algebraic Term Nets", Lecture Notes in Computer Science, N 655,
Spring Verlag, Berlin, pages 11-30, 1992.
[Bettaz93] Mohamed Bettaz, Mourad Maouche, Moussa Soualmi and Madani Boukebeche.
"Protocol Specification Using ECATNets", Networking and Distributed Computing, pp 7-35,
1993.
[Bézivin 04] Jean Bézivin, "Sur les principes de base de l’ingénierie des modèles", RSTIL'Objet,. 10(4) :145–157, 2004.
[Boo94]Grady Booch (Author), Robert A. Maksimchuk (Author),Michael W.
Engel (Author), Bobbi J. Young (Author), Jim Conallen(Author), Kelli A.
Houston (Author)Object-Oriented Analysis and Design with Applications 1994.
[Burmester04] Sven Burmester, Holger Giese, Jorg Niere, Matthias Tichy, Jorg P. Wadsack,
Robert Wagner, Lothar Wendehals and Albert Zundorf, "Tool Integration at the Meta-Model
Level within the FUJABA Tool Suite", International Journal on Software Tools for
Technology Transfer (STTT), vol. 6, n° 3, p. 203-218, 2004.
[Charles97] Nathan Charles, Howard Bowman and Simon J. Thompson, "From Act-one to
Miranda, a Translation Experiment", In Computer Standards and Interfaces Journal, 19(1),
May 1997.
[Cliff86] Jones Cliff, "Systematic Software Development Using VDM", Prentice-Hall ISBN
978-0138807252, 1986
[CPNAMI] home page : http://move.lip6.fr/software/CPNAMI/
[CPNtools] home page : http://cpntools.org/
[Czarnecki03] Krzysztof Czarnecki and Simon Helsen, "Classification of Model
Transformation Approaches", OOPSLA’03 Workshop on Generative Techniques in the
Context of Model-Driven Architecture, 2003.
125
[Czarnecki06] Krzysztof Czarnecki and Simon Helsen, "Feature-based survey of model
transformation approaches", IBM Syst. J., 45(3):621–645, ISSN 0018-8670, 2006..
[Davis03] James Davis, "GME: the generic modeling environment", In OOPSLA ’03:
Companion of the 18th annual ACM SIGPLAN conference on Object-oriented
programming, systems, languages, and applications, pages 82–83, New York, NY, USA,
ACM, ISBN 1-58113-751-6, 2003.
[De Lara02] Juan De Lara and Hans Vangheluwe, "AToM3: A Tool for Multi-Formalism
Modelling and Meta-Modelling", In Proceedings of Fundamental Approaches to Software
Engineering, FASE'02, Vol. 2306. LNCS. Grenoble, France, pages 174-188, 2002.
[Deng93] Yi Deng, Shi-Kuo Chang, Jorge C. A. de Figueired and Angelo Psrkusich, "
Integrating Software Engineering Methods and Petri Nets for the Specification and
Prototyping of Complex Information Systems", In Proceedings of the 14th International
Conference on Application and Theory of Petri Nets, Chicago, 206-223, 1993.
[EC82] E. Allen Emerson and Edmund M. Clarke. Using Branching Time Temporal Logic to
Synthesize Synchronization Skeletons. Science of Computer Programming 2(3): Pages 241266.
[Ehrig05] Karsten Ehrig, Claudia Ermel and Stefan Hansen, "Towards Model transformation
in Generated Eclipse Editor Plug-ins", Preliminary Version, GraMoT - International
Workshop on Graph and Model Transformation, Institut für Softwaretechnik und
Theoretische Informatik Technische Universität Berlin, 2005.
[Engels00] Gregor Engels, Jan Hendrik Hausmann, Reiko Heckel and Stefan Sauer,
"Dynamic Meta Modeling: A Graphical Approach to the Operational Semantics of Behavioral
Diagrams in UML", In Proceedings of the 3rd International Conference on the UML 2000,
YORK, ROYAUMEUNI, Octobre 2000.
[EMF] Eclipse Modeling Framework Home Page : http://www.eclipse.org/modeling/emf/
[Favre 06] Jean-Marie Favre , Jacky Estublier and Mireille Blay-Fornarino, " L’Ingénierie
Dirigée par les Modèles: au-delà du MDA", Traité IC2 – Information – Commande –
Communication, Hermès – Lavoisier, 2006.
[FrB05] Franck BarbierUml 2 et MDE ingénieriedes modèles avec études de cas
Etude (broché). Paru en 11/2005.
[FUJABA] FUJABA Home page, http://www.fujaba.de/
[Gargantini09] Angelo Gargantini, Elvinia Riccobene and Patrizia Scandurra, " Integrating
Formal Methods with Model-driven Engineering ", In Proceedings of the Fourth International
126
Conference on Software Engineering Advances, Porto, Portugal , ISBN: 978-0-7695-3777-1,
2009.
[GEF] Graphical Editing Framework Home Page : http://www.eclipse.org/gef/
[Genrich81] Hartmann J. Genrich and Kurt Lautenbach, "System Modelling with High-Level
Petri Nets", In Proceedings of the Theoretical Computer Science, vol. 13, 1981.
[GME] Generic Modeling Environment Home Page : http://www.eclipse.org/modeling/
[GMF] Graphical Modeling Frameworkhttp://www.eclipse.org/modeling/gmp/
[GMT] Generative Modeling Technologies Home Page : http://www.eclipse.org/gmt/
[Goguen96] Joseph A. Goguen and Malcolm Grant, "Algebraic Semantics of Imperative
Programs", The MIT Press, ISBN 978-0262071727, May 22, 1996.
[GreatSPN] home page : http://www.di.unito.it/~greatspn/index.html
[Greenfield04] Jack Greenfield, Keith Short, Steve Cook, Stuart Kent and John Crupi, "
Software Factories: Assembling Applications with Patterns, Models, Frameworks, and
Tools", Wiley & Sons, 2004.
[Guangyu09] Guangyu Li and Shuzhen Yao, "Research on Mapping Algorithm of UML
Sequence Diagrams to Object Petri Nets", In Proceedings of the 2009 WRI Global Congress
on Intelligent Systems. V(4), pages 285 – 289,19-21 May 2009.
[Guerra03] Esther Guerra and Juan de Lara, "A Framework for the Verification of UML
Models. Examples using Petri Nets", Escuela Politecnica Superior, Ingeniera Informatica,
Universidad Autonoma de Madrid, 2003.
[Guttag85] John V. Guttag, James J. Horning and Jeannette M. Wing, "The Larch Family of
Specification Languages", In Software, IEEE , ISSN 0740-7459 vol 2 . pp. 24-36. Sept. 1985.
[Harel 85] David Harel and Amir Pnueli, "Logics and models of concurrent systems", volume
13 of Nato Asi Series F: Computer And Systems Sciences, chapter On the
development of reactive systems, pages 477–498. Springer-Verlag New York, ISBN 0387-15181-8, New York, NY, USA, 1985.
[Holland 98] John .H Holland, "Emergence: From Chaos to Order", Helix Books AddisonWesley, 1998.
[Holscher06] Karsten Holscher, Paul Ziemann and Martin Gogolla, "On translating UML
models into graph transformation systems", Journal of Visual Languages and Computing,
pages 78-105, ELSEVIER, 2006.
127
[INA] INA home page : www2.informatik.hu-berlin.de/~starke/ina.html
[INCOSE] INCOSE: A Consensus of the INCOSE Fellows.
http://www.incose.org/practice/fellowsconsensus.aspx.
[ISO 8402] ISO 8402 Qualité: Concepts et Terminologie. Partie 1: Termes génériques et
Définitions.
[JARP] home page : http://jarp.sourceforge.net/
[JBR97a] I. Jacobson, G. Booch, and J. Rumbaugh. The Objectory Software Development
Process. Addison Wesley, 1997.
[JCJO92] Ivar JACOBSONObject-Oriented Software Engineering (OOSE) 1992
http://cs-exhibitions.uni-klu.ac.at/index.php?id=448
[Jensen97] Kurt Jensen, "A Brief Introduction to Coloured Petri Nets", Lecture Notes in
Computer Science, No 1217, Springer-Verlag, 1997, pp 203-208.
[Jensen98] Kurt Jensen, "An Introduction to the Practical Use of Coloured Petri Nets",
Lecture
[JuaGal97 ] Guy JUANOLE et Laurent GALLON : Analyses qualitatives et quantitatives
basées sur des réseaux de Petri Stochastriques et concept d’automate quotient quantifié 1997.
Notes in Computer Science, No 1492, Springer-Verlag, pp 237-292, 1998.
[Karsai04] Gabor Karsai and Aditya Agrawal, "Graph Transformations in OMG’s ModelDriven Architecture", Lecture Notes in Computer Science, Vol 3062, 243-259, Springer
Berlin /Heidelberg, juillet 2004.
[Kent02] Stuart Kent, "Model driven engineering", In Butler, Michael J., Luigia Petre, and
Kaisa Sere (editors): Third International Conference on Integrated Formal Methods (IFM),
volume 2335 of Lecture Notes in Computer Science, pages 286–298, Turku, Finland,
Springer, May 2002.
[Kerkouche08] Elhillali Kerkouche and Alloua Chaoui, "On the use of Meta-Modelling and
Graph Grammars to process and simulate ECATNets model", In proceedings of MS'2008,
Port Said, EGYPT, April 8-10, 2008.
[Kerkouche09a] Elhillali Kerkouche and Alloua Chaoui. "A Graphical Tool Support to
Process and Simulate ECATNets Models Based on Meta-Modelling and Graph Grammars",
INFOCOMP Journal of Computer Science, Vol. 8, N° 4, pp. 37-44, 2009.
[Kerkouche10]Elhillali Kerkouche, Allaoua Chaoui, El Bay Bourennane, Ouassila Labbani
On the Use of Graph Transformation in the Modeling and Verification of Dynamic Behavior
in UML Models 2010.
128
[Kerkouche11] Elhilali Kerkouche , Thèse de doctorat : Modélisation Multi-Paradigme: Une
Approche Basée sur la Transformation de Graphes
[kuske02] Sabin kuske, Martin Gogolla, Ralf Kollman and Hans-Jorg Krewoski, "An
integrated sementics for UML Class, Object and state diagrams based on graph
transformation", In Proceedings of Third International Conference on Integrated Formal
Methods (IFM’02), Lecture Notes in Computer Science, M. Butler, K. Sere (Eds.), vol. 2335,
pages 11-28, Springer, Berlin, 2002.
[Lavagno03] Luciano Lavagno, Grant Martin and Bran V. Selic, "UML for real:
design of embedded real-time systems", Kluwer Academic Publishers, Norwell, MA,
USA, 2003, ISBN 1-4020-7501-4.
[LoLa] home page : http://www.informatik.uni-rostock.de/tpp/lola/
[MARIA] home page : http://www.informatik.unihamburg.de/TGI/PetriNets/tools/db/maria.html
[Marvin 68] Marvin Minsky, "Matter, mind, and models", Semantic Information Processing,
pages 425–432, 1968.
[MetaEdit] Model-based development toolMetaEdit+ http://www.metacase.com/
[Milner80] Robin Milner, "A calculus of communicating systems", in Lecture Notes in
Computer Science, vol.92, Springer-Verlag, Berlin, 1980.
[Milner93] Robin Milner, "Elements of interaction: Turing Award Lecture", Communications
of the ACM, 36(1):78–89, CODEN CACMA2. ISSN 0001-0782, January 1993.
[OMG03a] “Object Management Group: OMG Unified Modeling Language
pecification”, Version 1.5, mars 2003.
[OMG04] “Object Management Group (OMG), Model Driven Architecture (MDA)”, site
Internet, http://www.omg.org/mda,2004.
[OMGb] OMG: MetaObject Facility (MOF), version 2.0. http://www.omg.org/mof/.
[OMGc] OMG: Common Warehouse Metamodel (CWM), version 1.1. http://www.omg.
org/technology/documents/formal/cwm.htm.
[OMGd] OMG: Object Constraint Language (OCL), version 2.0. http://www.omg.org/ocl/.
[OMGe] OMG: XML Metadata Interchange (XMI), version 2.0. http://www.omg.org/xml/.
[OMGedc] UML Profile For Enterprise Distributed Object Computing (EDOC)
[OMGm] MOFM2T Model-to-Text language http://www.omg.org/spec/MOFM2T/1.0/
[OMGs] OMG : Software Process Engineering Metamodel 2.2
http://www.omg.org/spec/SPEM/2.0/
129
[OPMSE] The Modeling and Simulation Environment based on Object Petri Net for Discrete
Event Systems, Luo Xueshan (National University of Defense Technology, C3I Systems
Research Center, 410073)
[Owre93] Sam Owre, John Rushby and Natarajan Shnkar, "The PVS Specification
Languages", In http:// www.csl.sri.sri.com/pvs-language/ 1993.
[Petit99] Michaël Petit, "Formal requirements engineering of manufacturing systems: a
multiformalism and component-based approach", Thèse de doctorat de l'Université de Namur,
Belgique, Octobre 1999.
[PNK] home page : http://page.mi.fu-berlin.de/trieglaf/PNK2e/index.html
[PROD] home page : http://www.informatik.unihamburg.de/TGI/PetriNets/tools/db/prod.html
[PROGRES] PROGRES Home page, http://wwwi3.informatik.rwthaachen.de/research/projects/progres/main.html
[QS82a] JEAN-PIERRE QUEILLE AND JOSEPH SIFAKIS. A Temporal Logic to Deal with Fairness
in Transition Systems. In Proceedings of the 23rd Annual Symposium on Foundations of
Computer Science (FOCS'82), pages 217-255. IEEE Comp. Soc. Press, 1982. (BibTex).
[QVT] Query/View/Transformation http://www.omg.org/spec/QVT/1.0/
[Ranger08] Ulrike Ranger and ErhardWeinell, "The graph rewriting language and
environment PROGRES", Applications of Graph Transformations with Industrial Relevance,
LNCS, 5088, 2008.
[Roques 00] Pascal Roques and Franck Vallée, "UML en action : De l’analyse des
besoins à la conception en Java", Eyrolles, 2000.
[Rozenberg99] Grzegorz Rozenberg, "Handbook of Graph Grammars and Computing by
Graph Transformation", Vol.1. World Scientific, 1999.
[Rum96] James Rumbaugh (Auteur), William Premerlani (Auteur),Frédérick
Eddy (Auteur), William Lorensen (Auteur) OMT, tome 1 : Modélisation et conception
orientées objet 1996.
[Schürr99] Andy Schürr, Andreas J. Winter and Albert Zündorf, "The PROGRES approach :
language and environment", World Scientific Publishing Co., Inc., River Edge, NJ, USA,
pages 487–550, 1999.
[Smith02] Graeme Smith, Florian Kammuller and Thomas Santen, "Encoding Object-Z in
Isabelle/HOL", In la revue Lecture Notes in Computer Science, vol.2272, pp.82-99, 2002.
130
[Staines07] Tony Spiteri Staines, "Supporting UML Sequence Diagrams with a Processor Net
Approach", Journal of Software, VOL. 2, NO. 2, AUGUST 2007.
[Taentzer03] Gabriele Taentzer, "AGG : A graph transformation environment for modeling
and validation of software", In Proceedings of Applications of Graph Transformations with
Industrial Relevance : Second International Workshop, AGTIVE 2003,LNCS 3062, pages
446_453, Charlottesville, VA, USA, September-October, 2003.
[TINA] (TIme petri Net Analyzer) http://projects.laas.fr/tina//
[Truong06] Ninh Thuan Truong, "Utilisation de B pour la vérification de spécifications UML
et le développement formel orienté objets", Dans la thèse de doctorat en Informatique de
l’Université Nancy2, au LORIA à Vandoeuvre, 2006.
[Turner07] Kenneth J. Turner, "Representing and analysing composed web services using
CRESS", in Journal of network and computer applications, ISSN 1084-8045 vol. 30, n°2, pp.
541-562, 2007.
[UML2.0] Unified Modeling Language UML 2.0 http://www.uml.org/
[Vangheluwe02] Hans Vangheluwe, Juan de Lara and Pieter J. Mosterman, "An Introduction
to Multi-Paradigm Modelling and Simulation", Tutorial, In Proceedings AI Simulation and
Planning AIS-2002. Pages 9-20. Lisbone. Avril 2002.
[Varró03] Dániel Varró and András Pataricza, "Vpm : A visual, precise and multilevel
metamodeling framework for describing mathematical domains and uml (the mathematics of
metamodeling is metamodeling mathematics)", Software and System Modeling, 2(3) :187–
210, 2003.
[Varró06] Daniel Varró, András Balogh and András Pataricza, "The viatra2 transformation
framework - model transformation by graph transformation", Eclipse Modeling Symposium,
2006.
[Wing90] Jeannette M. Wing, "A Specifier's Introduction to Formal Methods", Computer,
vol. 23(9):8-23, 1990.
131

Une approche basée transformation de graphes pour la génération

Transcription

Documents pareils

Exemples de diagrammes SysML sur un portail automatique

1. Diagramme de cas d`utilisation

P50 Maquettage d`un outil pédagogique pour une méthode de

VISIO PERFECTIONNEMENT

Rapport UML Il s`agit de réaliser une conception UML collaborative

TP UML - PolyDocs

Diagrammes UML + outil - Membres du Departement d`Informatique

Télécharger le PDF contenant plus de détails sur cette formation.

Corrigé de l`exercice 2