transformation des diagrammes d'©tats-transitions vers maude
TRANSCRIPT
N° d’ordre : ……………
UNIVERSITE DE M’SILA
FACULTE DES MATHEMATIQUES ET DE
L‘INFORMATIQUE
Département d‘informatique
MEMOIRE
Présenté pour l‘obtention du diplôme de Magistère
Spécialité : Sciences et Technologies de l‘information et de
Communication (STIC)
Option : Systèmes d‘information et de connaissance (SIC)
Par
BOUDIA MALIKA
SUJET
Transformation des diagrammes
d‘états-transitions vers Maude
Soutenu publiquement le 02 /06/2011 devant le jury composé de :
Pr BELOUADAH Hocine Université de M‘sila Président
M.C CHAOUI Allaoua Université de Constantine Rapporteur
M.C BILAMI Azedine Université de Batna Examinateur
M.C BOUREHLA Mustapha Université de M‘sila Examinateur
Promotion : 2006-2007
- 2 -
DEDICACES
الي الذين كتبث من اجلهم هذه الابيات
ب "مذهول به الترا
Je dédie ce modeste travail à mes très chers parents
en témoignage de mon profond respect, mon grand amour et toute ma gratitude pour leurs sacrifices. Aucun mot ne serait exprimer l’ampleur de ma reconnaissance. Aux âmes de mes grands-pères et mes grands-mères … A l’âme de mon frère gémeaux « elarabi-Saleh ». A ma sœur Fatiha« Aïcha » et sa famille … A mes deux oncles dada Abdelkader et dada Abdelhak A mon neveu Hocine qui m’a partagé les moments de la rédaction de cette thèse. A toute ma famille ……. À mes amis, mes collègues et mes stagiaires de l’INSFP M’sila……
خرج ذات الصباح كي يشتري ورقا وجريدة
لن يدري أحد ماذا كان سيكتب
لحظة ذهب به الحبر إلي مثواه الأخير
كان في حوزته رؤوس أقلام
وفي رأسه رصاصة
ولذا ..لم يضعوا وردا علي قبره
من أقلاموضعوا ما اشتري
ولذا لم يكتبوا شيئا علي قبره
تركوا له كثيرا من بياض الرخام
ولذا.. لن تتعرفوا إليه
هناك حيث كل القبور
لا شاهدة لها سوى قلم
وحيث كل مساء
تستيقظ أيد لتواصل الكتابة احلام مستغانمي "
REMERCIMENTS
Je voudrais remercier chaleureusement Mr. Chaoui Allaoua, M.C.
Université de Constantine pour m‟avoir aidé et orienté tout au long la préparation
de cette thèse .Il a été toujours disponible pour éclaircir mes lacunes et discuter mes idées.
Ses critiques, commentaires et conseils ont certainement permis à cette thèse d‟être ce
qu‟elle est.
Je tiens à lui exprimer ma profonde reconnaissance pour sa bienveillance, son soutien,
sa disponibilité.
Je tiens à remercier sincèrement ceux qui ont bien voulu prendre part à ce jury.
Je remercie Mr. Kerkouche Elhilali, enseignant à l’université d’Oum El Bouagui et
Melle Meliouh Amel, enseignante à l’universitéde M’sila pour leur aide précieux
Concernant l‟utilisation de l‟ATOM3 et la documentation.
BOUDIA Malika
- 3 -
Sommaire
Page
REMERCIEMENTS
INTRODUCTION GENERALE 12
CHAPITRE I : UML
I- Introduction
18
II- Le langage UML 20
II-1 Présentation d'UML 22
II-2 Historique d'UML 24
II-3 Les diagrammes d‘UML 62
II-4 Les vues d'UML 66
II-5 Extensions du langage UML 66
II-6 L‘architecture d‘UML 71
III- Le processus de développement 72
IV- Conclusion 78
CHAPITRE II : Statecharts
I- Introduction 80
II- Les diagrammes d‘états transitions 81
II-1 présentation 81
II-2 Les concepts des diagrammes d‘états transition 82
II-2.1 Les états 82
II-2.2 Les transitions 85
II-2.3 Les événements 88
II-2.4 Les concepts avancés 91
II-3 Les limitations des diagrammes d‘états- transition 98
III- Les diagrammes d‘états- transitions et les approches sémantiques 100
IV- Conclusion 114
CHAPITRE III : ATOM3 et Transformation Des MODELES
I- Introduction 116
II- Modélisation et méta modélisation 118
II-1 Définitions 118
II-1.1 Le modèle 118
II-1.2 Le méta-modèle 124
II-1.3 Le langage de modélisation 126
II-1.4 Le méta-méta-modèle 129
- 4 -
II.-2 La méta-modélisation 131
II-2 .1 La définition de méta-modélisation 131
II-2 .2 L‘objectif de méta- modélisation 131
II-2.3 L‘architecture à quatre niveaux de la méta-modélisation
adoptée par l‘OMG 132
III- La transformation des modèles 134
III-1 La définition transformation des modèles 134
III-2 Le principe des transformations de modèles 136
III-3 La structure d‘une règle de transformation 137
III-4 Les types de transformations des modèles 140
IV- ATOM3 149
IV-1 Présentation d‘ATOM3 149
IV-2 L‘architecture d‘ATOM3 150
IV- 3 Les niveaux de méta-modélisation sous ATOM3 152
IV- 4 Les concepts d‘ATOM3 153
V -Travaux connexes 160
VI-Conclusion 167
CHAPITRE IV : La logique de réécriture et Maude
I- Introduction 169
II- La logique de Réécriture 171
II-1 Présentation de la logique de Réécriture 171
II-2 Les théories de la logique de réécriture 172
II-3 Les concepts de base de la logique de réécriture 173
III-Maude 178
III-1 Présentation de Maude 178
III-2 Les caractéristiques de Maude 179
III-3 Les niveaux de programmation de Maude 182
III-4 Les modules de Maude 183
III-5 Les concepts de Maude 189
VI-Travaux connexes 194
V-Conclusion 198
CHAPITRE V : CONTRIBUTION
I. Rappels 200
I-1 UML 200
I-2 Les diagrammes d‘états-transitions 201
I-3 Transformation des modèles 202
I-4 La génération de code 203
I-5 ATOM3 203
I-6 Maude 204
- 5 -
I-7 Modules systèmes 205
II- L‘approche proposée 206
II-1 Présentation de l‘approche 208
II-2 Les étapes de l‘approche 208
II-2.1 Transformation des diagrammes d‘états-transitions
composites (séquentiel/concurrent) vers diagrammes états-
transitions à plat en utilisant l‘algorithme A/B
208
II-2.2 Transformation des diagrammes états- transitions à plat
Vers Maude 212
II-2.2.1 La création d‘un méta-modèle 212
II-2.2.2 La génération d‘un outil de modélisation 213
II-2.2.3 La définition de la grammaire de transformation 215
III- Conclusion 219
CONCLUSION GENERALE 221
BIBLIOGRAPHIE 225
- 6 -
LISTE DES TABLEAUX
TABLEAU N° TITRE Page
1.1 Méthodes formelles Vs Méthodes semi-formelles 22
1.2 Architecture en quatre couches 70
2.1 Type de transition et effets implicites 87
2.2 Types d‘événements [Rumbaugh, 2005 90
2.3 Types d‘états [Rumbaugh ,2005 96
3.1 Critères de classification des approches de transformations de
modèles
144
3.2 Les niveaux de méta-modélisation (Meta-Modelling Levels) 153
4.1 Quelques sortes du modules orienté objet. 187
4.2 Les concepts du language Maude 189
- 7 -
LISTE DES FIGURES
FIGURE N° TITRE Page
1.1 L‘histoire d‘UML 24
1.2 Les diagrammes UML utilisés 26
1.3 Exemple de diagramme de classes 29
1.4 exemple de diagramme d‘objet 31
1.5 Composant avec interface 33
1.6 Exemple de diagramme de composants 34
1.7 Exemple de diagramme de déploiement 36
1.8 Exemple de diagramme de package. 37
1.9
Exemple de diagramme de structure composite suggéré par Jim
Rumbaugh 39
1.10 Exemple d‘un diagramme de cas d‘utilisation. 44
1.11 Exemple de diagrammes d‘activités 48
1.12 Exemple de diagrammes d‘activités pour un projet de système
de management 49
1.13 Exemple de diagrammes d‘états- transitions 51
1.14 Les concepts diagrammes de séquence 54
1.15 Exemple de diagramme de communication 58
1.16 Exemple d'un diagramme global d‘interaction 59
1.17 deux manières pour tracer les diagrammes de temps. 60
1.18 les "4+1"vues de l'architecture 62
1.19 Exemple de Stéréotypes 67
1.20 Exemple de hiérarchie de méta modélisation en 4 couches 71
1.21 Activités et intensité de production en fonction de l‘avancement
du projet 75
1.22 Le processus de développement en Y de la méthode 2TUP 77
2.1 Diagramme d‘états transition 81
2.2 Protocole d‘états machine 83
- 8 -
2.3 Formalisme de représentation des états initial et final Figure 84
2.4 Les éléments de statechart diagram (diagramme d‘états –
transitions point de choix 91
2.5 Exemple d‘état-transition avec point de choix 97
2.6 Exemple d‘état-transition avec point de jonction 97
2.7 Catégorisation des approches sémantiques du diagramme
d'états-transition 100
2.8 Les principaux modèles de Petri Nets Figure 105
2.9 Schéma général du principe du model-checking 110
3.1 Les composants d‘un langage 127
3.2 Langage de modélisation 128
3.3 illustration des concepts modèle, méta-modèle et méta-méta-
modèle 130
3.4 L‘architecture à quatre niveaux de la méta-modélisation
adoptée par l‘OMG 133
3.5 Concepts de base de la transformation de modèles 135
3.6 La transformation de modèles 136
3.7 Types de transformation et leurs principales utilisations 142
3.8 Modèles et transformations dans l‘approche MDA 144
3.9 Approches de transformations de modèles (modèle vers modèle /
modèle vers code) 145
3.10 l‘interface d‘ATOM3 150
3.11
Travail propose un schéma de méta-modélisation de
l‘environnement ATOM3 (Proposed working scheme for a meta-
modelling environment)
151
3.12 L‘architecture d‘atom3 152
3.13 Boite de dialogue de l‘édition des entités 154
3.14 De l‘édition des relations sous ATOM3 154
3.15 Boite de dialogue de l‘édition des attributs d‘ATOM3 155
3.16 La structure d‘une contrainte 156
- 9 -
3.17 La structure d‘une action 157
3.18
Un méta-modèle commun pour modéliser le modèle d‘UML et
le modèle de base de données relationnelle (Common Uml and
Rdbms Meta-model)
160
3.19 Boite de dialogue utilisée pour éditer la transformation
'UML2Rdbms. 161
3.20 L‘architecture de la transformation 162
3.21 La présentation de la règle 22 162
3.22 Un méta-modèle pour les CBDs, exprimés en formalisme E/R
(Meta-model of CBDs, expressed in the ER formalism) 164
4.1 Visualisation des règles d‘inférence d‘une théorie de réécriture 177
4.2 Parallèle entre un programme informatique, une théorie de
réécriture et la logique mathématique 181
4.3 Un Petri Net 183
4.4 Le module système VENDING-MACHINE 184
4.5 Le module fonctionnel BOOL-OPS 186
4.6 Le module orienté-objet ACCOUNT 188
4.7 la méthodologie de l‘approche 194
4.8 Un exemple de diagramme d‘UML et leur correspondance en
MAUDE. 195
5.1 Et transformations dans l‘approche MDA 202
5.2 Schéma descriptive de l‘approche proposée 207
5.3
Conversion de diagramme d‘états –transitions séquentiel
composite vers un diagramme d‘états –transitions plat (Conversion
of a sequential composite state (X) to flat).
208
5.4
Conversion de diagramme d‘états –transitions concurrent
composite vers un diagramme d‘états –transitions plat (Conversion
of a concurrent composite state (X) to flat)
210
5.5 Le méta-modèle des diagrammes –d‘états-transitions à plat 213
5.6 L‘outil de modélisation généré par ATO M3 pour les
diagrammes d‘états –transition à plat 214
- 10 -
5.7 L‘éditeur de la grammaire de transformation
215
5.8 la grammaire nommé Statecharts2Maude
216
5.9
la description de deux règles (règle1, règle6) grammaire nommé
Statecharts2Maude
217
5.10 exemple de l‘exécution de la grammaire nommé
Statecharts2Maude. 218
- 11 -
INTRODUCTION
GENERALE
- 12 -
INTRODUCTION GENERALE
Aujourd‟hui, les systèmes développés sont devenus de plus en plus complexes. Le
paradigme de programmation orienté-objet a approuvé de nombreuses avancées et s‟implante
comme le standard de l‟industrie pour le développement logiciel. L‟autre standard de l‟industrie,
UML (Unified Modelling Language), est un langage visuel (graphique) spécialement développé
pour modéliser proprement un système orienté-objet (OO). Les diverses vues offertes par UML
permettent de visualiser plusieurs aspects d‟un même système. Ceci permet de mieux gérer la
complexité du système.
Cependant, UML étant un langage à caractère plutôt visuel, il souffre d‟un manque de
Sémantique formelle. En effet, les notations semi-formelles et visuelles d‟UML peuvent
provoquer des inconsistances au niveau des modèles développés.
UML propose un ensemble de notations graphiques standardisées regroupées en treize
types de diagrammes complémentaires.
Un diagramme donne à l'utilisateur un moyen de visualiser et de manipuler des éléments
de modélisation. UML définit des diagrammes structurels et comportementaux pour représenter
respectivement des vues statiques et dynamiques d'un système [Muller, 2001]. Les diagrammes
incluent des éléments graphiques qui décrivent le contenu des vues [Erikson, 2004].
Le diagramme d‟états-transitions est le seul diagramme, de la norme UML, à offrir
une vision complète de l‟ensemble des comportements de l‟élément auquel il est attaché
(généralement une classe active)…
Les diagrammes d‟états-transitions (statecharts diagram), concept utilisé par David Harel
pour son extension de notation de machine d‟état à plat comprend des états imbriqués et
concurrents. Cette notation a servi de base à la notation de la machine UML.
Les diagrammes d‟états transition UML représentent en réalité des automates à états
finis, mathématiquement parlant, ils représentent des graphes orientés.
La notation des Statecharts d'UML n'est pas purement visuelle. N'importe quelle machine
d'état non triviale exige un grand nombre d'information textuelle (par exemple, les spécifications
des actions et des gardes).
- 13 -
La syntaxe exacte des expressions d'action et de garde n'est pas définie dans les
spécifications d'UML, ainsi beaucoup de personnes emploient l'anglais structuré ou, plus
formellement, des expressions en langue d'exécution telle que C, C++, ou Java. Dans la pratique,
ceci signifie que la notation de statechart d'UML dépend largement du langage de programmation
spécifique.
Néanmoins, la majeure partie de la sémantique de statecharts est fortement concentrée
vers la notation graphique. Par exemple, les diagrammes d'états-transitions représentent
incorrectement l'ordre du traitement, que ce soit l'ordre de l'évaluation des gardes ou l'ordre
d'expédition des événements aux régions orthogonales. Ou le l‟ordre d‟exécution des transitions
Même, les diagrammes de statecharts exigent beaucoup de vitesse (les pseudos-states, comme
point de choix, point de jonction, etc.) pour représenter l'ordre d'exécution graphiquement. En
plus la caractéristique visuelle engendre des statecharts ambigües et non précises.
Afin d‟améliorer les statecharts, la notation et la sémantique d'UML sont vraiment
adaptées vers la conception automatisée.
La technologie MDA (Model Driven Architecture) est un standard issu de l‟OMG qui
permet d‟exploiter et de transformer les modèles UML. Ceci permet notamment de :
- Produire d‟autres modèles (d‟analyse vers conception, par exemple),
- Produire automatiquement des documentations issues du modèle,
- Générer automatiquement du code à partir du modèle.
Une fonctionnalité essentielle de la MDA est la notion de transformation. Une
transformation regroupe un ensemble de règles et de techniques pour transformer un modèle vers
un autre.
La transformation des modèles est définie comme étant le processus de conversion d‟un
modèle d‟un système vers un autre modèle [Czarnecki, 2006].
Plusieurs outils de modélisation ont été proposés pour effectuer la transformation des
modèles soit transformation modèle vers modèle ou modèle vers code (génération du code), par
exemple AGG, AToM3, VIATRA2, et VMTS.
ATOM3 supporte la méta-modélisation et les transformations des modèles en se basant
sur une grammaire de transformation. Cet outil crée le méta-modèle et édite leur apparence
visuel, puis il génère l‟outil de modélisation et il permet également de spécifier les règles de
- 14 -
transformation(Une règle de transformation : est une description de comment un concept ou
plus dans un langage source peut être transformé en un concept ou plus d‟un langage cible).
En plus ATOM3 assume plusieurs types de transformation : La transformation endogène,
la transformation exogène, la transformation PIM vers PIM, la transformation PIM vers PSM,
la transformation PIM vers PSM, les transformations inverses PIM vers PSM et PSM vers
code ……..
La transformation explorée est la transformation PSM vers code (La transformation de
PSM vers l‟implémentation (le code)) est une transformation de type modèle à texte [Czarnecki
,2006]. Le code est parfois assimilé par certains à un PSM exécutable. Dans la pratique, il n‟est
généralement pas possible d‟obtenir la totalité du code à partir du modèle et il est alors nécessaire
de le compléter manuellement.
Le language Maude est adopté comme code de destination, ce choix est argumenté par la
simplicité, l‟expressivité et la performance du Maude.
Plusieurs propriétés désignent le language Maude [Clavel, 1996a] : Maude est basé sur la
logique de réécriture, Maude est multi paradigme (Multiparadigm), Maude est réflectif, Maude
est caractérisé par un spectre large (wide –Spectrum), Maude est un méta langage, Maude est
qualifié par les stratégies internes (internal strategies), Maude est aussi utilisé pour : la
spécification, le prototypage, la vérification d‟une large gamme d‟applications. Maude est doté
d‟un ensemble d‟outils permettant de faciliter la fonction de la vérification.
- 15 -
L'approche que nous proposons, vise à transformer les diagrammes d‟états-transitions
vers Maude. Cette approche englobe en réalité deux transformations : la première translate les
diagrammes d‟états-transitions composites (concurrents/séquentiels) vers les diagrammes d‟états
transition à plat en appliquant les algorithmes de Saldhana, [Saldhana, 2001].
La deuxième transforme les diagrammes d‟états-transition à plat vers Maude, en utilisant
l‟outil ATOM3.ATOM3 assure les deux tâches : la méta-modélisation et la transformation de
modèles. La méta-modélisation est la description ou la modélisation de différents types de
formalismes. La transformation de modèles est une technique consistant à transformer, traduire
ou modéliser automatiquement un modèle décrit dans un certain formalisme, vers un autre
modèle qui peut être décrit soit dans le même formalisme soit dans un autre. Il permet aussi de
définir la syntaxe abstraite et concrète des langages visuels [Taentzer, 2005].
Dans cette approche, ATOM3 est utilisé pour créer un méta-modèle pour les statecharts,
éditer les apparences visuels des constituants du méta-modèle (les classes et les associations),
générer automatiquement l‟outil de modélisation des statecharts, spécifier les règles de la
grammaire de transformation puis exécuter la grammaire qui génère le code Maude.
- 16 -
Plan de travail
Ce mémoire est divisé en cinq chapitres :
- Le chapitre I : présente le language UML, éclaircit l‟historique d‟UML, décrit les
diagrammes d‟UML et leurs concepts, illustre les vues d‟UML, développe les
extensions du language UML, expose l‟architecture d‟UML et examine le
processus de développement.
- Le chapitre II : décrit les diagrammes d'états-transitions, leurs concepts de base et
leurs concepts avancés. Les statecharts sont restreintes par certaines limitations. Les
statecharts sont poursuites par les approches sémantiques, parce qu'il spécifie le
comportement interne des objets d'un système.
- Le chapitre III : apporte les définitions de modèle, méta- modèle, langage de
modélisation et méta-méta-modèle, clarifie la méta-modélisation et son objectif et
commente l‟architecture à quatre niveaux de la méta-modélisation adoptée par
l‟OMG, introduit la définition de la transformation de modèles, discute le principe
de transformation, spécifie la structure d‟une règle de transformation et récapitule
la taxonomie des transformations. Ce chapitre comporte un tutoriel sur l‟ATOM3 et
résume les travaux connexes à la transformation du modèle.
- Le chapitre IV : présente la logique de réécriture, ces théories ainsi que les concepts
liées à la logique de réécriture .ce chapitre expose également le langage Maude,
clarifie ces caractéristiques, décrit ces niveaux de programmation, spécifie les
modules de Maude et étudie les concepts de Maude. Ce chapitre
Synthétise les travaux connexes liés à la transformation de type modèle vers le code
Maude (génération de code).
- Le chapitre V : propose une approche de transformation de diagrammes d‟états
transitions vers Maude en exploitant l‟outil de méta-modélisation ATOM3.
- 17 -
CHAPITRE I
UML
I- Introduction
II- Le langage UML
III- Le processus de développement
IV- Conclusion
- 18 -
I. Introduction
UML (Unified Modelling Language) est un langage de modélisation et de spécification
objet principalement utilisé dans le domaine informatique. (II.1) :C'est un langage relevant des
formalismes objets et qui permet de spécifier, de visualiser, de construire et de documenter
les concepts d'un système [OMG, 2003a] [OMG, 2002].
UML (II.2), le langage unifié de la modélisation s'est dégagé pour devenir le standard de
modélisation objet. En effet, UML n‟est pas une méthode mais plutôt une notation qui fusionne
les notations d‟OOD, OMT et d‟OOSE.UML a été standardisée par l'Object Management Group
(OMG). La version 2.0 a été l'occasion d'une refonte majeure du langage UML dont les
spécifications ont été mises en accord avec celles du Meta Object Facility(MOF) méta-méta-
modèle du langage UML. Pour ce faire, les membres de l'OMG ont extrait les concepts
identiques du langage UML et du MOF et les ont mutualisés au sein d'une nouvelle architecture
dénommée UML 2.0 Infrastructure. Cette nouvelle organisation a permis d'alléger les
spécifications d'UML 2.0 et celles du MOF 2.0. Les nouvelles spécifications d'UML sont décrites
dans le document intitulé UML 2.0 Superstructure. L'infrastructure d'UML 2.0 a été adoptée en
septembre 2003 et la superstructure en octobre 2003.
UML propose un ensemble de notations graphiques standardisées regroupées en treize
types de diagrammes(II.3), dont 4 nouveaux diagrammes introduits par UML2.Les différents
diagrammes sont complémentaires, car chacun s‟intéresse à un aspect précis de la représentation.
La combinaison des différents types de diagrammes UML offre une vue complète du domaine
modélisé.
UML se décompose en plusieurs sous-ensembles. Les vues (II.4) présentent les différents
aspects d'un système. Une vue n'est pas un élément graphique ou un diagramme, mais une
abstraction qui englobe un nombre de diagrammes afin de décrire le système d'un point de vue
donné.
UML est extensible d'une manière normalisée et commandée. Les extensions du langage
UML(II.5) sont : les stéréotypes qui permettent de modifier la signification d‟une notion et
- 19 -
d‟accroître ainsi l‟expressivité du langage, OCL - Object Constraint Language- qui d‟une part
dote UML d‟une sémantique formelle proche de la logique classique et d‟autre part permet
d‟exprimer des contraintes dites d‟invariance sur les connaissances modélisées. Tagged value est
une paire (nom, valeur) ajoutant une nouvelle propriété à un élément d‟‟échange de
connaissances modélisées dans le modèle UML.
La caractéristique essentielle qui distingue la notation UML des autres notations consiste
en sa base formelle appelée méta-modèle. Le méta-modèle est défini à l‟aide de quatre couches
d‟architecture de méta-modélisation UML (II.6). Cette architecture est une infrastructure
prouvée pour définir la sémantique précise requise par des modèles complexes. Le langage UML
s‟inscrit dans une architecture à quatre couches ou niveaux de méta-modélisation qui sont :
Méta-méta-modèle (M3), Méta-modèle(M2), Modèle(M1), Objets utilisateur (M0).
UML est un langage de modélisation, pas un processus. Le processus définit qui fait
quoi à quel moment et de quelle façon atteindre un certain objectif. Le processus unifié est un
processus de développement logiciel (III) fondé sur le langage UML, itératif, centré sur
l‟architecture, piloté par les cas d‟utilisation et Orienté vers la réduction des risques.
- 20 -
II. Le Langage UML
II.1 Présentation d'UML
L‟UML (Unified Modeling Language), ou langage de modélisation unifié, se définit
comme un langage de modélisation graphique et textuel destiné à comprendre et à décrire des
besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir
des solutions et communiquer des points de vues [Muller, 2001].
UML unifie à la fois les notations et les concepts orientés objets. Il ne s'agit pas d'une
simple notation, les concepts retransmis par diagramme ont une sémantique précise et sont
porteurs de sens au même titre que les mots d'un langage. UML réunie également les notations
nécessaires aux différentes activités d'un processus de développement et offre, par ce biais, le
moyen d'établir le suivi des décisions prises, depuis la spécification jusqu'au codage. [Roques,
2007b].
UML a une dimension symbolique et ouvre une nouvelle voie d'échange de visions
systématiques précises.
UML se compose de vues, de modèles d‟éléments, de mécanismes généraux et de
diagrammes.
En résumé, UML est une langue de modélisation orientée objet, normalisée, et destinée
principalement (mais pas exclusivement) à modéliser les systèmes logiciels. En soi, il a beaucoup
d'avantages importants.
Les sections suivantes décrivent brièvement les caractéristiques d'UML [Milicev, 2009].
- UML est normalisé et largement accepté aujourd'hui. C'est un langage commun pour
développer et échanger des modèles de logiciel. La plupart des chercheurs et praticiens
l'emploient pour décrire leurs idées et conceptions.
- UML est conceptuellement riche. Beaucoup de concepts intéressants ont été incorporés à
UML en raison des besoins pratiques. C'est pourquoi UML peut être employé pour des
- 21 -
domaines d‟applications très différents. UML est un langage d'usage universel pour la
modélisation systèmes dépendants du logiciel.
- UML est orienté objet. Il soutient tous les concepts fondamentaux du paradigme d'objet. Il
évite également la plupart des inconvénients du niveau de programmation d'OO. Il
dispose en plus d‟une notation schématique qui rend possible la visualisation des modèles.
- UML est extensible d'une manière normalisée et commandée. Il est possible d'adapter le
langage pour chaque domaine d‟application particulier ou problème concret. C'est un
aspect important d'UML qui élargit sa portée et le rend valable plus longtemps.
Cependant, malgré ses nombreux avantages, UML a dans son état actuel, plusieurs
inconvénients majeurs :
- UML est très complexe et hétérogène. C'est le résultat de contributions dans différents
domaines.
- Une grande partie (pour être plus précis, la majeure partie) d‟UML n'a pas encore de
sémantique précise.
- Quelques parties d'UML ne sont pas prévues pour la modélisation précise et formelle. En
effet, UML est visé à toutes les phases du développement de logiciel, dont les premières
phases de modélisation des conditions, lorsque les analystes n‟ont encore que des idées
vagues et inachevées au sujet du système qu‟ils construisent.
UML laisse ainsi se former des modèles inachevés, contradictoires, et sans
représentation dans les premières phases de création, qui devront être raffinées par la suite. De
telles parties d'UML pourraient (et devraient) ne pas avoir de sémantique formelle.
- Certaines régions d'UM sont trop imprécises par leur nature, et il est alors très probable
qu'ils ne puissent jamais avoir de sémantique formelle. Ils ont souvent inachevé
contradictoire, ambigu, dérivé, ou vides de sens. La rentabilité de telles parties et leur
survie dans UML est fortement incertaine.
- La sémantique de quelques parties d'UML n‟est pas encore définie, soit en raison du
manque de maturité ou d‟une incompréhension complète de leur objectif, soit parce que
les concepteurs souhaitent pouvoir les personnaliser et spécifier des domaines propres ou
spécifier des cartographies d‟implémentation de langage.
- 22 -
UML, comporte beaucoup d‟imprécisions et de choix laissés à l‟utilisateur (ce qui en Fait
un langage semi-formel et non formel .Le tableau 1.1 compare entres les deux méthodes
semi-formelles et les méthodes formelles.
Tableau 1.1 Méthodes formelles Vs Méthodes semi-formelles [Idani, 2006]
II.2 Historique d'UML [Miralles, 2006]
Le langage UML est né de la mise en commun des trois plus importantes méthodes de
modélisation orientées objet du début des années 90 (au sein d'un même langage) [OMG, 1999]:
- La méthode Booch dont l'auteur, Grady Booch, travaillait au développement de systèmes
en Ada chez Rational Software Corporation.
- La méthode Object Modeling Technique (OMT) développée par Jim Rumbaugh qui
dirigeait une équipe de recherche chez General Electric.
- La méthode Object-Oriented Software Engineering (OOSE) résultant des travaux d'Ivar
Jacobson sur les commutateurs téléphoniques chez son employeur Ericsson. La méthode
OOSE était la première à introduire le concept des cas d'utilisation (use case).
- 23 -
Le langage UML a bénéficié de bien d'autres travaux comme ceux de Sally Shlaer et
Steve Mellor sur l'analyse et la conception de systèmes, ou ceux de Jim Odell et James Martin en
génie logiciel, mais aussi des nombreux acquis de la communauté Smalltalk. La fusion de ces
trois méthodes a été réalisée très rapidement dans les années 94-96 lorsque Jim Rumbaugh
rejoignit Grady Booch chez Rational Software Corporation en 1994. En 1995, cette dernière
acquit la société Objectory AB d'Ivar Jacobson.
Tous trois, souvent surnommés Les trois amigos, rédigèrent la version 0.9 d'UML qui fut
publiée à OOPSALA 96 en juin 1996, texte qui sera soumis à l'OMG en janvier 1997 sous le titre
de version 1.0. Cette version sera amendée par des propositions émanant des membres de l'OMG
et donnera lieu à la version 1.1 soumise en septembre 1997 et adoptée en novembre de la même
année. En juin 1998, la version 1.2 apportera des modifications mineures au langage UML alors
que la version 1.3 fera l'objet de modifications plus conséquentes comme l'intégration du langage
de contraintes Object Constraint Language(OCL), ou la génération d'interfaces via le langage
Interface Definition Language(IDL). Cette dernière sera soumise en juin 1999 et adoptée en mars
2000. La version 1.4, adoptée en septembre 2001, introduira des concepts et des spécifications
détaillées sur les notions de composants et de profils. Adoptée en mars 2003, la version 1.5
ajoutera la sémantique des actions.
La version 2.0 a été l'occasion d'une refonte majeure du langage UML dont les
spécifications ont été mises en accord avec celles du Meta Object Facility(MOF), méta-méta-
modèle du langage UML. Pour ce faire, les membres de l'OMG ont extrait les concepts
identiques du langage UML et du MOF et les ont mutualisés au sein d'une nouvelle architecture
dénommée UML 2.0 Infrastructure. Cette nouvelle organisation a permis d'alléger les
spécifications d'UML 2.0 et celles du MOF 2.0. Les nouvelles spécifications d'UML sont décrites
dans le document intitulé UML 2.0 Superstructure. L'infrastructure d'UML 2.0 a été adoptée en
septembre 2003 et la superstructure en octobre 2003. La version UML 2.0 est l'aboutissement
d'une collaboration intensive de 3 ans entre les membres de l'OMG.
Entre les versions 1.0 et 2.0, sept ans se sont écoulés et sept versions ont été adoptées par
les membres de l'OMG ce qui correspond en moyenne à une version par an. Ceci montre l'intérêt
et le dynamisme de cette communauté. La figure 1 .1 expose l‟histoire d‟UML.
- 24 -
Figure 1.1 : L‘histoire d‘UML [Epi, 2009]
II.3Diagrammes UML :
Un diagramme donne à l'utilisateur un moyen de visualiser et de manipuler des éléments
de modélisation. UML définit des diagrammes structurels et comportementaux pour représenter
respectivement des vues statiques et dynamiques d'un système [Muller, 2001]. Les diagrammes
incluent des éléments graphiques qui décrivent le contenu des vues [Erikson, 2004].
UML s‟articule maintenant autour de 13 diagrammes différents dont 4 nouveaux
diagrammes introduits par UML2, chacun d‟eux est dédié à la représentation d‟un système
logiciel suivant un point de vue particulier [Roques, 2007b] [Barbier, 2005].
UML modélise le système suivant deux modes de représentation :
- L‟un concerne la structure du système pris « au repos ».
- L‟autre concerne sa dynamique de fonctionnement.
- 25 -
Le mode de représentation statique ou structurel s‟appuie sur les 6 diagrammes ci-après :
[Roques, 2007b].
Six diagrammes structurels ou diagrammes statiques (UML structure):
- Diagramme de classes (Class diagram).
- Diagramme d‟objets (Object diagram).
- Diagramme de composants (Component diagram).
- Diagramme de déploiement (Deployment diagram).
- Diagramme de paquetages (packages) (Package diagram).
- Diagramme de structures composites (Composite structure diagram).
Le mode de représentation dynamique ou comportemental s‟appuie sur les 7 diagrammes
ci-après, dont 2 nouveaux diagrammes introduits par UML 2 :
Diagrammes comportementaux : ou diagrammes dynamiques (UML Behavior)
- Diagramme de cas d‟utilisation (Use case diagram).
- Diagramme d‟activités (Activity diagram).
- Diagramme d‟états -transition (State machine diagram).
Diagrammes d‟interactions (Interaction diagram).
- Diagramme de séquence (Sequence diagram).
- Diagramme de communication (Communication diagram).
- Diagramme global d‟interaction (Interaction overview diagram).
- Diagramme de temps (Timing diagram).
La Figure 1.2 extraite de [Roques, 2007b] développe Les diagrammes UML 2.
- 26 -
Figure 1.2 : Les diagrammes UML utilisés [Roques, 2007b]
Les diagrammes de classe :
a) Définition :
Un diagramme de classe [Rumbaugh, 2005] est une représentation graphique de la vue
statique qui montre une collection d‟éléments déclaratifs (statiques) du modèle comme les
classes, les types, et leurs contenus et relations. Il représente une vue de package et peut
contenir des symboles pour les packages imbriqués.
Selon Martin Fowler [Fowler,2005], un diagramme de classe décrit les types des objets
qui composent un système et les différents types de relations statiques qui existent entre eux.
Les diagrammes de classe représentent également les propriétés et les opérations
des classes, ainsi que les contraintes et la façon dont les objets sont connectés.
- 27 -
Les classes sont des descripteurs d‟un ensemble d‟objets qui ont une structure, un
comportement et des relations similaires. Les classes sont représentées par des rectangles
compartimentés. Les classes sont reliés l‟une à l‟autre via plusieurs formes : les associations (
une classe associe une autre classe ), la dépendance ( une classe dépend d‟une autre classe ) ,
la spécialisation ( une classe est une spécialisation d‟une autre classe ) L‟origine du diagramme
de classes provient principalement d‟OMT Rumbaurgh(Object Modeling Technique - James
Rumbaugh) et d‟OOD Booch OOD (Object Oriented Design – Grady Booch).
b) Les concepts de diagrammes de classes:
Le diagramme de classe comporte les concepts [Roques, 2005] :
Classe et objet : une classe représente la description abstraite d‟un ensemble d‟objets
possédant les mêmes caractéristiques. On peut aussi parler de type.
Un objet est une entité aux frontières bien définies, possédant une identité et
encapsulant un état et un comportement. C‟est une instance (ou une occurrence) d‟une
classe.
Attribut et opération : un attribut représente un type d‟information contenu dans une
classe. Une opération représente un élément de comportement (un service) contenu
dans une classe. Nous ajouterons plutôt les opérations en conception objet.
Car cela fait partie des choix d‟attributs des responsabilités aux objets.
Association : une association représente une relation sémantique durable entre deux
classes. Une association entre concepts dans un modèle du domaine est par défaut
bidirectionnelle.
Agrégation et composition : une agrégation est un cas particulier d‟association non
symétrique exprimant une relation de contenance. Les agrégations n‟ont pas besoin
d‟être nommés : implicitement elles signifient « contient » ou « est composé de ». Une
composition est une agrégation plus forte impliquant que :
- Un élément ne peut appartenir qu‟à un seul agrégat composite (agrégation non
partagé)
- 28 -
- La destruction de l‟agrégat composite entraine la destruction de tous ses éléments
(le composite est responsable du cycle de vie des parties).
Généralisation, superclasse, sous classe : Une superclasse est une classe plus générale
reliée à une ou plusieurs autres classes plus spécialisées (sous classe) par une relation de
généralisation. Les sous classes « héritent » des propriétés de leur superclasse et peuvent
comporter des propriétés spécifiques supplémentaires.
Package : c‟est un mécanisme général de regroupement d‟éléments en UML , qui est
principalement utilisé en analyse et en conception d‟objet pour regrouper des classes
et des associations . Les packages sont des espaces de noms : deux éléments ne peuvent
pas porter le même nom au sein de même package. Par contre deux éléments
appartenant à des packages différents peuvent porter le même nom.
La structuration d‟un modèle en packages est une activité délicate. Elle doit s‟appuyer
sur deux principes : cohérence et indépendance.
Cohérence : consiste à regrouper les classes qui sont proches d‟un point de vue
sémantique. Un critère intéressant consiste à évaluer les durées de vie des instances de
concepts et à rechercher l‟homogénéité.
Indépendance : s‟efforce de minimiser les relations entre packages c‟est-à-dire plus
concrètement les relations entre classe de packages différents.
La Figure 1.3 extraite de [Meyer, 2001] décrit un exemple de diagramme de classes en
introduisant ces concepts.
c) Intérêts des diagrammes de classes :
Dans UML, les diagrammes de classes constituent la vue logique (car normalement
indépendante du langage de programmation cible du système).
Les intérêts des diagrammes de classes sont multiples:
- Rassembler les données utilisées par le système dans des entités encapsulées : les
classes (collections d‟objets d‟attribut communs).
- Définir les opérations qui permettent de manipuler ces données, celles-ci seront
intégrées aux classes.
- 29 -
- De réaliser une vision des éléments statiques du système , c‟est-à-dire de recenser
les parties des structures qui ne se modifieront pas avec le temps .
- Mettre en œuvre les concepts objets (en particulier l‟héritage qui permet la
réutilisation du code).
Figure 1.3 : Exemple de diagramme de classes [Meyer, 2001]
Les diagrammes d‘objets :
a) définition : un diagramme d‟objet est un instantané des objets d‟un système à un moment
donné. Comme ils représentent des instances et non des classes, on les nomme souvent
« diagrammes d‟instances ». [Fowler, 2005]
Pour James Rumbaugh, Ivar Jacobson et Grady Booch, un diagramme d‟objets présente une
configuration d‟objets. Un objet est une instance d‟une classe. Il est modélisé comme une
- 30 -
spécification d‟instance qui peut représenter un seul objet ou un jeu d‟objets satisfaisant à des
conditions données [Rumbaugh, 2005].
Les diagrammes d‟objets, ou diagrammes d‟instances, montrent des objets et des liens. Comme
les diagrammes de classes, les diagrammes d‟objets représentent la structure statique. Un
diagramme d‟objets représente l‟image d‟un système à un instant donné .Pour cette raison, il
est souvent appelé „‟snapshot‟‟ [Troung ,2001].La Figure 1.4 extraite de [Ambler, 2005] présente
un exemple de diagramme d‟objet
b) Les concepts de diagramme d‘objet :
Les diagrammes d‟objets usent les concepts suivants [Muller, 2001] :
Objet : un objet est une instance d‟une classe qui décrit le jeu possible des objets qui
peuvent exister. On peut percevoir un objet sous deux perspectives liées : comme une entité
à un moment précis dans le temps doté d‟une valeur spécifique, et comme un détenteur
d‟identité avec plusieurs valeurs dans le temps. Ces deux vues peuvent cohabiter dans un
modèle mais pas dans le même objet ou la même classe.
Un objet possède alors des valeurs pour chacun de ses attributs. Un objet en général est
associé à une collection de liens qui le relie à d‟autres objets.
Chaque objet possède une identité unique. On peut le référencer grâce à un identificateur
qui l‟identifie et permet d‟y accéder.
Liaison ou « association» : les objets sont reliés par des liens instances (des associations)
entre les classes des objets considérés. La représentation concrète d‟une structure au moyen
d‟objets est souvent plus parlante que celle abstraite par des classes. Surtout dans le cas de
structures récursives. Toutefois, les liens entre objets représentent les connexions entre les
instances des classes à un instant donné seulement.
c) Les intérêts des diagrammes d‘objets :
- Les diagrammes d‟objets sont utiles pour représenter les exemples d‟objets connectés
entre eux. Dans de nombreux cas, on peut définir précisément une structure avec un
- 31 -
diagramme de classe. mais cette structure demeure trop difficile à comprendre. Dans ce
cas, les diagrammes d‟objets font toute la différence.
- Les diagrammes d‟objets sont utiles principalement pour montrer un contexte. par
exemple avant ou après une interaction. mais également pour faciliter la
compréhension des structures de données complexes.
- Les diagrammes d‟objets sont utilisés pour illustrer les structures de données
complexes ou pour monter le comportement par une séquence de snapshots durant
l‟exécution des systèmes.
Figure 1.4 : exemple de diagramme d‘objet [Ambler, 2005]
Les diagrammes de composants :
a) définition des diagrammes de composants :
Les diagrammes de composants sont des graphes de composants connectés par des
relations de dépendance. Les composants sont des composants logiciels. On distingue les
composants de code source, de code binaire et les composants exécutables. Un module logiciel
peut être représenté comme un type de composant. Certains composants existent lors de la
compilation, à l‟édition des liens et d‟autres lors de l‟exécution.
- 32 -
Les diagrammes de composants décrivent les composants et leurs dépendances dans
l‟environnement de réalisation. Les diagrammes de composants sont des vues statiques de
l‟implémentation des systèmes qui montrent des choix de réalisation [Muller, 2001].
Un diagramme de composants montre le réseau de dépendance entre les composants. La
vue des composants prend alors deux formes.
Elle peut monter un jeu de composants disponibles ( une bibliothèque de composants )
avec leurs dépendances ; c‟est ce qui permet d‟assembler un système . Elle peut également
montrer un système configuré, avec la sélection des composants (extraits de la bibliothèque)
utilisés pour la construire sous cette forme. Chaque composant est câblé aux autres composants
dont il utilise les services : ces connexions doivent être en accord avec les interfaces des
composants [Rumbaugh, 2005].
Pour résumer , un diagramme de composants[Rumbaugh,2005] montre les composants
d‟un système, c‟est à dire les unités logicielles à partir desquelles on a construit l‟application,
ainsi que les dépendances entre les composants qui permettent de traiter l‟impact de changement
donné.
Le diagramme de composants résulte des modules de Booch et des diagrammes de
processus.
b) Les concepts des diagrammes de composants
Les diagrammes de composants utilisent les concepts suivants [Muller ,2001] :
Un composant : c‟est un élément physique qui représente une partie implémentée d‟un
système. Un composant peut être un code ( source binaire ou exécutable ) , un script , un
fichier de commandes , un fichier de données , etc.…..
Un composant est représenté par un rectangle principal avec sur son côté gauche deux
rectangles plus petits. Le nom du composant est placé dans le rectangle principal.
- 33 -
Un composant est défini comme une sous ensemble de classificateurs. Il peut ainsi
avoir des attributs : des opérations particulières et des relations (association, généralisation,
dépendance). Les instances des composants représentent des unités implémentées qui
possèdent une identité et résident dans des instances de nœuds. Elles sont représentées comme
des composants, par un nom souligné qui respecte la syntaxe suivante : nom_de_l_instance ;
nom_du_composant.
Les composants d‟un composant plus global sont représentés dans le symbole de ce
dernier. La Figure 1.5 extraite de [Rumbaugh, 1998] montre composant avec interface
Figure 1.5 : composant avec interface [Rumbaugh, 1998]
Les modules : ils représentent toutes sortes d‟éléments physiques qui entrent dans la
fabrication des applications informatiques, les modules peuvent être de simples fichiers ou
encore des bibliothèques chargés dynamiquement.
Les dépendances entre composants :Les relations de dépendance sont utilisées dans les
diagrammes de composants pour indiquer qu‟un composant fait appel aux services offerts
par les éléments d‟implémentation d‟un autre composant. Ce type de dépendance est le
reflet des choix de réalisation.
Une telle relation de dépendance est représentée par une flèche pointillé orientée du
composant vers le composant fournisseur .
c) Intérêts des diagrammes de composants :
- Spécifier l‟architecture logicielle du projet.
- 34 -
- Définir les choix des composants pour le développer.
- Les diagrammes de composants décrivent les composants et leurs dépendances dans
l‟environnement de réalisation. Les diagrammes de composants sont des vues statiques
de l‟implémentation des systèmes qui montrent des choix de réalisation . La figure1.6
extraite de [Charroux ,2008] illustre un exemple de diagramme de composants.
Figure 1.6 : exemple de diagramme de composants [Charroux ,2008]
Les diagrammes de déploiement :
a) définition des diagrammes de déploiement :
Un diagramme de déploiement est un graphe composé de nœuds interconnectés par des
liens de communication. Le diagramme de déploiement montre la disposition physique des
différents matériels , « les nœuds », qui entrent dans la composition d‟un système et la
répartition des instances de composants , ainsi que les processus et objets qui vivent sur ces
matériels [Muller,2001].
Un diagramme de déploiement décrit la distribution physique de ressources
matérielles qui composent le système, et montre la répartition des composants sur ces
- 35 -
matériels. Chaque ressource étant matérialisé par un nœud , le diagramme de déploiement
précise comment les composants sont répartis sur les nœuds et quels sont les connexions
entre les composants et les nœuds, les diagrammes de déploiement existent sous deux formes :
spécification et instance [Fowler, 2005]. Les diagrammes de déploiement proviennent des
modules de BOOCH et des diagrammes de processus.
Un diagramme de déploiement permet de décrire la structure d'une plateforme technique,
de spécifier la localisation des nœuds constitués par des unités distribuées, de préciser où se
trouvent les processus et de montrer comment les objets se créent et se déplacent dans une
architecture distribuée [Lai, 2000]. La figure 1.6 illustre un exemple de diagramme de
déploiement.
b) Les concepts des diagrammes de déploiement
- Nœuds : Les diagrammes de déploiement sont essentiellement composés de nœuds, il en
existe deux types [Larman ,2006].
nœud physique (ou équipement) : ressource de traitement physique (exemple de
l‟électronique numérique) dotée de services de traitement et de mémoire destinés à
exécuter un logiciel (comme un ordinateur).
nœud d‘environnement d‘exécution (ENN : execution environnement node) :
ressource de traitement logiciel qui s‟exécute au sein d‟un nœud ( comme un
ordinateur ) et offrant en même temps un service pour héberger et exécuter
d‟autres logiciels .
- un chemin de communication : désigne la connexion normale entre les nœuds. Il peut
s‟accompagner de l‟indication du protocole et indique habituellement les connexions
réseau. Un nœud peut contenir et représenter un artefact, un élément physique concret
qui est en règle générale un fichier. Il peut s‟agir de fichiers JAR, d‟assemblies .NET, de
fichiers exécutables ou de scripts, ainsi que de fichiers de données XML, HTML etc. ….
c) Intérêts des diagrammes de déploiement :
- Visualiser le côté système en même temps que le système logiciel et afficher les
spécifications de l‟interconnexion matérielle et logicielle.
- 36 -
- Montrer l‟affectation d‟artefacts logiciels ( comme des fichiers exécutables ) à des nœuds
de traitement et présenter le déploiement des éléments logiciels sur l‟architecture
physique ainsi que la communication ( généralement en réseau ) entre les composants
physiques et servir à présenter l‟architecture physique ou de déploiement dans la
description de l‟architecture logicielle du processus unifié.
La Figure 1.7 extraite de [Fowler, 2004] illustre un exemple de diagramme de déploiement.
Figure 1.7 : exemple de diagramme de déploiement [Fowler, 2004]
Les diagrammes de paquetage (package) :
a) définition de diagrammes de paquetage : En UML, un diagramme de paquetage décrit
comment un système est organisé en groupes logiques appelés paquetages et montre les
dépendances entre ces paquetages. En effet, les packages permettent de regrouper et d'isoler des
classes, des associations, et éventuellement d'autre packages. Un package regroupe le plus
souvent un ensemble d'entités qui correspondent à une fonctionnalité bien définie. Bien souvent,
- 37 -
c'est cette fonctionnalité qui définira le nom du package. [Lopez, 2000]. La figure 1.8 extraite de
[Pender, 2002] présente un exemple de diagramme de package.
Figure 1.8 : exemple de diagramme de package. [Pender, 2002]
b) Les concepts des diagrammes de package : [Muller, 2001]
Package : chaque paquetage définit un espace de nommage, cela signifie que
tous les éléments contenus dans un paquetage se distinguent par leur
appartenance au paquetage englobant . Deux éléments de modélisation, contenus
dans deux paquetages différents, peuvent ainsi porter le même nom. En
revanche, les éléments contenus dans un paquetage (exception faite des
associations et généralisations) possèdent un nom unique.
Les éléments de modélisation situés au niveau le plus haut sont par défaut contenus
dans un paquetage racine. Ils doivent également avoir un nom unique.
La structuration d‟un modèle en packages est une activité délicate. Elle doit s‟appuyer sur
deux principes fondamentaux : cohérence et indépendance, ou la cohérence consiste à regrouper
les classes qui sont proches d‟un point de vue sémantique. Un critère intéressant consiste à
évaluer les durées de vie des instances de concept et à rechercher l‟homogénéité. Le deuxième
principe s‟efforce de minimiser les relations entre les packages. [Roques, 2005]
- 38 -
Dépendance entre package (ligne de dépendance) :Les éléments contenus dans un
paquetage emboité voient les éléments contenus dans leur paquetage ou dans les
paquetages englobant. Ils peuvent être associés entre eux à travers les niveaux
d‟emboitement. Pour avoir accès à des éléments qui ne sont pas accessibles
par défaut, il faut définir une relation de dépendance entre les paquetages
concernés. Une relation de dépendance entre paquetages doit exister dès lors que
deux éléments issus de deux paquetages différents sont associés, hormis en cas de
dépendance implicite (généralisation de paquetages et emboitement de paquetages),
Les dépendances entre paquetages représentent des relations entre paquetages et non
entre éléments individuels. Elles se représentent dans les diagrammes de classes, les
diagrammes de cas d‟utilisation et les diagrammes de composants. Une relation de dépendance
est orientée du paquetage source vers le paquetage cible. Les dépendances sont ainsi
unidirectionnelles.
c) Intérêts des diagrammes de packages :
- On emploie souvent les diagrammes de packages UML pour présenter l‟architecture
logique d‟un système : les couches, sous-systèmes, package (au sens java). Un
diagramme de package UML permet de grouper des éléments quelconques : classes,
autres packages, cas d‟utilisation, etc.…
- Les diagrammes de package sont extrêmement utiles dans les systèmes à grande échelle
pour obtenir une image des dépendances entre leurs principaux éléments. Ces
diagrammes correspondent bien aux structures de programmation courantes.
Représenter les packages et leurs dépendances permet de garder les dépendances
d‟une application sous contrôle.
Les diagrammes de structure composite :
a) Définition de diagrammes de structure composite : C‟est un nouveau diagramme introduit
en UML2. Il permet de présenter la décomposition hiérarchique d‟un objet, un cas
d‟utilisation, une collaboration, une activité ou une classe, en un ensemble de structures
internes. Ces structures internes sont des ensembles d‟éléments interconnectés avec leurs
relations et leurs modes de communication [Fowler, 2003].
- 39 -
Ce diagramme permet de réduire la complexité des objets en donnant une vue détaillée
sur l‟architecture interne de ces objets durant l‟exécution du système [Pilone, 2005].
Ce diagramme de structure composite présente l‟une des nouvelles caractéristiques les
plus significatives d‟UML2 qui réside dans la possibilité de décomposer hiérarchiquement une
classe en ses différentes parties. La figure 1.9 extraite de [Fowler, 2005] suggéré par Jim
Rumbaugh, montre un exemple sur un diagramme de structures composites qui représente la vue
interne d‟un composant.
Figure 1.9: exemple de diagramme de structure composite suggéré par Jim
Rumbaugh [Fowler, 2005]
b) Les concepts de diagrammes de structure composite :
Les éléments clés du diagramme de structure composite sont les classifieurs structurés, les
parties, les ports, les connecteurs et les collaborations.
- 40 -
Les classifieurs structurés : un classifieur structuré représente une classe, dans la
plupart des cas une classe abstraite, dont le comportement peut être décrit
complètement ou partiellement par le biais d'interactions entre parties. Un classifieur
encapsulé est une forme de classifieur structuré contenant des ports.
Les parties: une partie représente un rôle joué par une instance d'une classe ou un
ensemble d'instances à l'exécution. La partie peut donner le nom d'un rôle, d'une
super-classe abstraite ou d'une classe concrète spécifique. La partie peut inclure une
cardinalité.
Les ports : le port est un point d'interaction qui peut être utilisé pour connecter un
classifieur structuré avec ses parties ou son environnement. Les ports peuvent
accessoirement spécifier les services qu'ils fournissent ainsi que les services que
peuvent requérir d'autres parties du système. Les ports sont symbolisés par un carré
sur le diagramme.
Les ports peuvent déléguer les requêtes reçues à des parties internes ou au contraire les
délivrer directement à la partie qui possède le port en question. Les ports ayant un statut public
sont dessinés à cheval sur la bordure de la partie. A l'inverse, les ports protégés (non visibles par
l'environnement) sont contenus dans la partie.
Les connecteurs : Les connecteurs relient plusieurs entités, leur permettant d'interagir
entre elles lors de l'exécution. Un connecteur est représenté par une ligne reliant une
combinaison de parties, des ports ou des classifieurs structurés.
Les collaborations: une collaboration est en général d'un niveau d'abstraction plus
élevé qu'un classifieur. Elle est représentée par un ovale en pointillé contenant les
rôles joués par chaque instance dans la collaboration lors de l'exécution. Une
collaboration [Gabay, 2008] représente un assemblage de rôles d‟éléments qui
interagissent en vue de réaliser une fonction donnée.
Il existe deux manières de représenter une collaboration :
- représentation par une collaboration de rôles,
- représentation par une structure composite: le diagramme de structure
composite.
- 41 -
c) Intérêts des diagrammes de structure composite :
- Décomposer hiérarchiquement une classe en une structure interne et subdiviser un
Object complexe en ses différentes parties.
- Les diagrammes de structure composite représentent des regroupements lors de
l‟exécution par rapport aux diagrammes de packages qui représentent des regroupements
lors de compilation. [Fowler, 2005]
- 42 -
Les diagrammes de cas d‘utilisation
a) Définition :
Un cas d‟utilisation (use case) représente un ensemble de séquences d‟actions réalisées
par le système et produisant un résultat observable intéressant pour un acteur particulier.
Un cas d‟utilisation modélise un service rendu par le système. Il exprime les interactions
acteur/système et apporte une valeur ajoutée « notable » à l‟acteur concerné.
Un cas d‟utilisation est une manière spécifique d‟utiliser un système. Les acteurs sont à
l‟extérieur du système ; ils modélisent tout ce qui interagit avec lui. Un cas d‟utilisation réalise un
service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l‟acteur qui
l‟initie. [Charroux, 2010]
Un cas d‟utilisation [Balzert ,2006] décrit la fonctionnalité du système logiciel qu‟un
acteur doit exécuter pour obtenir un certain résultat ou pour atteindre un objectif. Les cas
d‟utilisation doivent permettre de discuter avec l‟utilisateur futur des fonctionnalités du
système logiciel sans se perdre dans les détails.
Pour l‟origine ; les diagrammes de cas utilisation sont similaires avec ceux de OOSE (
Object oriented software engineering] de IVAR JACOBSON [Fowler, 2005].
b) Les concepts des diagrammes de cas d‘utilisation [Balzert ,2006] [Charroux, 2010]
Les diagrammes de cas d‟utilisation comprennent les concepts suivants :
Un acteur : un acteur [Balzert ,2006] (actor) est un rôle joué par l‟utilisation du
système logiciel. Les acteurs peuvent être des personnes physiques comme des
systèmes automatisés. Ils se trouvent obligatoirement à l‟extérieur de système.
Le diagramme de cas d‟utilisation donne , à un niveau d‟abstraction supérieur, un bon
aperçu du système logiciel et de son interface . Les acteurs sont souvent spécifiés sous forme
de personnages stylisés. ils peuvent être représentés par un rectangle doté de stéréotypes
« actor » ou par un pictogramme ( exemple : un ordinateur ) .
- 43 -
L‟acteur est dit « principal » [Charroux, 2010] pour un cas d‟utilisation lorsque le cas
d‟utilisation rend service à cet acteur. Les autres acteurs sont dits « secondaires ». Un cas
d‟utilisation a au plus un acteur principal, et un ensemble – éventuellement vide – d‟acteurs
secondaires. Un acteur principal obtient un résultat observable du système tandis qu‟un acteur
secondaire est sollicité pour des informations complémentaires.
Les cas d‘utilisation : sont couramment modélisés sous forme d‟ellipse. Le nom
peut figurer à l‟intérieur de l‟ellipse ou au-dessus. Une ligne entre un acteur et
un cas d‟utilisation signifie qu‟une communication est établie. Elle est modélisée
sous forme d‟association en UML. Le système observé (subject ) est modélisé
dans le diagramme de cas d‟utilisation sous forme de grand rectangle comprenant
tous les cas d‟utilisation .
relations entre les cas d‘utilisation : Pour clarifier un diagramme UML permet
d‟établir des relations entre les cas d‟utilisation .Il existe principalement deux types de
relations: les dépendances stéréotypées et la généralisation/spécialisation. Les
dépendances stéréotypées sont des dépendances dont la portée est explicitée par le
nom du stéréotype. Les stéréotypes les plus utilisés sont l‟inclusion et l‟extension.
La relation d‘inclusion: Un cas A est inclus dans un cas B si le comportement décrit
par le cas A est inclus dans le comportement du cas B : on dit alors que le cas B
dépend de A. Cette dépendance est symbolisée par le stéréotype inclut. Par exemple,
l‟accès aux informations d‟un compte bancaire inclut nécessairement une phase
d‟authentification avec un mot de passe.
La relation d‘extension : si le comportement de B peut être étendu par le
comportement de A, on dit alors que A étend B. Une extension est souvent soumise à
condition. Graphiquement, la condition est exprimée sous la forme d‟une note. La
figure 1.10 extraite de [Charroux, 2010] présente l‟exemple d‟une banque où la
vérification du solde du compte n‟intervient que si la demande de retrait d‟argent
dépasse 20 euros.
La relation de généralisation : un cas A est une généralisation d‟un cas B si B est un
cas particulier de A, la consultation d‟un compte bancaire via Internet est un cas
particulier de la consultation. Cette relation de généralisation/spécialisation est
- 44 -
présente dans la plupart des diagrammes UML et se traduit par le concept d‟héritage
dans les langages orientés objet...
La figure 1.10 extraite de [Charroux, 2010] explique les relations entre cas dans un diagramme
de cas d‟utilisation.
Figure 1.10 : exemple d‘un diagramme de cas d‘utilisation. [Charroux, 2010]
c) Les intérêts des diagrammes de cas d‘utilisation :
Les intérêts des diagrammes de cas d‟utilisation sont :
- Modéliser le système.
- Déterminer les fonctionnalités du système à travers une vue d‟un acteur et le
représenter.
- Les cas d‟utilisation permettent de forcer l‟utilisateur ou l‟expert à définir ce qu‟il
attend du système.
- 45 -
- Les cas d‟utilisation constituent un outil précieux pour comprendre les exigences
fonctionnelles d‟un système, elles représentent une vue externe du système.
- 46 -
Les diagrammes d‘activités :
a) Définition : selon MARTIN FOWLER les diagrammes d‟activités sont une technique qui
permet de décrire la logique procédurale, les processus métier et les enchainements d‟activités
(workflows). Ils jouent à plus d‟un titre un rôle semblable à celui des organigrammes, la
principale différence étant qu‟ils prennent en charge les comportements parallèles . [Fowler,
2005]
Pour PIERRE ALAIN et NATALIE GAERTNER, un diagramme d‟activités représente
l‟état de l‟exécution d‟un mécanisme sous forme d‟un déroulement d‟étapes regroupées
séquentiellement dans des branches parallèles de flot de contrôle. Le début et la fin ( si elle
existe ) d‟un mécanisme sont définies respectivement par un état initial et un état final .
[Muller, 2001]
Un diagramme d‟activités est une variante des diagrammes d‟état transition, ils se
ressemblent dans leur présentation, mais leur interprétation est sensiblement différente. Dans
un diagramme d‟état transition, les états-transition, les états et les transitions sont mis en avant
alors que dans un diagramme d‟activités ce sont les activités et les transitions qui sont
mises en avant. Pour l‟origine : les diagrammes d‟activité dérivent des « workflows » décrits
dans de nombreuses anciennes méthodes. La Figure 1.11 représente un exemple de diagramme
d‟activités,
Les diagrammes d‟activités utilisent les concepts suivants : [Balzert, 2006] [Sinan Si
Alhir, 2002]
Activité : (Activity) décrit l‟exécution de fonctionnalités ou de comportements.
Elle est modélisée par plusieurs nœuds reliés par des flèches. On distingue les
nœuds d‟action, les nœuds de contrôle, et les nœuds d‟objets. Les activités
possèdent tant un modèle de flux de contrôle qu‟un modèle de données. Le modèle
flux de contrôle spécifie l‟ordre des fonctions tandis le modèle de données spécifie
les données échangées entre fonctions. L‟activité est un nouveau concept d‟UML 2.
Elle est modélisée dans un diagramme d‟activité (Activity diagram)
Action / nœud : la plus petite unité de fonction exécutable au sein d‟une activité
est l‟action (action). Elle est représentée sous forme de rectangle aux angles
arrondis. Ce rectangle contient le nom ou une brève description de l‟action. Si une
- 47 -
action est un appel d‟activité, alors un petit symbole de fourchette est apposé en
bas à droite.
En plus d'un nœud d‟action, une activité peut contenir un nœud de contrôle (control
node) : décision et exécution pour la modélisation d‟alternatives, répartition et synchronisation
pour les spécifications de déroulements parallèles ainsi que nœuds initiaux et finaux. Par
ailleurs UML2 propose un nœud final pour spécifier la fin d‟un flux de contrôle.
Les nœuds objets (Object nodes) permettent de porter les données d‟une action à
l‟autre. Ils sont représentés par des rectangles et réalisent le modèle de données d‟une
activité. Le nom du nœud objet est porté dans le rectangle (le nom de classe) avec, le cas échéant,
l‟état dans lequel se trouve l‟objet.
Les nœuds paramètres (paramètres d‟entrée et de sortie) sont un type particulier de
nœuds objets, portés aux extrémités d‟une activité.
Autre cas particulier : le stockage de données, qui modélise les données dormantes.
Les nœuds objets peuvent éventuellement être utilisés dans un mode streaming. Cela
signifie que les données sont créées ou utilisées en permanence.
Une forme particulière : les actions qui attendent un événement temporel (accept time
event, wait time action ), elle est symbolisé par un sablier, a l‟opposé de l‟attente d‟un
événement : une action envoyant un signal à un objet cible destiné à déclencher un processus.
Partitions : les partitions d‟activité ( activity partition ) regroupent les partitions
possédant certaines caractéristiques communes, comme une unité organisationnelle,
un lieu, un domaine de responsabilité, Il s‟avère souvent utile d‟organiser les
activités d‟un modèle en fonction des responsabilités, ce type d‟agencement est
matérialisé par des régions distinctes ( appelées partitions ) formant des couloirs
(swimlane, ligne d‟eau) ou les swimlane [Sinan Si Alhir, 2002] sont des région de
responsabilité pour les actions et sous-activités des états .
La figure 1. 11 extraite de [Audibert, 2006] résume un exemple de diagrammes d‟activités,
- 48 -
La figure 1.12 extraite de [Sinan Si Alhir, 2002] montre deux swimlane, un pour le système de
management du projet, et l‟autre pour la base de données.
Figure 1.11 : exemple de diagrammes d‘activités [Audibert, 2006]
- 49 -
Figure 1.12 : exemple de diagrammes d‘activités pour un projet de système de
management [Sinan Si Alhir, 2002].
b) Intérêts des diagrammes d‘activités :
Les intérêts des diagrammes d‟activités sont :
- Modéliser les comportements internes, d‟une classe, d‟un cas d‟utilisation ou d‟une
opération sous forme d‟une succession d‟actions.
- Représenter une succession d‟état synchrones (alors qu‟on préférera le diagramme
d‟états- transitions pour présenter une suite d‟état asynchrones).
- 50 -
- Permettre la représentation du parallélisme, qui offre un excellent outil de modélisation
de workflows [Fowler, 2005]
Les diagrammes d‘états- transitions:
a) Définition :
Diagramme d‟état transition ou diagramme de machine d‟états, y compris les états
simples, les transitions et les états composites imbriqués. Le concept d‟origine a été inventé par
David Harel, qui leur a donné le nom de diagrammes d‟états- transitions.
Une machine d‟état modélise les historiques de vie possibles d‟un objet de classe. Elle
contient des états reliés par des transitions. Chaque état modélise une période de vie d‟un objet
ou il remplit certaines conditions. Lorsqu‟un événement se produit, il déclenche une transition
qui envoie l‟objet vers un nouvel état. Lorsqu‟une transition a lieu, un effet (action à la
transition) s‟exécute.
Les diagrammes de machines d‟états illustrent ces machines d‟état, Pour l‟origine les
diagrammes d‟état transition « statecharts » proviennent de David Harel avec des modifications
mineures.
b) Intérêts des diagrammes d‘états- transitions :
Les intérêts de la modélisation par les diagrammes d‟états transitions sont :
- Donner vie aux objets (s‟ils s‟y prêtent), représentés jusqu'à présent de manière statique
comme des occurrences de classes qu‟on peut généraliser par les classes.
- Visualiser le système en diminuant sa complexité.
- Tenir compte des états lors de l‟implémentation (en effet la traduction des états peut
être faite simplement, la plupart de langages le permettent).
- Présenter un aspect du modèle dynamique, l‟autre étant illustré par les diagrammes
d‟activités, les diagrammes de collaboration et les diagrammes de séquence.
- Pouvoir décrire les changements d‟états des automates. La figure 1.13 Illustre un
exemple de diagrammes d‟état transition.
- 51 -
Figure 1.13 : exemple de diagrammes d‘états- transitions [Roques, 2007a]
Les diagrammes de séquence :
a) Définition :
Les diagrammes de classe et les diagrammes d'objet représentent l'information statique.
Dans un système fonctionnel cependant, les objets agissent l'un sur l'autre entre eux, et ces
interactions se produisent dans le temps. L'UML propose les diagrammes de séquence pour
montrer la dynamique temps-basée (time-based) de l'interaction. [Schmuller, 2004]
Les diagrammes de séquence montrent les interactions qui surviennent dans une
séquence de temps, en particulier, il montrent la participation des objets dans les interactions et
les messages qu'ils échangent dans une intervalle de temps .
- 52 -
Les diagrammes de séquence montrent les interactions entre objets. Comme les
diagrammes de collaboration. Toutefois la représentation se concentre sur la séquence des
interactions selon un point de vue temporel. Ils sont en général plus aptes à modéliser les
aspects dynamiques des systèmes temps réel et les scénarios complexes mettant en œuvre peu
d‟objets.
Un diagramme de séquence montre [Rumbaugh, 2005] une interaction de façon
bidimensionnelle. La dimension verticale correspond à l'axe temps, qui s'écoule du haut vers
le bas. La dimension horizontale montre les rôles que représentent des objets individuels dans
la collaboration. Chaque rôle est représenté par une colonne verticale contenant un titre et une
ligne verticale qui est la ligne de vie, l'existence d'un objet dans le temps est représentée par une
ligne en pointillé tant que la spécification de l'exécution d'une procédure est active pour un
objet. Sa ligne de vie est représentée par une double ligne.
En règle générale, un diagramme de séquence montre uniquement des séquences de
messages et non pas des intervalles de temps exactes.
Un message est représenté par une flèche allant de la ligne de vie d'un objet vers celle
d'un autre objet.
Les flèches s'organisent en séquences temporelles vers le bas du diagramme. On
symbolise un message asynchrone par une tête de flèche bâton.
En général, un diagramme de séquence capture le comportement d'un seul scénario.
Il contient un certain nombre d'objets et les messages transmis entre ces objets dans le
cadre d'un cas d'utilisation. Pour l‟origine : les diagrammes de séquence proviennent de
nombreuses méthodes orientés objets sous des noms différents (interaction, tracés messages et
tracés événements) et remontent aux premières méthodes orientés objets. Les auteurs disent
qu'ils proviendraient des objets message "sequencechart " du Siemens Pattern Group. La figure
1.12collectionne les concepts diagrammes de séquence.
b) Les concepts de diagrammes de séquence : [Balzert, 2006]
Les diagrammes de séquence utilisent les concepts suivants:
- 53 -
Ligne de vie : un diagramme de séquence (sequence diagramm) indique l'interaction
entre plusieurs partenaires de communication. Chaque partenaire de communication
est présenté par un rectangle (tête) doté d'une ligne, en pointillé éventuellement, et
qui représente la durée de vie du partenaire de communication. Au lieu de
"partenaire de communication", on parle également de « ligne de vie » (life line).
Le nom de partenaire de communication est indiqué dans le rectangle, le trait en
pointillé d'une ligne de vie représente un axe temporel. Le trait en pointillé d'une
ligne de vie représente un axe temporel, orienté de haut en bas. Le diagramme de
séquence est encadré d'un cadre rectangulaire, contenant, en haut à gauche, le
raccourci sd (sequence diagram).
Message : l'interaction entre deux partenaires de communication peut se produire via
un message synchrone ou asynchrone.
Dans le cas d'un message synchrone, l'expéditeur attend que le destinataire ait
intégralement exécuté le traitement nécessaire. Le destinataire envoie ensuite un message de
réponse à l'expéditeur, qui fait implicitement part de la fin de traitement et que peut en outre
contenir des données de réponse. Les messages synchrones sont souvent des appels
d'opération, mais ils peuvent également être des signaux. Les messages synchrones sont
représentés par une flèche à pointe fermé, les messages asynchrones sont représentés par une
flèche à pointe ouverte . La réponse d'un message synchrone est une flèche en pointillé. La
période pendant laquelle un partenaire de communication exécute le traitement exigé peut
être modélisée par une barre grise ou transparente chevauchant le trait en pointillé
(spécification d'exécution).
Dans le cas des messages asynchrones, l'expéditeur n'attend pas la fin de traitement par
le destinataire, il continue en parallèle son propre traitement.
Les messages asynchrones sont toujours réalisés par un signal.
Il existe une particularité : le message de création d'un nouveau partenaire de
communication est représenté par une flèche en pointillé, pointant vers le rectangle du
- 54 -
partenaire de la communication nouvellement crée à l'opposé : la suppression d'un partenaire de
communication (fin de la ligne de vie) est modélisée par un X majuscule. La figure 1 .14 illustre
les concepts utilisés dans un diagramme de séquence.
Figure 1.14: Les concepts diagrammes de séquence [Balzert, 2006].
c) Intérêts des diagrammes de séquence :
Les diagrammes de séquence présentent les intérêts suivants :
- Permettre de mieux comprendre le fonctionnement du système ; modéliser la vie des
objets dans le temps et leur chronologie.
- Représenter les interactions, les communications (par message) entre objets.
- D'être très utile dans la description des cas d'erreur et des cas limites d'utilisation du
système.
- 55 -
- En règle générale, un diagramme de séquence montre uniquement des séquences de
messages et non pas des intervalles de temps exactes. On peut utiliser un diagramme
timing lorsqu'il est important de mesurer le temps, mais pour comprendre la sémantique
des interactions, les diagrammes de séquence suffisent amplement.
- 56 -
Les diagrammes de communication :
a) Définition de diagramme de communication :
Diagramme qui présente les interactions organisées autour de différentes parties d‟une
structure composite ou des rôles d‟une collaboration. Contrairement à un diagramme de
séquence, un diagramme de communication signale explicitement les relations entre les
éléments. En revanche, il ne présente pas le temps sous la forme d‟une dimension distincte ainsi
les séquences de messages et threads concurrents doivent être déterminés avec des numéros de
séquence. Les diagrammes de séquence et les diagrammes de communication s‟expriment par
interactions, mais se présentent de manière différente. La figure 1.15 exemple de diagramme
de communication.
b) Les concepts de diagrammes de communication :
Selon Craig Larman les diagrammes de communication utilise les concepts
suivant [Larman, 2006]:
Liens : un lien est une connexion entre deux objets qui indique qu‟une forme
de navigation et de visibilité entre eux est possible, de façon plus formelle,
c‟est une instance d‟association.
Message : chaque message entre objets est représenté par une expression, et une
petite flèche indique sa direction. Chaque lien permet la circulation de plusieurs
messages, un numéro de séquence est associé à chaque message : il indique
son ordre dans le thread de contrôle courant. Un objet peut s‟envoyer, via un
lien, un message à lui-même. On emploie alors un lien retournant vers l‟objet, et
les messages sont assortis de numéros de séquence. Voici le schéma de
numérotation :
1. Le premier message n‟est pas numéroté.
2. L‟ordre et le niveau d‟imbrication des messages suivants sont tracés selon un plan de
numérotation réglementé ou l‟on ajoute un numéro à la fin des messages imbriqués. On
indique l‟imbrication en ajoutant le numéro du message entrant au début du message
sortant.
- 57 -
Le message peut avoir le caractère conditionnel, on fait suivre son numéro d‟ordre
d‟une clause de condition entre crochets. Le message n‟est alors envoyé que si la condition
est remplie.
Instance : tout message peut servir à créer une instance, mais la convention
UML veut qu‟on utilise à cet effet un message nommé « create » (new). Si on
emploie un autre nom de message, on doit l‟annoter avec le stéréotype UML
« create », ce message peut comprendre des paramètres indiquant la transmission
de valeurs initiales. Il peut s‟agir, par exemple d‟un appel de constructeur avec
paramètres en java. De plus, on peut ajouter la valeur marquée ( marqued value
) UML {NEW} à la boite de ligne de vie pour souligner le fait qu‟il s‟agit
d‟une création, les valeurs marquées sont un mécanisme d‟extension souple qui
permet d‟ajouter les informations significatives sur la sémantique d‟UML.
Appel synchrone ou asynchrone : comme dans les diagrammes de séquence,
les appels asynchrones sont représentés à l‟aide d‟une flèche ouverte et les
appels synchrones à l‟aide d‟une flèche pleine.
c) Intérêts des diagrammes de communication :
- Les diagrammes de communication sont intéressants lorsqu‟on applique UML « en
mode esquisse » en modélisant au tableau (une pratique agile) parce qu‟ils permettent de
mieux exploiter l‟espace. En effet ; on peut ajouter et supprimer des boites n‟importe
où sur l‟axe horizontal ou vertical.
- Une approche plus rationnelle consiste à considérer que les diagrammes de séquence
sont préférables lorsqu‟ on doit mettre l‟accent sur les séquences d‟appels et que les
diagrammes de communication sont privilégiés si on doit mettre les liens en évidence.
Les diagrammes de communication sont plus faciles à modifier lorsqu‟on travaille au
tableau et constituent une bonne méthode pour explorer des alternatives.
- 58 -
Figure 1.15 : exemple de diagramme de communication [Audibert, 2006]
Le diagramme global d‘interactions (Interaction overview diagram)
Comme leur nom l'indique, le diagramme global d‟interactions donne une vue globale sur
les interactions des objets actifs du système. Il regroupe des diagrammes d‟activité et des
diagrammes de séquence. Il est présenté soit comme un diagramme d‟activités dont les activités
sont remplacées par des diagrammes de séquences, soit comme un diagramme de séquences
contenant des notations du diagramme d‟activité pour montrer le flux des activités [Fowler,
2003].
Les diagrammes d‟interactions permettent d‟établir un lien entre les diagrammes de cas
d‟utilisation et les diagrammes de classes : ils montrent comment des objets (des instances de
Classes) communiquent pour réaliser une certaine fonctionnalité. Ils apportent un aspect
dynamique à la modélisation du système [Audibert ,2006]. La figure 1.16 illustre un exemple
d'un diagramme global d‟interaction.
- 59 -
Figure 1.16: Exemple d'un diagramme global d‘interaction [Fowler, 2003]
Diagramme de temps :
a) Définition :
Le diagramme de temps (timing diagram) : C‟est une nouveauté apparue dans UML 2 .0
.Le diagramme de temps permet de représenter les états et les interactions d‟objets dans un
contexte où le temps a une forte influence sur le comportement du système à gérer.
Autrement dit, le diagramme de temps permet de mieux représenter des
changements d‟états et des interactions entre objets liés à des contraintes de temps.
Pour cela, le diagramme de temps utilise, en plus des lignes de vie, les concepts suivants :
des états ou des lignes de temps conditionnés avec deux représentations graphiques possibles.
- 60 -
Deux figures extraites de [Ambler, 2004] représentent deux manières pour tracer les
diagrammes de temps.
Figure 1.17: deux manières pour tracer les diagrammes de temps. [Ambler, 2004]
b) Les concepts de diagrammes de temps :
Le diagramme de temps utilise trois concepts de base : [Gabay, 2008]
Ligne de vie : Elle indique l‟objet que l‟on veut décrire. Elle se dessine de
manière horizontale. Plusieurs lignes de vie peuvent figurer dans un diagramme de
temps.
État ou ligne de temps conditionnée : Les distincts états que peut prendre l‟objet
d‟étude sont listés en colonne permettant ainsi de suivre le comportement de
l‟objet ligne par ligne (une ligne pour un état).
États linéaires : Il s‟agit du même concept que le précédent, mais la
représentation de la succession des états est faite de manière linéaire à l‟aide d‟un
graphisme particulier.
- 61 -
c) Les intérêts des diagrammes de timing :
- Les diagrammes timing sont utiles pour présenter les contraintes temporelles entre les
changements d‟état de différents objets. Ils sont particulièrement familiers aux
électroniciens.
II.4 Les vues d'UML:
L'architecture d'un logiciel ne comporte pas qu'une dimension. Elle est au contraire
constituée de plusieurs concurrents, les vues présentent les différents aspects d'un système. Une
vue n'est pas un élément graphique ou un diagramme, mais une abstraction qui englobe un
nombre de diagrammes afin de décrire le système d'un point de vue donné.
Disposer d'une architecture est une chose la décrire en est une autre. Philipe Kruchten a
encouragé l'idée, très largement adoptée, qui consiste à décrire une architecture en utilisant
plusieurs vues, voici la définition de cette vue architecturale.
Définition: vue de l'architecture du système depuis un point de vue donné ; la vue architecturale
se concentre avant tout sur la structure, la modularité, les composants essentiels et les
principaux flots de contrôle d'un système, une vue architecturale est une fenêtre ouverte sur le
système d'un point de vue particulier qui met l'accent sur les informations essentielles. La figure
1.18 illustre les" 4+1" vues de l'architecture.
- 62 -
Figure 1.18 : les "4+1"vues de l'architecture [Kruchten, 1995a] [Kruchten, 1995b].
II.4.1 La vue logique : [Quatrani ,2000]
Les besoins fonctionnels du système, autrement dit les services qu'il doit apporter aux
utilisateurs, sont traités dans la vue logique de l'architecture. Celle-ci est constituée de
diagrammes de classes qui contiennent les abstractions clefs du système, représentées sous
forme de classes et de relations d'agrégation, relations de généralisation et les paquetages. La
vue logique est traitée au début de la phase d'élaboration ; elle produit les classes et les
paquetages qui constituent les abstractions principales du domaine. Au fur et à mesure, des
classes et des paquetages supplémentaires sont ajoutés aux modèles pour prendre en compte les
choix relatifs aux mécanismes clefs du système.
La vue architecturale logique reflète le point de vue fondamental [Larman ,2006]:
- 63 -
- Organisation conceptuelle du logiciel du point de vue des couches, sous-systèmes,
packages, Frameworks, classes et interfaces les plus importants. Elle résume également
les fonctionnalités des principaux éléments logiciels, comme chaque sous système.
- Représentation des scénarios de cas d‟utilisation les plus importants (sous forme de
diagrammes d'interaction) qui illustrent les aspects essentiels du système.
- Vue sur le modèle de conception UP ; représentée en UML par des diagrammes de
packages, de classes et d‟interaction.
Pour résumer, la vue logique décrit les aspects statiques et dynamiques du système en
termes de classes et d‟objets. Elle se centralise sur l‟abstraction et l‟encapsulation et met en jeu
des objets et des classes, ainsi que des collaborations et des interactions autour de ces objets.
Cette vue est constituée de diagrammes de classes, d‟objets, de séquence, de collaboration et
d‟états.
II.4.2 La vue de processus:
La vue de processus représente la décomposition en flots d'exécution (processus,
thread, tâches…), la synchronisation des flots et l'allocation des objets et des classes au sein des
différents flots. La vue de processus se préoccupe également de la disponibilité du système, de
la fiabilité des applications et des performances. La vue de processus prend son importance
dans les environnements multitâches [Muller, 2001].
Pour résumer, la vue de processus décrit la décomposition en flots d‟exécution
(processus, fils D‟exécution et tâches), la synchronisation entre flots et l‟allocation des objets et
des Classes au sein des différents flots. Elle prend toute son importance dans des environnements
multitâches. Elle fait apparaître les tâches, les fils d‟exécution, les processus et les interactions,
dans des diagrammes de séquence, de collaboration et d‟états.
Cette vue réfléchit un point de vue fondamental suivant [Larman ,2006] :
- Processus et thread, responsabilités, collaborations et allocation d'éléments logiques
(couches, sous-système, classes…..)
- Vue sur le modèle de conception UP, représenté en UML par des diagrammes de classes
et d'interactions, en utilisant la notation UML pour les threads et les processus.
- 64 -
II.4.3 La vue d'implémentation :
Ou encore vue de réalisation, elle se préoccupe de l'organisation des modules statiques
(les exécutables, le code source ….) dans l'environnement de développement ; elle montre
l'allocation des classes dans les modules et l'allocation des modules dans les sous-systèmes
[Muller, 2001]. Cette vue de l'architecture décrit l'organisation des composants logiciels au
sein de l'environnement de développement. Elle prend en compte des besoins auxiliaires
comme la facilité d'utilisation, la gestion du logiciel, la réutilisation et les contraintes imposées
par le langage de programmation. Les outils de développements, les paquetages, les composants
et les relations qui les lient constituent les éléments de modélisation employés pour décrire la
vue des composants de l'architecture. [Quatrani, 2000].
Pour résumer, la vue de réalisation se préoccupe de l‟organisation des modules dans
l‟environnement de développement. Elle montre l‟allocation des classes dans les modules, et
l‟allocation des modules dans les sous-systèmes. Les sous-systèmes sont eux-mêmes organisés en
niveaux hiérarchiques comportant des interfaces bien définies. Cette vue définit les modules, les
sous-programmes, les sous-systèmes et les tâches, dans des diagrammes de
composants, cette vue réfléchit les points de vue suivants [Larman ,2006] :
- Tout d'abord, le modèle d'implémentation, contrairement aux autres modèles UP qui se
constituent de texte et de diagrammes, se compose du code source réel, des exécutables,
etc..., il comprend deux parties : 1) les livrables ; 2) les éléments qui créent des livrables
(comme code source et les fichiers graphiques). Le modèle d'implémentation contient les
pages web, les DLL, les exécutables, le code source...
- La vue d'implémentation est une description sommaire de l'organisation des livrables et
des éléments qui créent des livrables (code source).
- Vue sur le modèle d‟implémentation, exprimée de manière textuelle et représentée sous
forme de diagrammes de packages et de composants.
II.4.4 La vue de déploiement :
L'objet de cette vue est l'assignation des parties exécutables du logiciel aux nœuds
physiques que sont les machines ou les processeurs. Cette vue décrit la position géographique
- 65 -
et l'architecture physique de chaque élément du système. Elle décrit aussi les ressources
matérielles et la répartition du logiciel dans ces ressources, les dispositions et nature physiques
des matériels ainsi que leurs performances, l'implémentation des modules principaux sur les
nœuds du réseau, les exigences en terme de performances ( temps de réponse tolérance aux
pannes) , cette vue trouve toute son importance lorsque le système est distribué [Muller,2001].
Pour synthétiser, La vue de déploiement décrit les ressources matérielles et l‟implantation
du logiciel dans ces ressources. Elle tient toute son importance lorsque le système est distribué.
Cette vue se concentre sur les nœuds, les modules et les programmes principaux, dans des
diagrammes de déploiement.
Cette vue réfléchit les points de vue fondamentaux [Larman ,2006]:
- Déploiement physique des processus et des composants sur les nœuds de traitement, et
configuration physique du réseau entre les nœuds.
- Vue sur le modèle de conception UP, représentée en UML par des digrammes de
déploiement. Normalement la vue est constituée par l'intégrité du modèle et non pas par
un sous ensemble.
II.4.5 La vue des cas d'utilisation :
La vue des cas d‟utilisation [Guiochet ,2003] unit les quatre vues précédentes. Les cas
d‟utilisation permettent d‟identifier les interfaces critiques, et obligent les concepteurs à se
concentrer sur les exigences fonctionnelles. Elle rend compte des acteurs, des cas d‟utilisation,
des classes et des collaborations à l‟aide de diagrammes des cas d‟utilisation et de diagrammes
de séquence ou de collaboration, cette vue produit selon [Larman ,2006] :
Un résumé des cas d'utilisation les plus importants quant à l'architecture et à leurs
exigences non fonctionnelles. Autrement dit, il s'agit de cas d'utilisation qui, par leur
implémentation, couvrent les aspects les plus importants de l'architecture qui impliquent de
nombreux éléments architecturaux.
Dans son article décisif, Philippe Kruchten ne s'est pas contenté d'encourager la
documentation d'une architecture à partir de plusieurs vues. Il a présenté plus spécifiquement les
- 66 -
4+1 vues qui se sont désormais étendues à N+1 vues, plus générales, qui reflètent les multiples
questions liées à un système. Pour plus de d‟informations consulter [kruchten, 1995].
II.5 Extensions du langage ML [Raimbault, 2008] [Cheesman, 2000] [Pender, 2003]
Stéréotype : L‟usage de stéréotypes est un mécanisme d‟extensibilité du langage UML
[OMG, 2005a] [OMG, 2005b]. Un stéréotype permet de générer de nouvelles notations
UML à partir de celles existantes, afin de mieux dresser le langage UML pour modéliser
un domaine donné .Un stéréotype permet d‟exploiter les éléments UML d‟une manière
distincte. Couramment, un stéréotype permet de spécifier l‟élément de base (sans
stéréotype) auquel il est appliqué. Les éléments UML dotés de stéréotypes sont appelés
des éléments stéréotypés. Concrètement, un stéréotype n‟est autre qu‟un mot, couramment
un nom commun, qui donne la signification dont l‟élément stéréotypé est utilisé dans la
modélisation. Un même stéréotype peut s‟appliquer à un ou plusieurs types d‟éléments
UML. Un stéréotype est représenté comme son élément de base, auquel est ajouté à côté
du nom de l‟élément le nom du stéréotype entre „≪‟ et „≫‟. La figure 1.19 montre le
Stéréotype« interface »dans le symbole de classe , et le Stéréotype « use » dans l‟arc
de dépendance. Ces Stéréotypes enrichissent les éléments UML par des informations
supplémentaires .voir la figure 1.19extraite de [Perdita ,2006] présente un exemple de
Stéréotypes.
- 67 -
Figure 1.19 : exemple de Stéréotypes [Perdita ,2006]
OCL : Le langage OCL - Object Constraint Language considéré comme le langage
formel officiel au sein du modèle UML, elle constitue une extension d‟UML
[Warmer ,99] depuis la réalisation de la version 1.1 en 1998 en collaboration avec la
société IBM. OCL est devenu intégrante depuis la version1.3, apparue en juin
1999.Depuis la version 2.0 d‟UML, OCL permet aussi de définir le méta-modèle
d‟UML.
Concrètement, OCL exprime textuellement des contraintes sous forme de pseudo-codes.
Ces contraintes s‟expriment essentiellement en terme d‟invariants sur les attributs, et de pré et
post-conditions pour les opérations. En effet OCL ajoute certes de l‟expressivité au langage
UML, mais il le fait de façon textuelle alors que l‟intensité d‟UML apparaît dans sa possibilité
de représenter des connaissances de façon visuelle.
En UML, une contrainte OCL est insérée dans un commentaire UML, éventuellement liée
à l‟élément concerné par la contrainte.
Une contrainte OCL permet de raffiner les spécifications d‟une modélisation là où le
vocabulaire visuelle d‟UML y est incapable en termes de représentation. Il s‟agit d‟un langage
- 68 -
d‟expression de contraintes qui est adapté aux diagrammes UML, les auteurs [Warmer ,99]
[Pender, 2003] [OMG, 2006b] suggèrent d‟utiliser les expressions OCL pour :
- Spécifier les invariants de classes et les types dans les diagrammes de classes ;
- Spécifier le « type invariant » pour les stéréotypes.
- Décrire les prés-et post conditions des opérations déclarées dans les diagrammes de
classe.
- Décrire les gardes au sein des diagrammes d‟états- transitions.
- La figure 1.3 extraite [Meyer, 2001] exprime une contrainte appliquée sur la classe
client qui regroupe les particuliers et les sociétés .Pour plus de détails sur OCL lire
[OMG, 2010] [OMG, 2006b].
Tagged value : [Rumbaugh, 2005]
Une valeur marquée est une paire (nom, valeur) qui ajoute une nouvelle propriété à
un élément de modélisation [Muller, 2001].
Une valeur étiquetée est une paire nom-valeur qu‟on peut associer à un élément de
modèle exploitant un stéréotype qui contient une définition de tag.
Les valeurs étiquetées indiquent d‟autres informations de modélisation, en sus de celles
définies dans le méta modèle UML.
Les valeurs étiquetées sont un mécanisme d‟extensibilité permettant d‟associer des
informations arbitraires à des modèles .elles sont matérialisées sous la forme : Tag = valeur
La figure 1.7 illustre un exemple de valeur marquée. Concernant le tag OS (operating
system) qui prends la valeur Windows.
Sérialisation en XMI: Le format XMI - XML Metadata Inter change est une norme
standardisée par l‟OMG, pour l‟échange d‟informations de métadonnées basé sur
XML. Il s‟agit d‟une méthode de sérialisation d‟éléments MOF .Le langage MOF -
Meta-Object Facility- (un autre standard 11 de l‟OMG) est un langage auto-défini
pour représenter et manipuler des méta-modèles. En fait, MOF représente une plate-
- 69 -
forme commune pour définir les standards de l‟OMG : « The Meta Object Facility
Specification is the fondation of OMG‘ s industry-standard environment ».
Le langage UML étant conforme au standard MOF, il en résulte qu‟une modélisation
En UML peut être sérialisée en XMI. La sérialisation d‟éléments UML en XMI est spécifiée
depuis la version 1.3 d‟UML. En réalité, Le format XMI ne constitue pas une véritable extension
d‟UML, mais elle propose un format standard de stockage et d‟échange de connaissances
modélisées dans le modèle UML. Pour plus d‟informations sur cette extension lire [OMG,
2007b] [Timothy, 2002].
II.6 L‘architecture UML :
Le langage UML s‟inscrit dans une architecture à quatre couches ou niveaux de méta-
modélisation qui sont :
Méta-méta-modèle (niveau M3) : La couche méta-méta-modèle permet de définir le
langage pour spécifier un Méta modèle. Pour le langage UML (langage de niveau
M2), son méta modèle est le langage MOF [OMG, 2006a] (niveau M3). Il fournit par
exemple le concept de classe. Il permet de généraliser les constructions d‟UML que
sont les attributs, classes et instances grâce à la notion de classe du niveau M3.
Méta-modèle (niveau M2) : Un méta-modèle est une instance d‟un méta-méta-
modèle. La couche “méta-modèle” permet de définir le langage pour spécifier un
modèle et c‟est à ce niveau-là que les notions comme celles de classe, attribut,
opération, sont présentées dans la superstructure de la spécification d‟UML [OMG,
2005a]. Ces notions sont des instances du concept de classe de niveau M3, comme
présenté à la figure 1.20 extraite de l‟infrastructure de la version 2.0 de la
spécification d‟UML [OMG, 2005b].
Modèle (niveau M1) : La couche modèle est une instance du méta-modèle. Le
principal rôle du niveau “modèle” est de définir un langage qui décrit un domaine
d‟information. C‟est à ce niveau que seront définis les noms des classes ou d‟instances
de classes, attributs et opérations propres au système modélisé. Des exemples d‟objets
du niveau modèle sont : Fenêtre, couleur Fenêtre (ou bleu pour une instance de
l‟attribut couleur de la classe Fenêtre) et afficher Fenêtre ().
- 70 -
Objets utilisateurs (ou instances exécutables, run-time instances en anglais,
niveau dit M0) : Les objets utilisateurs sont des instances exécutables d‟un modèle.
Le rôle du niveau “données utilisateurs” est de décrire un domaine d‟information
spécifique. Des exemples d‟objets du niveau objets utilisateurs sont : <Fenêtre 3>
(instance de Fenêtre), un appel de l‟opération instance d‟afficher Fenêtre ().Le tableau
1.2 récapitule les quatre couches et la figure 1.20 et représente cette même
architecture avec des classes UML.
Tableau. 1.2 : Architecture en quatre couches
- 71 -
Figure. 1.20: Exemple de hiérarchie de méta modélisation en 4 couches [OMG, 2005b].
- 72 -
III. Le Processus De Développement
UML est un langage de modélisation, pas un processus, et son objectif est de décrire
des modèles qui pourront être produits par le biais de processus de développement divers à des
fins de standardisation .Il est plus important de décrire les artefacts résultant d‟un
développement que le processus conduisant à leur production .dans tous les cas ,UML a été
conçu pour prendre en charge un large éventail de processus. [Rumbaugh, 2005].
Lorsque les trois amigos, Grady Booch, James Rumbaugh et Ivar Jacobson, ont conçu le
langage UML, ils ont volontairement distingué le langage de modélisation de la méthode
permettant de mener à bien le projet de développement d'une application afin de laisser libre
chaque concepteur d‟adopter la méthode la Plus adaptée à son environnement professionnel.
Maintenant, il existe de plusieurs méthodes de conduite de projet qui sont classées en
deux grandes familles : les méthodes dites traditionnelles et les méthodes agiles.
Les méthodes traditionnelles: Les méthodes traditionnelles proviennent le plus
souvent des méthodes de gestion de projet éprouvées en ingénierie industrielle ou
dans le secteur du Bâtiment et des Travaux Public [Larman, 2002 a]. Il existe une
multitude de méthodes traditionnelles pour développer une application informatique
mais la plupart reposent sur Quelques méthodes de référence :
- Cycle en cascade et cycle en V.
- Cycle en spirale.
- RAD (Rapid Application Development).
- UP (Unified Process).
Les méthodes agiles : la méthode extrême Programming est la plus répandue. Pour
cela nous allons consacrer cette section pour développer le processus unifié (UP) et
Méthode 2 Track Unified Process (2TUP).
- 73 -
III.1 Méthode Processus Unifié (UP)
Selon [Jacobson, 2003] Les idées qui donneront naissance à la méthode de conduite
Processus Unifié datent de la fin des années soixante.
Le processus unifié est un processus de développement logiciel, c'est-à-dire qu‟il
regroupe les activités à mener pour transformer des besoins d‟un utilisateur en système
logiciel. [Jacobson, 2000].
[Jacobson, 1999] précise que la méthode Processus Unifié est la synthèse des meilleures
pratiques de développement logiciel sur trois décennies dans des domaines variés. Bien qu‟elle
soit totalement dissociée du langage UML [Fowler, 2005], elle est associée à ce langage de
modélisation car les auteurs d‟UML, Grady Booch, Ivar Jacobson et James Rumbaugh, ont
participé à sa formalisation. [Jacobson, 2000] a mentionné que le processus unifié utilise le
langage UML pour la création des plans d‟élaboration et de construction du système
logiciel. Et certainement, d‟après [Jacobson, 2000], UML fait partie intégrante de processus
unifié : l‟un et l‟autre ont été développés de concert.
III 1.a Les Principes de la méthode UP
La méthode Processus Unifié repose sur quatre principes suivants : le processus de
développement doit être conduit par les cas d'utilisation, itératif et incrémental, centré sur
l'architecture et piloté par les risques. [Larman, 2002b].
Le principe du développement conduit par les cas d'utilisation :
Le but de tout projet informatique est d‟imiter le comportement d'un système afin
d‟exaucer un besoin ou une exigence. Aussi, il faut d‟une part, mobiliser la connaissance qu'ont
les acteurs d‟un système à travers le domaine (aspects structurels) et les comportements de ces
concepts (aspects dynamiques) et, d‟autre part, bien d‟identifier les besoins ou les exigences des
utilisateurs (aspects fonctionnels).
Pour ce faire, il est nécessaire de mettre en œuvre une technique de capture de cette
connaissance et de ces besoins et exigences. Pour cela, le Processus Unifié propose d'utiliser le
concept des cas d'utilisation et celui des scénarios [Rumbaugh, 2005].
- 74 -
Les cas d'utilisation ont été introduits par Ivar Jacobson en 1987[Jacobson, 2003]. Il en
donnait la définition suivante : un cas d'utilisation est une séquence de transactions accomplies
entre un utilisateur et un système au cours d'un dialogue.
Le principe du développement itératif et incrémental :
La définition d‟itérations de réalisation est en effet la meilleure pratique de gestion des
risques d‟ordre à la fois technique et fonctionnel. On peut estimer qu‟un projet qui ne produit rien
d‟exécutable dans les 9 mois court un risque majeur d‟échec. Chaque itération garantit que les
équipes sont capables d‟intégrer l‟environnement technique pour développer un produit final et
fournit aux utilisateurs un résultat tangible de leurs spécifications. Le suivi des itérations
constitue par ailleurs un excellent contrôle des coûts et des délais. [Roques, 2007a]
Le principe du développement centré sur l'architecture :
Selon [Jacobson, 1999], ce principe a été introduit par les auteurs de la méthode afin de
souligner l‟importance du travail de structuration de l‟application en systèmes et sous-systèmes
que doit impérativement faire le concepteur. D‟après [Roques, 2007a], La structuration en sous-
systèmes ne doit pas être une simple description du système sous forme graphique ou textuelle
mais elle doit être matérialisée. La structuration d‟une application est nécessaire pour les quatre
raisons suivantes [Jacobson, 1999] :
- Compréhension du système
- Organisation du développement
- Réutilisation de composants existants
- Évolution du système
Le principe du développement piloté par les risques :
Le pilotage par les risques du développement d‟une application permet de prendre en
compte des problèmes très tôt voire à leur origine et de les traiter par anticipation.
Il existe plusieurs catégories de risques mais les risques les plus importants sont d‟une
part, les risques financiers et les risques commerciaux [Muller, 2001] et, d‟autre part, les risques
- 75 -
non techniques et des risques techniques [Jacobson., 1999].Pour s‟informer sur d‟autres
caractéristiques d‟UP consulter [Misfu ,2010].
III .1.b les phases de la méthode Processus Unifié :
Dans la méthode Processus Unifié, le cycle de développement d‟une application est
planifié en quatre phases : l‘inception, l‘élaboration, la construction et la transition [Jacobson,
1999]; [Kruchten, 1999; [Larman, 2002a]. La figure 1.21 Illustre les activités et intensité de
production en fonction de l‟avancement du projet.
L'inception est la phase d'ébauche du projet [Booch, 2000]. Dans la phase d'élaboration,
l'identification et la description des besoins et l‟évaluation des risques sont effectuées. La phase
de construction consiste à concevoir et à implémenter les cas d‟utilisation. Craig Larman
synthétise cette phase par la métaphore : on met de la chair au squelette créé lors de la phase
d'élaboration [Larman, 2002a]. La transition [Booch, 2000]; [Roques, 2007a] est la phase de
transfert de l'application vers les utilisateurs et de son déploiement dans un environnement
opérationnel [Jacobson, 1999].
Figure1.21 : Activités et intensité de production en fonction de l‘avancement du projet
[Booch, 2000] [Jacobson, 1999] [Kruchten, 1999]
- 76 -
III.2Méthode 2 Track Unified Process (2TUP)
La méthode 2TUP est une méthode Processus Unifié qui a été élaboré par [Roques,
2007a] pour apporter une réponse aux contraintes de changement continuel imposées aux
systèmes d'information de l‟entreprise.
En ce sens, il renforce le contrôle sur les capacités d‟évolution et de correction de tels
systèmes. 2 Track [Roques, 2007a] signifient littérairement que le processus suit deux chemins.
Il s‟agit des chemins « fonctionnels » et «d‟architecture technique » qui correspondent aux deux
axes imposés au système informatique.
Selon [Roques, 2007a] le processus 2TUP comporte :
La branche gauche (fonctionnelle) comporte :
La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur
le métier des utilisateurs. elle qualifie au plus tôt le risque de produire un système
inadapté aux utilisateurs. De son côté la maitrise d‟œuvre consolide les
spécifications et en vérifie la cohérence et l‟exhaustivité l‟analyse, qui consiste à
étudier précisément la spécification fonctionnelle de manière à obtenir une idée de
ce que va réaliser le système en termes métier .
La branche de gauche porte sur les aspects fonctionnels liés à la spécification en termes
métier. Les résultats de l‟analyse ne dépendent d‟aucune technologie particulière.
la branche de droite (architecture technique) comporte :
La capture des besoins techniques , qui examine toutes les contraintes et les choix
dimensionnant la conception du système .Les outils et les matériels sélectionnées ainsi que la
prise en compte de contraintes d‟intégration avec l‟existant conditionnent généralement des
pré- requis d‟architecture Technique.
La conception générique, qui définit ensuite les composants nécessaires à la
construction de l‟architecture technique. Cette conception est la moins dépendante
possible des aspects fonctionnels. Elle a pour objectif d‟uniformiser et de réutiliser
les mêmes mécanismes pour tout un système. L‟architecture technique crée le
- 77 -
squelette du système informatique et écarte la plupart des risques de niveau
technique. L‟importance de sa réussite est telle qu‟il est conseillé de réaliser un
prototype pour assurer sa validité.
La branche de milieu comporte :
La conception préliminaire , qui présente une étape délicate, car elle intègre le
modèle d‟analyse dans l‟architecture technique de manière à tracer la cartographie
des composants du système à développer .
La conception détaillé, qui étudié ensuite comment réaliser chaque composant.
L'étape de codage, qui produit ces composants et teste au fur et à mesure les
unités de codes réalisées.
L‟étape de recette, qui consiste enfin à valider les fonctions du système
développé. La figure 1.22 présente le processus de développement 2TUP.
Figure 1.22 : Le processus de développement en Y de la méthode 2TUP [Roques, 2007a]
- 78 -
IV- Conclusion
Malgré ces avantages indéniables, l‟utilisation d‟UML pose certains problèmes. Ils
proviennent essentiellement de l‟absence d‟une sémantique précise pour les notations utilisées
.La sémantique est fondée sur un méta-modèle mais reste décrite en langage naturel. La
construction de système complexe conduit à des modèles UML ambigus et provoque de
nombreux problèmes d‟interprétation.
- 79 -
CHAPITREII
STATECHARTS
I- Introduction
II- Les diagrammes d’états transitions
III- Les diagrammes d’états- transitions
et les approches sémantiques
IV- Conclusion
- 80 -
I. Introduction
Les diagrammes d‟états-transitions d‟UML (II.1) décrivent le comportement interne
d‟un objet à l‟aide d‟un automate à états finis. Ils présentent les séquences possibles d‟états et
d‟actions qu‟une instance de classe peut traiter au cours de son cycle de vie en réaction à des
événements discrets (de type signaux, invocations de méthode). Ils s'inspirent principalement du
formalisme des statecharts proposé par David Harel.
Le diagramme d‟états-transitions est le seul diagramme, de la norme UML, à offrir une
vision complète et non ambiguë de l‟ensemble des comportements de l‟élément auquel il est
attaché.
Un objet peut passer par une série d‟états(II.2.1) pendant sa durée de vie. Un état
représente une période dans la vie d‟un objet pendant laquelle ce dernier attend un événement ou
accomplit une activité. La configuration de l‟état global de l‟objet est le jeu des états
(élémentaires) qui sont actifs à un instant donné.
Une transition(II.2.2) définit la réponse d‟un objet à l‟occurrence d‟un événement. Elle
lie, généralement entre deux états et indique qu‟un objet dans un état peut entrer dans l‟état et
exécuter certaines activités, si un événement déclencheur se produit et que la condition de garde
est vérifiée.
Un événement (II.2.3) est quelque chose qui se produit pendant l‟exécution d‟un système
et qui mérite d‟être modéliser. Les diagrammes d‟états-transitions permettent justement de
spécifier les réactions d‟une partie du système à des événements discrets. Un événement se
produit à un instant précis et est dépourvu de durée. Quand un événement est reçu, une transition
peut être déclenchée et faire basculer l‟objet dans un nouvel état. On peut diviser les événements
en plusieurs types explicites et implicites : signal, appel, changement et temporel, pour diminuer
la complexité des diagrammes de transition, plusieurs concepts avancés (II.2.4) ont été adapté
pour minimiser le nombre des états et des transitions.
Les diagrammes d‟états-transitions sont dotés d‟une syntaxe forte, mais elles souffrent de
certaines limitations (II.3).
- 81 -
Les diagrammes d‟états- transitions font l‟objet de plusieurs approches sémantiques de
formalisation afin d‟enrichir leur sémantique.
II. Les diagrammes d‘états transitions
II.1 Présentation :Les diagrammes d‟état transition (statecharts diagram), concept utilisé par
David Harel1 pour son extension de notation de machine d‟état à plat comprend des états
imbriqués et concurrents. Cette notation a servi de base à la notation de la machine UML.
Les diagrammes d‟états-transitions UML représentent en réalité des automates à états
finis, mathématiquement parlant, ils représentent des graphes orientés.
Le diagramme d‟états-transitions est le seul diagramme en UML qui offre une vision complète et
non ambiguë de l‟ensemble des composants de l‟élément auquel il est attaché [Audibert, 2006].
La figure 2.1exprime le protocole d‟états- machine.
Figure 2.1 : diagramme d‘états- transitions [Meyer ,2001]
1-http://www.wisdom.weizmann.ac.il/~harel/biography.html
- 82 -
II.2 Les concepts des diagrammes d‘états-transitions [Rumbaugh, 2005] [Grässle, 2005]
II.2.1 Les états (state) :
Un état est la condition d‟un objet à un moment donné [Larman, 2006], c'est une situation
donnée durant la vie de l‟élément qui satisfait à des conditions, réalise des actions ou est en
attente d‟événement. Cet état dépend des états précédents et des événements survenus.
Graphiquement, les états sont représentés sous forme de rectangles arrondis ; chaque état peut
posséder un nom qui le distingue des autres (le nom de l‟état est optionnel). Les états sans nom
sont anonymes et distincts les uns des autres. [Muller, 2001]
Les états sont caractérisés par deux choses différentes : la valeur des attributs de l‟objet
et la valeur des liens avec les autres objets à un instant donné.
Un diagramme d‟états-transitions est habituellement constitué d‟un état initial,
éventuellement des états intermédiaires (zéro ou plusieurs), et un ou plusieurs états finaux.
[Rumbaugh, 2005]
Un état peut être simple, ou composite ou de sous machine. Par définition un état
simple n‟a pas de sous état imbriqué, un état composite contient un ou plusieurs
régions, chaque (région) contient un ou plusieurs sous états. Si un état composite
est actif, chacune de ces régions est active.
Un état composite peut être non orthogonal ou orthogonal. Un état non
orthogonal possède une seule région. L‟état orthogonal modélise la concurrence.
La figure 2.2 extraite de [Erikson ,2004] présente le protocole d‟états machine.
- 83 -
Figure 2.2 : Protocole d‘états machine [Erikson ,2004]
Généralement un état est constitué de :
a. Nom : une chaine textuelle qui distingue l‟état d‟autres états (un état peut être
anonyme).
b. Sous état : si la machine -d‟états à une sous structure imbriquée, on l‟appelle état
composite. Un état composite contient une ou plusieurs régions, chacune contenant un
ou plusieurs sous états directs. Un état sans structure (à l‟exception des éventuelles
actions internes) est un état simple.
c. Activités entry et exit : un état peut avoir une activité « entry » et une activité « exit »,
l‟objectif de ces activités est d‟encapsuler l‟état de façon à ce qu‟il soit utilisable en
externe sans connaissance de sa structure interne. Elles représentent des actions à
exécuter à l‟entrée et à la sortie de l‟état.
d. Transition internes : un état peut avoir une liste de transitions internes (qui sont
comme des transitions normales mais qui n‟ont pas d‟état cible et ne provoquent pas de
changement d‟état).
- 84 -
e. Activité do interne : un état peut contenir une activité do interne décrite par une
expression. Lors de l‟entrée dans l‟état, l‟activité do commence après que l‟activité
entry est terminée.
f. Evénements rapportés : (déférés) c‟est une liste d‟événements qui ne sont pas traités
dans cet état mais qui sont sauvegardés dans une file d‟attente pour être traiter par
l‟objet dans d‟autres états.
g. Sous machine : le corps d‟un état peut représenter une copie d‟une machine d‟états
distincte référencée par son nom, appelée sous machine d‟état car elle est imbriquée
dans la machine d‟état étendu. Une sous machine peut être rattachée à une classe qui
fournit le contexte des actions qui s‟y trouvent comme les attributs qui peuvent être
lus ou écrits. Une sous machine peut être réutilisée dans plusieurs machines d‟états afin
d‟éviter la répétition du même fragment de machine d‟états. Une sous machine est une
sorte de sous routine de machine d‟état.
h. Etat initial / état final :
Etat initial (initial state) : pseudo état qui indique l‟état de départ par défaut de la
région enveloppée.
Etat final (final state) : pseudo état qui indique que l‟exécution du diagramme ou de
l‟état composite est terminé. La figure 2.3 désigne le formalisme de représentation des états
initial et final.
Figure2.3 : Formalisme de représentation des états initial et final [Gabay, 2008]
- 85 -
II.2.2 Les transitions (transition): c'est une relation entre deux états qui indique que
l‟objet change d‟état lorsqu‟un événement se produit. Sémantiquement, les transitions
représentent les chemins potentiels entre les états dans l‟historique de vie de l‟objet, ainsi que
les actions réalisés dans le changement d‟état.
Les diagrammes d‟états-transitions sont des graphes dirigés, les états sont reliés par des
connexions unidirectionnelles, appelées transitions.
Pour la structure, une transition possède un état source, un déclencheur d‟événement,
une condition de garde, une action et un état cible, certains éléments peuvent ne pas figurer.
Généralement, une transition est constituée de :
a. Etat source : l‟état source est l‟état affecté par la transition. Si un objet se trouve dans
l‟état source, une transition sortante de l‟état peut se déclencher si l‟objet reçoit
l‟événement déclencheur de la transition de garde ( soit satisfaite ), l‟état source devient
inactif après le déclenchement de la transition.
b. Etat cible : l‟état cible est l‟état qui devient actif après l‟achèvement de la transition.
c. Déclencheur d‟événement (event trigger): c‟est un événement reconnu par l‟état source
et avec lequel la transition est franchissable une fois que la garde de la transition est
vérifié. Un événement peut être un signal, un appel de méthode, un passage de temps ou
un changement d‟état.
d. Condition de garde : la condition de garde est une expression booléenne qui est évaluée
lorsque la gestion d‟un événement déclenche une transition spécifiée par „[„ <garde>‟]‟,
syntaxiquement il s‟agit d‟une expression logique sur les attributs de l‟objet, la transition
ne se déclenche qu‟une fois que la condition de la garde est évaluée « true ».
e. Effet : une transition peut contenir un effet, c'est-à-dire une action ou une activité qui
s‟exécute lorsque la transition se déclenche. Le comportement peut accéder à l‟objet
détenteur de la machine d‟états et le modifier (ainsi qu‟indirectement d‟autres peuvent
utiliser d‟autres objets qu‟il peut atteindre). L‟effet peut utiliser des paramètres de
l‟événement déclencheur, ainsi que des attributs et des associations de l‟objet déteneur.
On peut accéder à l‟événement déclencheur comme étant l‟événement en cours pendant
- 86 -
toute la durée de l‟étape run-to-completion, qu‟il a initié, y compris les segments
dépourvus de déclencheurs et actions entry et exit .
On suppose qu‟un effet a une durée de vie assez brève car la machine d‟états ne peut
pas traiter d‟autres événements tant que son exécution n‟est pas achevée. Tout comportement
destiné à poursuivre pour une durée étendue doit être modélisé comme une activité do associé
à un état plutôt qu‟a une transition. Le tableau suivant illustre les types et les effets implicites.
Le tableau 2.1 résume les différents types de transition et effets implicites.
- 87 -
Type de transition description Syntaxe
Transition entry
Transition exit
Transition externe
Transition interne
Spécification d‟une activité
d‟entrée qui s‟exécute lorsqu‟on saisit
un état
Spécification d‟une activité
de sortie qui s‟exécute lorsqu‟on
quitte un état
Réponse à un événement qui
engendre un changement d‟état ou
une auto transition, ainsi qu‟un effet
spécifié. Elle peut également
entrainer l‟exécution d‟une activité
exit et/ou d‟une activité entry pour
les états dont l‟on sort ou dans
lesquels on entre.
Réponse à un événement
qui entraine l‟exécution d‟un effet
mais pas d‟un changement d‟état, ou
l‟exécution d‟activités exit ou entry
Entry/activity
Exit /activity
(a :T)[guard]/activity
e (a : T) [guard]/activity
Tableau2.1 : Type de transition et effets implicites [Rumbaugh, 2005]
- 88 -
II.2.3 Les événements:
Un événement est une occurrence d‟un fait significatif ou remarquable. Un événement
correspond à l‟occurrence d‟une situation donnée dans le domaine du problème. Contrairement
aux états qui durent, un événement est par nature une information instantanée qui doit être
traitée sans délai. Un événement peut déclencher le passage d‟un état à un autre.
Les transitions indiquent les chemins dans le graphe des états, par contre les
événements déterminent quels chemins doivent être suivis. Les événements, les transitions et les
états sont indissociables dans la description du comportement dynamique. Fonctionnellement, un
objet placé dans un état donné attend l‟occurrence d‟un événement pour passer dans un autre
état. La réception de l‟événement par l‟objet conduit au déclenchement de la transition. L‟objet
qui était dans un état source passe dans l‟état destination de la transition. De ce point de vue,
les objets se comportent comme des éléments passifs, contrôlés par les événements en
provenance de système. La figure représente un événement qui déclenche une transition.
Événement
La définition compète d‟un événement comprend :
- Le nom d‟événement.
- La liste des paramètres éventuels.
- L‟objet expéditeur.
- L‟objet destinataire.
- La description de la signification de l‟événement.
Différents types sont définis dans UML, rappelons :
a. Evénement signal : il est causé par la réception d‟un signal. Un signal est une
spécification d‟un stimulus asynchrone entre deux instances. L‟envoi d‟un signal
déclenche une réaction asynchrone au niveau de l‟instance destinataire de manière
A B
- 89 -
asynchrone, sans réponse à l‟instance source ; contrairement à l‟invocation d‟une
opération qui peut être synchrone ou asynchrone, avec ou sans réponse.
b. Evénement d‟appel : un événement d‟appel représente la réception de l‟appel d‟une
opération par un objet. La classe destinataire choisit d‟implémenter une opération
comme une méthode ou comme un déclencheur d‟événement d‟appel dans une machine
d‟état (ou éventuellement les deux). Les paramètres de l‟opération sont des paramètres
de l‟événement d‟appel. Une fois que l‟objet destinataire a traité l‟événement d‟appel
en empruntant une transition déclenchée par l‟événement ou pas, le contrôle retourne à
l‟objet appelant. Contrairement à une méthode, la transition d‟une machine d‟états
déclenchée par un événement d‟appel peut continuer de s‟exécuter en parallèle de
l‟appelant. En général, un événement appel est causé par la réception d‟un appel
d‟opérations. Les événements de création et de destruction d‟objet sont deux événements
d‟appel spéciaux.
c. Evénement de changement : un événement de changement est la satisfaction d‟une
expression booléenne qui dépend de valeurs d‟attributs désignées. Il s‟agit d‟une
manière déclarative d‟attendre qu‟une condition soit satisfaite, dite encore événement de
modification exprimé par une expression booléenne et émis dés que l‟expression passe de
faux à vrai suite à un changement de valeurs d‟un ou de plusieurs attributs ou une
modification de liens. L‟événement persiste même si l‟expression repasse à faux.
d. Evénement temporel : représente le passage du temps, on les spécifie soit en mode absolu
(spécification d‟une date ou d‟une heure), soit en mode relatif (spécification d‟un délai
après apparition d‟un événement). Dans un modèle de haut niveau, les événements
proviennent du monde extérieur, mais dans un modèle d‟implémentation ils sont
provoqués par des signaux émanant d‟un objet spécifique (comme un système
d‟exploitation ou un objet application). Le tableau suivant résume les types
d‟événements. Le tableau2.2 synthétise les différents types d„événements.
- 90 -
Type d‘événement Description Syntaxe
Appel
Changement
Signal
Temps
Réception d‟une demande
d‟appel explicite synchrone par un
objet
Changement dans la valeur
d‟une expression booléenne
Réception d‟une
communication explicite, nommé
asynchrone entre des objets
Arrivée d‟un temps absolu
ou passage d‟un laps de temps relatif
Op ( a :T)
When (exp)
sname ( a :T)
after (time )
Tableau2.2: Types d‘événements [Rumbaugh, 2005]
- 91 -
La figure 2.4 extraite de [Grässle, 2005] illustre les éléments de statechart diagram
(diagramme d‟états-transition).
Figure2.4 : les éléments de statechart diagram (diagramme d‘états-transitions) [Grässle,
2005].
II.2.4 Les concepts avancés :
Les diagrammes d‟états transitions utilisent plusieurs concepts avancés afin de modéliser
les comportements complexes, afin de diminuer le nombre des états et des transitions et afin de
réduire la complexité des diagrammes d‟états transitions.
Activités d‟entrée /sortie : un état peut avoir une activité entry et une activité exit.
L‟objectif est d‟encapsuler l‟état de façon qu‟il soit utilisable en externe sans
connaissance de sa structure interne. Une activité entry est exécutée lors de l‟entrée
dans l‟état (après toute activité rattaché à la transition entrante et avant toute activité do
interne). Une activité exit a lieu lors de la sortie de l‟état (après l‟achèvement de toutes
les activités do internes et avant toute activité rattachée à la transition sortante).
- 92 -
Les activités d‟entrée/sortie généralement ne possèdent pas d'arguments ou de
conditions de garde. Toutefois, l‟activité d‟entrée pour le premier état dans le diagramme
d‟états- transitions peut avoir des paramètres pour les arguments reçus lors de la création de
l‟objet.
Transitions internes : pour des raisons de modélisation, on est mené à exploiter le concept
« transition interne », un état peut avoir une liste de transitions internes qui
ressemblent aux transitions normales, mais qui n‟ont pas d‟états cible et qui ne
provoquent pas de changement d‟état. Leur événement se produit pendant qu‟un objet se
trouve dans l‟état détenant la transition ou dans l‟un de ses sous-états imbriqués, alors
l‟action de la transition interne s‟exécute, mais il n‟ya pas de changement d‟état et aucune
activité entry ou exit ne s‟exécute.
Activité do : un état peut contenir une activité do décrite par une expression donnée,
lorsque un objet est en état donné, il reste généralement en attente de l‟arrivée des
événements, mais parfois, on voudra accomplir des activités à ce moment jusqu'à ce
que l‟événement apparaisse. UML2 utilise le mot clé « do » pour spécifier les activités
jusqu'à ce que l‟événement apparaisse. Chronologiquement, lors de l‟entrée dans l‟état,
l‟activité do commence après que l‟activité entry est terminée, l‟état est à terme. Une
transition d‟achèvement se déclenche alors et quitte l‟état. Sinon, l‟état attend une
transition déclenchée pour provoquer le changement d‟état. Si une transition se
déclenche pendant que l‟activité do est en cours, cette dernière est interrompue et
l‟activité exit de l‟état s‟exécute.
Evénements différés : les événements différés sont des événements qui ne sont pas traités
par l‟objet dans cet état, mais plutôt ces événements seront gardés dans une file d‟attente
pour les traiter par l‟objet dans d‟autres états.
UML utilise l‟action « différer » pour définir des événements différés ; c‟est à dire des
événements qui, s‟ils ne déclenchent pas de transition lors de leur occurrence, ne sont pas
perdus mais mémorisés dans une file d‟attente jusqu'à ce qu‟ils soient acceptés ou que
l‟automate soit dans un état ou ils ne sont plus différés (alors dans ce cas, les événements sont
perdus).
- 93 -
Sous machine : le corps d‟un état peut représenter une copie d‟une machine d‟état
distincte référencée par son nom. Cette dernière est appelée « sous machine », en
anglais sub-machine, car elle est imbriquée dans la machine d‟états plus étendue. La
sous machine est prévue pour être réutilisée dans plusieurs machines d‟états afin d‟éviter
la répétition du même fragment de machine d‟état. Une sous machine est une sorte de
machine d‟état.
Sous état : les diagrammes d‟états-transitions deviennent illisibles du fait de l‟explosion
combinatoire, le nombre de connexions entre états est élevé, la solution adoptée pour
maîtriser cette situation est l‟utilisation des états composites. Un état composite (ou état
englobant) est décomposé en sous états.
Un sous état est un état imbriqué dans un autre état. Chaque sous état peut également
être un composite, c‟est-à-dire décomposé en d‟autres sous états imbriqués à un niveau
hiérarchique inférieur. Les sous états sont des sous états concurrents (orthogonaux) et/ou des
sous états séquentiels (non orthogonaux).
Sous état séquentiel : un état composite est composé d'une ou plusieurs régions, chacune
peut contenir un ou plusieurs états. Un état composite possédant une seule région est
dit état séquentiel (non concurrent, non orthogonal), généralement la région
séquentielle contient un état initial et un état final.
Sous état orthogonal : le concept état orthogonal permet de présenter efficacement le
mécanisme de concurrence. Un état orthogonal est un état composite contenant plus
d‟une région, chaque région représente un flot d‟exécution. Graphiquement, dans un
diagramme d‟états-transitions les différentes régions sont séparées par un trait en
pointillé allant du bord gauche au bord droit de l‟état composite. Un état peut être
composé de plusieurs sous états concurrents (appelés régions). Cette composition est de
type conjonctive (et), ce qui implique que l‟objet doit être simultanément dans tous les
sous–états. La conjonction d‟états représente une forme de parallélisme entre automates.
Etat historique (history state) : un état historique permet à un état composite de se
souvenir de son dernier sous état actif avant son exit le plus récent. Un état historique
permet de conserver un historique plat (shallow history) ou un historique profond (deep
history). L‟historique plat se souvient et réactive un état situé à la même profondeur
- 94 -
d‟imbrication que l‟état historique lui-même. L'historique plat est représenté par un petit
cercle contenant la lettre H. L‟état historique profond se souvient d‟un état qui a pu
être imbriqué à une certaine profondeur de l‟état composite. Il est représenté par la lettre
H*.
Pour résumer un état simple ne possède pas de sous structure mais uniquement un jeu
de transitions et éventuellement des activités entry et exit. Un état composite est un état
décomposé en régions contenant un ou plusieurs états, le tableau décrit les différents types de
sous états. Le tableau 2.3 récapitule les différents types d‟états.
- 95 -
Type état description Notation
Etat simple Etat dépourvu de sous structure
Etat orthogonal
Etat divisé en deux régions ou plus,
un sous état direct de chaque
région est simultanément actif
avec l‟état composite lorsque ce
dernier est actif
Etat non orthogonal
Etat composite contenant un ou
plusieurs sous état directs ; un seul
d‟entre eux est exactement actif à
la fois lorsque l‟état composite est
actif
Etat initial
Pseudo –état, qui indique l‟état de
départ lorsque l‟état enveloppant
est invoqué
Etat final
Eta spécial dont l‟activation
indique que l‟état enveloppant est
terminé
Terminaison
Etat spécial dont l‟activation
achève l‟exécution de l‟objet de la
machine d‟états.
Jonction
Pseudo–état qui relie des segments
de transition en une seule
transition de type RTC (run–to-
completion)
choix
Pseudo état qui crée un
embranchement dynamique dans
une transition de type RTC
S
S
S
- 96 -
Etat historique
Pseudo état dont l‟activation
restaure l‟état précédemment actif
dans un état composite
Etat de sous -machine
Etat qui indique une
définition de machine d‟états qui
remplace conceptuellement l‟état
de sous machine.
Point d‟entrée
Pseudo–état visible de
l‟extérieur dans une machine
d‟états qui identifie un état interne
comme cible
a
Point de sortie
Pseudo état visible de
l‟extérieur dans une machine
d‟états qui identifié un état interne
comme une source
b
Tableau 2.3 : Types d‘états [Rumbaugh ,2005] [Pilone ,2005]
Tous les formalismes d‟états machine, y compris les statecharts d‟UML, universellement,
assument que les machines d‟états complètent le traitement de chaque événement avant de
commencer le traitement d‟événement suivant. Ce modèle d‟exécution s‟appelle run-to-
completion ou RTC [Samek, 2009].
Point de choix : pour représenter des alternatives pour franchir d‟une transition. UML2
offre des pseudos états particuliers : les points de jonction (graphiquement représentés
par un petit cercle plein), et les points de décision (représentés graphiquement par
losange, voir figure 2.5.).
H
S : M
T
U
- 97 -
Figure2.5: point de choix [Kimmel ,2005]
Point de jonction : les points de jonction sont des pseudo états permettant de partager
des segments de transition, afin d‟aboutir à une notation plus compacte ou plus lisible
des chemins alternatifs. Un point de jonction peut avoir plusieurs segments de
transition entrante et plusieurs segments de transition sortante (voir la figure 2.6).
Figure2.6 : exemple d‘état-transition avec point de jonction [Gabay, 2008]
Point de décision : un point de décision est un pseudo état qui possède une entrée et au
moins deux sorties. Dans un point de jonction les gardes localisées après le point de
décision sont évaluées au moment où il est atteint. Le choix est basé sur les résultats
obtenus en franchissant le segment avant le point de choix dans une point de décision
on peut utiliser une garde particulière, notée [else], sur un segment en aval d‟un point
- 98 -
de choix. Ce segment n‟est franchissable que si les gardes des autres segments sont
toutes fausses. Afin de garantir un modèle bien formé, il est recommandé d‟utiliser la
classe [else].
La transition complexe (complex transition) : une transition complexe modélise la
synchronisation de contrôle et/ou le débranchement de contrôles selon le nombre de
sources et de cibles. Une transition complexe est une transition à partir ou vers un état
orthogonal. Une transition complexe possède plusieurs états source et/ou plusieurs
états cibles.
- Si elle possède plusieurs états source, elle représente une jointure de contrôle.
- Si elle possède plusieurs états cibles, elle représente un débranchement de
contrôle.
- Si elle dispose plusieurs états source et cible, elle représente une synchronisation
de threads parallèles.
La transition complexe est représentée graphiquement par une barre épaisse et courte.
Pour élaborer le diagramme d‟états- transition, Les auteurs de [Roques, 2005] et
[Roques, 2007] proposent une approche incrémentale fondée sur les étapes suivantes :
- Représenter d‟abord la séquence d‟états décrivant le comportement nominal
d‟un objet, de sa naissance à sa mort, avec des transitions associés.
- Ajouter progressivement les transitions correspondant aux comportements
« alternatifs» ou d‟exception ;
- Intégrer, de la même manière, celles concernant les comportements d‟erreur.
- Compléter les effets sur les transitions et les activités dans les états.
- Structurer le tout en sous-états et utiliser les notations avancées (entry, exit,
etc.)si le diagramme devient trop complexe.
II.3 Les limitations des diagrammes d‘états transition [Samek, 2009] :
Les Statecharts ont été inventés comme « formalisme visuel pour les systèmes
complexes » [Harel, 1987]. Ainsi dès leur apparition, ils ont été inséparablement associés à une
représentation graphique sous forme de diagrammes d'état. Cependant, il est important de
comprendre que le concept de HSMs [Hierarchical State Machine] dépasse n'importe quelle
- 99 -
notation particulière, graphique ou textuelle. Les spécifications d'UML [OMG, 2007a] rendent
cette distinction évidente en séparant clairement la sémantique de machine d'état de la notation.
Cependant, la notation des Statecharts d'UML n'est pas purement visuelle. N'importe
quelle machine d'état non triviale exige un grand nombre d'information textuelle (par exemple,
les spécifications des actions et des gardes).
La syntaxe exacte des expressions d'action et de garde n'est pas définie dans les
spécifications d'UML, ainsi beaucoup de personnes emploient l'anglais structuré ou, plus
formellement, des expressions en langue d'exécution telle que C, C++, ou Java. Dans la pratique,
ceci signifie que la notation de statechart d'UML dépend largement du langage de programmation
spécifique.
Néanmoins, la majeure partie de la sémantique de statecharts est fortement concentrée
vers la notation graphique. Par exemple, les diagrammes d'état représentent mal l'ordre du
traitement, que ce soit l'ordre de l'évaluation des gardes ou l'ordre d'expédier des événements aux
régions orthogonales. Même, les diagrammes de statecharts exigent beaucoup de vitesse (les
pseudo-states, comme point de choix, point de jonction, etc.) pour représenter l'ordre d'exécution
graphiquement.
Ce n'est pas de critiquer la notation graphique des statecharts. En fait, il est
remarquablement expressif et peut à peine être amélioré. En revanche, il faut simplement
préciser les points faibles et les limitations des diagrammes statecharts.
La notation et la sémantique d'UML sont vraiment adaptées vers la conception
automatisée.
En utilisant des outils d'automation, une machine d'état d'UML, comme représentée dans
un outil, n'est pas simplement le diagramme d'état, mais plutôt un mélange de représentations
graphique et textuelle qui capturent avec précision la topologie d'état et les actions. Les
utilisateurs de l'outil peuvent obtenir plusieurs vues complémentaires de la même machine d'état,
visuelle et textuelle, tandis que le code produit est juste un des nombreuses vues disponibles.
- 100 -
III. Les diagrammes d‘états transitions et les approches sémantiques :
La formalisation des machines d‟états peut être spécifiée en plusieurs méthodes :
Mathématiques, non-mathématiques, textuelles, graphiques, Théoriques vs. Application pratique,
etc. L‟article [Crane, 2005] discute une classification basée sur le type de la sémantique. Cette
formalisation a pour objectif d‟enrichir les machines d‟états UML par une sémantique précise
non ambigüe qui permet par conséquence la vérification formelle des diagrammes d‟états-
transitions. La figure extraite de [Crane, 2005] schématise la catégorisation des approches
sémantiques des diagrammes d‟états-transitions, qui comportent trois grandes catégories divisées
des sous- catégories.
Figure 2.7 : Catégorisation des approches sémantiques du diagramme d'états-
transitions [Crane, 2005]
- 101 -
III.1 Les Modèles Mathématiques (Models Mathimatical)
Cette catégorie comporte les approches sémantiques qui sont basées directement sur des
concepts et des notions mathématiques standard. L'avantage d'appliquer une notation
mathématique est qu‟elle favorise la précision et la description détaillée, qui produit une
sémantique complète, précise et non ambiguë. En principe au moins, la notation devrait être
accessible à n‟importe quel utilisateur ayant des notions de base en mathématiques. Cependant,
il s'avère que la plupart des approches de cette catégorie échouent pour fournir un niveau élevé
d‟abstraction, correctement comprise par des utilisateurs [Varro, 2002].
Cette catégorie est subdivisée en sous-catégories à savoir :
III.1 .1 Les Systèmes de Transitions (transition system) :
Les systèmes de transition [Manna, 1991] permettent d‟élaborer des modèles de
comportement .Ils sont basés sur la définition d‟un espace d‟états et de transitions qui permettent
le passage d‟un état à un autre .Chaque état représente un état du système, c‟est à dire une
interprétation des variables du système .Avec un système de transition, on définit
naturellement une sémantique opérationnelle. En effet, le système est décrit en terme de
changements d‟états .Dans une optique d‟expression de propriétés d‟un système spécifié par
un système de transitions on utilise généralement la logique temporelle .
Un Système de transitions étiqueté (LTS) (Labelled Transition System) est défini en
termes d‟états et transitions étiquetées entre états, où les étiquettes indiquent le comportement
produit durant la transition. Formellement :
Définition 2.1 : (LTS) : Un LTS 234
est un quadruplet (Q, q0,Σ,→) tel que :
- Q est un ensemble dénombrable d‟états,
2- A. Arnold. Systèmes de transitions finis et sémantique des processus communicants.
Masson, 1992. 3- A. Arnold. Finite Transition Systems: Semantics of Communicating Systems, International Series in
Computer Science. Prentice-Hall International, Englewood Cliffs, NJ, 1994 4- E. Brinksma and J. Tretmans, "Testing transition systems : an annotated Bibliography", In the proceeding
of Modelling and Verification of Parallel Processes (MOVEP2k),
LNCS 2067, pp. 187-195. Springer- Verlag, 2000.
- 102 -
- q0 ∈ Q est l‟état initial,
- Σ est un alphabet dénombrable d‟actions,
- →⊂ Q×Σ∪ {τ}×Q est un ensemble de transitions. Un élément (s, a, s_) de → sera
Simplement noté : s a s‟.
En général, un système de transition est un graphe dont les nœuds symbolisent les états
et les arêtes symbolisent les transitions entre ces états. Il y‟a plusieurs types de systèmes de
transition, comprenant : les systèmes de transition libellées (LTS : Labled Transition System), la
structure de Kripke et les systèmes de transitions symboliques.
III.1 .2 Les machines d'état abstraites (Abstract State Machines) :
Dans ce modèle, le système est représenté par son état et un ensemble d‟opérations qui
modifient et agissent sur cet état. Chaque opération permet d‟accomplir une transition entre les
états que peut prendre le système. Plusieurs méthodes formelles utilisent ce formalisme.
Les ASMs (Abstract State Machines) sont l‟une d‟entre elles. L‟histoire et l‟origine du
développement des ASMs sont discutées par Börger dans un article [Börger, 2002] où il décrit
l‟évolution des ASMs depuis leur conception jusqu‟à leur mise en œuvre dans des cas industriels
particuliers. Présentées par Gurevich [Gurevitch, 1993a], les ASMs sont une tentative de
combiner les modèles formels et les méthodes de spécifications pratiques. Une machine abstraite
en ASM est constituée d‟un système fini de transitions d‟états. Chaque transition d‟état est une
règle modifiant un état pour obtenir un nouvel état. Ces règles de transitions contiennent une
garde et des fonctions de mise à jour. Ainsi, si une règle peut s‟appliquer, c‟est-à-dire que sa
garde est vérifiée, alors la clause relative à la transition est exécutée de manière atomique.
L‟exécution de cette clause met à jour l‟état du système et le processus continue. Il se
peut, dans certains cas, que plusieurs règles soient éligibles en même temps. Dans cette condition,
une règle parmi celles éligibles est choisie de façon non déterministe. L‟état du système est
constitué d‟une collection de noms représentant diverses parties du système. La mise à jour de
l‟état consiste à assigner des valeurs à ces noms ou à en modifier la valeur.
- 103 -
Le formalisme des ASMs combine deux perspectives des processus de calcul : les
méthodes de spécifications et les modèles de calcul. C‟est une méthodologie simple, permettant
de décrire des machines abstraites représentant des algorithmes [Börger, 1995]. Selon Gurevich
[Gurevitch, 1993b], tous les processus de calcul peuvent être modélisés avec des algèbres
évolutives. Ils sont au moins aussi expressifs que les machines de Turing [Turing, 1936]. Le
privilège des ASMs est de pouvoir être utilisé à la fois comme langage de spécification et
comme langage de programmation. En effet, elles peuvent être exécutées si les ensembles et les
fonctions exprimées sont calculables.
Une machine d'état abstraite (ASM) se compose fondamentalement d'un ensemble des
états et une règle de mise à jour itérativement appliquées [JÄurjens, 2002].
Les ASMs peuvent être employées pour la description opérationnelle des algorithmes
[Jin, 2004]. Bien que les ASMs puissent être considérées comme des systèmes de transition
[BÖrger, 2000], les auteurs de [Varro, 2002] différencient les deux formalismes.
La syntaxe des ASMs est analogue à un simple langage de programmation déclaratif qui
rend la machine accessible aux utilisateurs ayant un background de base en programmation.
L‟analyse des ASMs est également possible avec le même support.
III.1.3 Les Réseaux de Petri (Petri Nets):
Les réseaux de Pétri proposent un formalisme bien étudié et intuitif qui est à la fois
graphique et mathématique applicable sur plusieurs systèmes [Tadao, 1989]. Les PNs [Wu,
2010] ont été présentés par Carl Adam Pétri en 1962 pour synchroniser des automates de la
communication, et ont été alors prolongés pour définir un grand ensemble de modèles, avec
l'augmentation de la complexité et des possibilités [Diaz, 2009]. La définition formelle des
réseaux de Petri est la suivante :
Définition 2.2 : (Réseau de Petri56
places/transitions). Un réseau de Petri places/transitions
R est un triplet (P,T,W) défini par la donnée :
5 [Diaz, 2001] Diaz M. Les Réseaux de Petri : modèles fondamentaux. Hermes, Paris. 2001.
- 104 -
- D‟un ensemble fini non vide de places P = {p1, . . . , pm}, où |P| est le nombre de places ;
- D‟un ensemble fini non vide de transitions T = {t1, . . . , tn}, où |T| est le nombre de
transitions, avec P ∩ T = ∅ ;
- d‟une relation d‟incidence W : P × T ∪ T × P → N correspondant aux arcs :
◦ W(p, t)p∈P, t∈T contient la valeur entière associée à l‟arc allant de p à t ;
◦ W(t, p)p∈P, t∈T contient la valeur entière associée à l‟arc allant de t à p ;
◦ dans le cas où une place p n‟est pas reliée à la transition t, on a simplement W(t, p) = 0
et W(p, t) = 0.
Un réseau de Petri est également un langage de modélisation représenté sous forme d‟un
graphe biparti orienté composé de nœuds appelés places et transitions, connectés grâce à des arcs
orientés pondérés. Une place correspond à une variable d‟état du système qui va être modélisé et
une transition à un événement et/ou actions qui vont entraîner l‟évolution des variables d‟états
du système. A un instant donné, une place contient un certain nombre de jetons qui va évoluer en
fonction du temps: il indique la valeur de la variable d‟état à cet instant. L‟évolution d‟un RdP
correspond à l‟évolution de ses jetons au cours du temps (évolution de l‟état du système) : il se
traduit par un déplacement des jetons ce qui s‟interprète consommation/production de ressources
déclenchées par les événements ou les actions.
Les réseaux de Petri fournissent un ensemble d‟outils qui permet à la fois la spécification
fonctionnelle, la modélisation et l‟évaluation des systèmes de production.
Comme il existe diverses extensions pour différents domaines tels que les RDP
stochastique pour l‟analyse des performances. De nombreux outils d‟édition et d‟analyse des
RdPs sont disponibles. [Merseguer, 2002], la figure 2.8 extraite de [Diaz, 2009] résume les
principaux modèles de Petri Nets.
6 [Diaz, 2003] Diaz, M. (2003). Vérification et Mise en œuvre des réseaux de Petri. Hermes Science, Traite IC2
Information-Commande-Communication.
- 105 -
Figure 2.8 : Les principaux modèles de Petri Nets [Diaz, 2009]
III.1 .4 Autres Approches Mathématiques :
Cette sous-catégorie renferme d'autres approches mathématiques qui ne se servent pas ni
des systèmes de transition, ni d'ASMs, ni des réseaux de Pétri. Par exemple, Les approches qui
incluent les représentations Co-algébriques et les formalismes à base d‟ensembles-relations.
III.2 Les Systèmes de Réécriture (rewriting system) :
Les systèmes de réécriture figurent parmi les formalismes les plus généraux de
l‟informatique pour la modélisation de transformations sur les mots ou les termes ou les graphes.
Consulter [Dershowitz, 1990].
Les systèmes de réécriture sont des équations orientées employées pour calculer en
remplaçant à plusieurs reprises des subterms d'une formule donnée par des termes égaux jusqu'à
ce que la forme la plus simple possible soit obtenue. Les systèmes de réécriture ont fait leur
début dans l‟article [Gorn, 1967].
- 106 -
Un système de réécriture inclut un ensemble de règles de réécriture où chaque règle est
constituée d‟une partie gauche et d‟une partie droite. Le système de réécriture est exécuté par
l‟application des règles de réécriture à une configuration donnée. Durant l‟exécution de la
grammaire (les règles du système de réécriture) dans un ordre prédéfini, la partie gauche dans une
configuration est remplacée par la partie droite de la règle appliquée. L‟exécution se termine
lorsqu‟aucune des règles ne peut être appliquée. Les systèmes de réécriture peuvent être
considérés en tant que modèles mathématiques. [Varro, 2002].Mais les auteurs de [Crane, 2005]
les considèrent comme une catégorie séparée. Cette catégorie englobe les types suivants : [Meyer,
2005]
III.2 .1 La réécriture de mots :
Un système de réécriture de mots sur l‟alphabet ∑ est un ensemble potentiellement
infini de règles de réécriture, c‟est à dire de couples de mots (l, r) ∈ ∑*×∑*. On note Dom(R)
(resp. Im(R)) l‟ensemble des parties gauches et droites de règles de R. Une règle (l,r) réécrit un
mot w en w′ en remplaçant une instance de l dans w par r. Plus formellement, la relation de
réécriture d‟un système R est
: = {(ulv,urv) | (l,r) ∈ R ∧u,v ∑∗}.
R
III.2 .2 La réécriture des termes :
Les systèmes de réécriture de termes peuvent être définis de façon similaire aux systèmes
de mots : un système de réécriture de termes sur un alphabet gradué F est composé d‟un ensemble
potentiellement infini de règles (l,r) où l et r sont des termes de T(F,X) tels que Var (r) ⊆ Var (l)
⊆ X (X est un ensemble de variables supposé disjoint de F). Nous considérons explicitement des
ensembles de règles fermés par renommage des variables de X, de façon à ce que les règles qui
ne diffèrent que par le nommage de leurs variables puissent être considérées identiques. La
relation de réécriture d‟un tel système doit être définie par substitution de façon à prendre en
compte le fait que les règles de réécriture peuvent modifier la structure des termes, échanger des
branches, dupliquer ou supprimer des sous-termes et ainsi de suite.
- 107 -
La relation de réécriture d‟un système R est
:= {(c[lσ],c[rσ]) ∈ T(F) × T(F) | (l,r) ∈ R ∧ c ∈ C1(F) ∧σ∈ S(F,X)}.
R
Les systèmes de réécriture de termes peuvent être définis de façon similaire aux systèmes
des graphes à l‟exception que les règles de réécriture sont appliquées sur des termes au lieu des
graphes. Dans le contexte d‟une machine d‟états, un terme représente une configuration
(l‟exemple d‟un ensemble d‟états actifs). Les règles de réécriture décrivent la relation entre les
termes (les transitions entre les états).
III.2 .3 La réécriture des graphes : [Rozenberg, 1997] [Engelfriet ,1997] [Ehrig ,1990]
La réécriture de graphes, appelé aussi transformation des graphes est un mécanisme pour
transformer des graphes d'une manière mathématique rigoureuse. Ce formalisme a été introduit à
la fin des années 60 pour traiter des problématiques telles que la construction de compilateurs ou
la spécification des types de données.
Elle, fournit une technique de spécification mathématique précise et visuelle. En
combinant les avantages des graphes et des règles en un seul paradigme de calcul [Varro, 2002].
Actuellement, ces techniques établissent la base formelle pour la résolution de problèmes
liés à des domaines d'application par exemple : l‟identification faciale [Wiskott
,1997[Kotropoulos, 2000] la reconnaissance d'objets [Bunke, 2000] [Nasrabadi ,1991], la
reconnaissance de symboles [Llados ,2003], et l'identification de caractères et la graphologie
[Lu, 1991].
Dans la théorie, il y a principalement deux aspects de la réécriture de graphes : les
grammaires de graphes et la transformation de graphes. Les mécanismes et les approches de
réécriture sont identiques dans les deux cas mais la différence réside dans leur finalité. On parle
généralement de productions de grammaire dans le premier cas et de règles de transformation
dans le second. Pour préciser la différence entre les deux, on peut dire que les grammaires de
- 108 -
graphes suivent et préservent la même logique que les grammaires génératives ("generative
grammars") de Chomsky [Chomsky, 1956]. Le profit s‟oppose sur l'ensemble des graphes
produits suite à l'application d'un ensemble de productions à partir d'un graphe de départ donné.
Si on se concentre sur les transformations elles-mêmes comme processus de calcul, nous parlons
alors de transformation de graphes.
On fera la différenciation suivante, dans le cas des grammaires de graphes, on distingue
entre les nœuds terminaux et non terminaux. Les applications successives des productions de
grammaire permettent le passage d'un graphe intermédiaire (contenant des non terminaux) vers
un autre graphe intermédiaire (contenant encore des non terminaux) jusqu'à atteindre un graphe
final (ne contenant plus de non terminaux).
Dans le cas de la transformation de graphes, les nœuds sont tous du même type (tous des
terminaux) et l'application d'une règle de transformation a pour but le passage d'un graphe
représentant par exemple l'état courant d'un système vers un autre graphe représentant son nouvel
état.
III.3 Les Approches de translations
Cette catégorie combine les approches qui concentrent sur la translation des machines
d‟états d‟UML à des spécifications formelles par l‟emploi des langages de spécification ou des
langages d‟entrée aux model-checkers ...etc. Ces approches s‟occupent de plus de l‟analyse et la
vérification automatique du comportement représenté par la machine d‟état d‟UML.
III.3 .1 Langages de Model-Checking : La vérification par modèle, ou Model-checking,
Les méthodes formelles, telles que la preuve (automatique ou assistée) de théorème ou le
modèle checking, s'appuient quant à elles sur un cadre mathématique précis et non ambigu
permettant de modéliser à la fois le système et les propriétés qu'il doit vérifier, tout en proposant
des algorithmes de vérification de ces propriétés.
Les premiers travaux sur le model checking sont attribuées à Edmund Clarke [Clarke,
1981] [Clarke, 2007] [Grumberg, 2008] Joseph Sifakis [Queille, 1982] qui ont reçu le prix
Turing en 2007 pour leurs contributions dans ce domaine.
- 109 -
Le model checking a été défini à l'origine pour vérifier des propriétés des systèmes
concurrents. Le système à vérifier est représenté par un système de transition d'états et la
propriété à vérifier est exprimée en logique temporelle.
La démarche du model checking est la suivante : [ALUR, 1990] [Clarke, 1986]
Construction d'un modèle ∑ du système S ;
Formalisation de la propriété P (donnée par exemple en langage naturel) dans une
logique adaptée pour obtenir un modèle ɸ de P ;
Utilisation d'un algorithme d'exploration partielle ou exhaustive de l'espace d'états Afin de
vérifier si ∑ satisfait ɸ .
L‟auteur de [Lamport, 1977] classe généralement les propriétés comportementales en
deux catégories principales :
- Sûreté (safety) : Un comportement mauvais ne se produira jamais ;
- Vivacité (liveness) : Un comportement bon finira toujours par se produire.
La propriété d'équité (fairness) est un cas particulier de la vivacité : elle stipule qu'un
comportement bon, sollicité un nombre infini de fois, pourra se produire un nombre infini de fois.
[Zeitoun, 2010], récapitule les avantages et les inconvénients du model checking :
- Le model checking est complètement automatique.
- Pas de comportement „‟ oublie „‟. Si le model checker valide un système, ce système
est correct vis-à-vis de la propriété vérifiée.
- Lorsque les propriétés requises ne sont pas satisfaites, les logiciels de model checking
exhibent une trace du système non satisfaisante.
- Les propriétés sont exprimées dans des logiques temporelles, qui permettent
d'exprimer facilement de nombreuses propriétés naturelles.
- La méthode se généralise à des systèmes concurrents.
- L'explosion du nombre d‟états à parcourir pour vérifier rend utiles des techniques de
réduction de l'espace d'états.
- 110 -
Techniques symboliques : ne pas représenter explicitement chaque état,
mais Calculer sur des représentations compactes.
Techniques réductions par ordre partiel : identifier des chemins qu'il
suffit d'explorer Pour garantir la vérification complète de la propriété.
Quoique le modèle checking puisse être confronté au problème de l‟explosion de l‟espace
d‟état, un certain nombre de travaux de recherche ont été menés pour tenter de maitriser cette
limitation [Clarke, 1999].
En résumé, les approches listées dans cette sous-catégorie visent à appliquer la technique
de model-checking pour vérifier le comportement spécifié dans une machine d‟état par la
translation de la dernière à un langage d‟entrée d‟un model-checker tels que Promela de SPIN,
SMV- SL de SMV et UUPAL …etc .la figure 2.9 schématise le principe de model checking
Figure 2.9 : Schéma général du principe du model-checking
- 111 -
III.3 .2 Les langages de Spécification : [Wikipedia ,2010]
Les méthodes formelles peuvent être utilisées pour donner une spécification du système
que l'on souhaite développer, au niveau de détails désirés. Une spécification formelle du système
est basée sur un langage formel dont la sémantique est bien définie (contrairement à une
spécification en langage naturel qui peut donner lieu à différentes interprétations). Cette
description formelle du système peut être utilisée comme référence pendant le développement.
De plus, elle peut être utilisée pour vérifier (formellement) la réalisation finale du système
(décrite dans un langage informatique dédié).
Une fois qu'une spécification a été développée, elle peut être utilisée comme référence
pendant le développement du système concret (mise au point des algorithmes, réalisation en
logiciel et/ou circuit électronique). Par exemple:
Si la spécification formelle est dotée d'une sémantique opérationnelle, le comportement
observé du système concret peut être comparé avec le comportement de la spécification
(qui elle-même doit être exécutable ou simulable). De plus, une telle spécification peut
faire l'objet d'une traduction automatique vers le langage cible.
Si la spécification formelle est dotée d'une sémantique axiomatique, les prés- conditions
et post conditions de la spécification peuvent devenir des assertions dans le code
exécutable. Ces assertions peuvent être utilisées pour vérifier le fonctionnement correct
du système pendant son exécution (ou simulation), ou mieux encore des méthodes
statiques (preuve de théorème, model-checking) peuvent être utilisées pour vérifier que
ces assertions seront satisfaites pour toute exécution du système.
Les langages de spécification sont classés comme suit :
- Approche basée sur des états : Z [Demuynck, 1997], SAZ, Méthode B classique,
ASM, TLA+.
- Approche basée sur des événements : Action System
- Méthode B événementielle voir Méthode B, VHDL, Esterel, SDL, LOTOS, E-
LOTOS, EB3
- Algébriques: Larch (Larch family)
- 112 -
- CASL: Common Algebraic Specification Language
Plusieurs approches tendent à formaliser la machines d‟états UML par sa translation en
une spécification formelle écrite par des langages formels tels que Z, PVS, CASL, Lotus, Object
Z, et RSL
- 113 -
III.3 .3 Autre approches de translation :
Cette sous-catégorie regroupe des approches qui traduisent la machine d‟états UML en
des expressions régulières concurrentes ou traduisent la machine d‟état à un système
axiomatique, par exemple :
- [Jansamak ,2004], cet article propose les règles de transformation pour formaliser
des diagrammes de statechart d'UML. La langue cible pour la transformation sont des
expressions régulières concourantes (CREs) représentant des extensions des
expressions régulières.
- [Lano, 2000], ce document fournit une interprétation formelle systématique pour la
plupart des éléments de la notation d'UML. Cette interprétation, dans une logique
temporelle structurée, permet l'analyse précise des propriétés de ces modèles, et la
vérification d'un modèle contre des autres.
- [Aoki, 2001], ce document, propose un système axiomatique pour la vérification
d'uniformité des modèles construits d'analyse selon des modèles d'UML. Ce système
axiomatique fournit la sémantique rigoureuse de ces modèles et permet de prouver
des affirmations assignées aux modèles.
- 114 -
IV- Conclusion
Statechart est un graphique des états reliés par les transitions, qui représentent la machine
d'état. Typiquement, Statecharts décrivent le comportement d‟une classe lorsqu‟elle reçoit un
événement.
Le SM (state -machine, machine- d‟état) de Statechart est un ensemble fini de modèles
d'états-transitions, où le modèle d'état- transitions est défini comme suit :
ST = (S, T, E, C, A, i, f) où
- S est un ensemble fini d'états.
- E est un ensemble fini d'événements.
- C est un ensemble fini de conditions.
- A est un ensemble fini d'actions.
- Le T ⊂ S×E×C×2A×S de T est un ensemble fini de transitions, Là où 2
A dénote
l'ensemble de puissance d'A.
- i ∈ S est un état initial
- f ∈ S est un état final.
Les diagrammes d‟états transitions font partie des diagrammes du langage UML, qui est
un langage semi-formel caractérisé par une syntaxe riche et une sémantique ambigüe et non
précise. L‟alternative réside dans les méthodes formelles qui représentent une solution
intéressante à ce problème.
Les spécifications formelles auront pour effet d‟éliminer les ambigüités au niveau de
l‟interprétation des modèles, d‟enrichir la sémantique faible et de vérifier formellement les
modèles (model checking).Quant à elle, tenter de valider le comportement d‟un système à l‟aide
de diverses propriétés énoncées à l‟aide d‟une logique temporelle.
Les méthodes formelles définissent :
- Une sémantique opérationnelle et animation de spécifications.
- Une sémantique dénotationnelle, mécanismes de vérification et de génération de code.
- 115 -
CHAPITRE III
ATOM3 ET TRANSFORMATION
DES MODELES
I- Introduction.
II- Modélisation et méta modélisation.
III- La transformation des modèles.
IV- ATOM3.
V- Travaux connexes.
VI- Conclusion.
- 116 -
II. Introduction
L‟architecture dirigée par les modèles ou MDA est une démarche de réalisation de
logiciel, proposée et soutenue par l'OMG. C'est une variante particulière de l'ingénierie dirigée
par les modèles (IDM, ou MDE pour l'Anglais Model Driven Engineering).
Le génie logiciel s‟est servi d‟un ancien paradigme, les modèles, mais avec une nouvelle
approche, l‟ingénierie dirigée par les modèles – MDE (Model Driven Engineering). Dans cette
nouvelle tendance, l‟approche MDA (pour l'Anglais Model Driven architecture) de l‟OMG en
est une variante particulière. Celle-ci est basée sur les standards de l'OMG. Elle propose une
architecture à quatre niveaux, avec les éléments suivants à chaque niveau : méta-méta-modèle,
méta-modèle, modèle et information (c'est-à-dire l‟implémentation du modèle) (II.1). Pour
atteindre la caractéristique «méta», il ne faut pas raisonner sur le contenu du modèle, c‟est-à-dire
sur ce qu‟il faut modéliser dans le système. Il faut plutôt raisonner sur les concepts (et les
relations entre ces concepts) nécessaires à la description des modèles d‟un système [Kühne,
2006].
Le principe de base du MDA est l'élaboration de modèles indépendants de plate-forme
(Platform Independent Model, PIM) et la transformation de ceux-ci en modèles dépendants de
plates-formes (Platform Specific Model, PSM) pour l'implémentation concrète du système. Les
techniques employées sont donc principalement des techniques de méta- modélisation (II.2) et
des techniques de transformation de modèles (III).
Aujourd‟hui, Il est largement reconnu qu‟un des points clés de MDA est la transformation
de modèles [Sendall, 2003]. La définition suivante de la transformation de modèles, largement
consensuelle, est proposée dans [Kleppe, 2003]:
“A Transformation is the automatic generation of a target model from a source
model, according to a transformation definition. A transformation definition is a set of
transformation rules that together describe how a model in the source language can be
transformed into a model in the target language. A transformation rule is a description of
- 117 -
how one or more constructs in the source language can be transformed into one or more
constructs in the target language”.
Plusieurs outils de modélisation ont été proposés pour effectuer la transformation des
modèles soit transformation modèle vers modèle ou modèle vers code (génération du code), par
exemple AGG, AToM3 (VI), VIATRA2, et VMTS. Certaines tentatives de transformations des
modèles sont réalisées, Les travaux connexes (V) représentent un survol sur ces approches.
- 118 -
II. Modélisation et méta modélisation :
La méta-modélisation :
Afin de préciser la notion de méta modélisation, nous considérerons les définitions
suivantes :
II.1 Définitions (modèle, méta-modèle, méta-méta-modèle)
II.1.1 Le modèle :
Le dictionnaire de la langue française en ligne TLFI [Atilf ,2010] (Trésor de la langue
française informatisé), donne les définitions suivantes du mot « modèle » :
Arts et métiers : représentation à petite échelle d‟un objet destiné à être reproduit
dans des dimensions normales.
Épistémologie: système physique, mathématique ou logique représentant les
structures essentielles d‟une réalité et capable à son niveau d‟en expliquer ou d‟en
reproduire dynamiquement le fonctionnement.
Cybernétique : système artificiel dont certaines propriétés présentent des analogies
avec des propriétés, observées ou inférées, d‟un système étudié, et dont le
comportement est appelé, soit à révéler des comportements de l‟original susceptibles
de faire l‟objet de nouvelles investigations, soit à tester dans quelle mesure les
propriétés attribuées à l‟original peuvent rendre compte de son comportement
manifeste.
Un modèle: est une abstraction d‟un système construit dans une intention particulière.
Un modèle représente un système. Cette relation de représentation est notée μ. Ou
système est l‟entité à modéliser.
Un système est une construction théorique que forme l‟esprit sur un sujet (par exemple,
une idée qui est mise en œuvre afin d‟expliquer un phénomène physique qui peut être représenté
par un modèle mathématique). [Wiki, 2010]
- 119 -
Un modèle est une abstraction d'un système qui devrait être plus simple que celui-ci.
Cette simplification se traduit, en général, par la disparition de détails d'ordre technique.
Un modèle représente le système qu'il décrit et doit pouvoir être utilisée à sa place pour
répondre à un certain nombre de questions sur celui-ci. [Bézivin, 2001]. Pour [Erikson, 2004], un
modèle est une description abstraite des systèmes exprimés par des diagrammes.
Un modèle [Calvez, 1990] [Morel, 1992] : un modèle est une interprétation explicite par
son utilisateur de la compréhension d'une situation, ou plus simplement d'une idée qu'il se fait
sur la situation. Il peut être exprimé par des mathématiques, des symboles, des mots, mais c'est
essentiellement une description d'entités et de relations entrent-elles. Ainsi, modéliser revient à
élaborer une vue partielle plus ou moins abstraite de l‟existant.
Un modèle est une description abstraite d‟un système ou d‟un processus, une
représentation simplifiée qui permet de comprendre et simuler. La modélisation n‟est pas un
problème à solution unique, bien souvent, le même problème analysé par des personnes
différentes conduit à des modèles différents. D‟où, il n‟y a donc pas de mauvais modèles,
mais en revanche des modèles plus élégants que d‟autre. Un modèle capture la sémantique
d‟un problème et contient des données exploitées par les outils pour l‟échange d‟information
, la génération de code , la navigation , etc. [Muller, 2001].
Un modèle [Rumbaugh, 2005] est une représentation identique ou différente d‟une
forme. Il capture les aspects importants des éléments à modéliser à partir d‟un certain point de
vue et simplifie ou omet le reste, Un modèle [Rumbaugh, 2005] contient :
Sémantiques et représentation : les modèles se représentent sous deux aspects importants : les
informations de sémantique (la sémantique) et représentation visuelle (la notation). L‟aspect
sémantique capture la signification d‟une application sous forme d‟un réseau de constructs
logiques, tels que des classes, des associations, des états, des cas d‟utilisation et des messages.
Les éléments du modèle sémantique véhiculent la signification du modèle, c‟est à dire qu‟ils
expriment la sémantique. On les utilise pour la génération de code, le contrôle de validité, la
métrique de la complexité selon [Clark, 2008], il y a plusieurs types de sémantiques :
- 120 -
La sémantique de traduction : La sémantique du langage peut être obtenue par la
traduction des concepts du langage vers les concepts d'un autre langage qui a déjà une
sémantique précise. Ce type de sémantique peut être trouvé dans la traduction des
langages de programmation de haut niveau vers des langages machines. L'avantage de
ce type de sémantique est qu'il permet d'obtenir directement une sémantique exécutable
pour un langage à travers la traduction. Cependant, son inconvénient est le risque de
perte d'informations du langage original au cours du processus de traduction, et de lier
un langage à une machine, ce qui empêche son exécution sur d'autres machines.
La sémantique opérationnelle : La sémantique opérationnelle décrit la sémantique
dynamique du langage, c‟est-à-dire qu‟elle décrit la manière d'exécuter un modèle (ou
programme). Typiquement, la sémantique opérationnelle est exprimée en termes
d'opérations associées aux concepts du langage. Par exemple, les opérations run (), Start
(), stop () du concept Thread dans le langage Java décrivent la sémantique
opérationnelle de ce concept en indiquant la manière d'exécuter un thread dans un
programme Java.
La sémantique extensionnelle : La sémantique d'un langage est définit comme une
extension d'un autre langage. Les concepts du nouveau langage héritent la sémantique
des concepts d'un langage existant. Cette idée est très proche de la notion de profil dans
UML. Le bénéfice est la réutilisation des langages existants avec un moindre effort.
La sémantique dénotationnelle : L'objectif du sémantique dénotationnelle est
d'associer des objets mathématiques tels que des nombres, des tuples, des fonctions aux
concepts du langage. Par exemple, l'ensemble des nombres entiers de 0 à l'infini peut
être associé au concept Integer du langage Java. Le concept est dit "dénoter" les objets
mathématiques, alors que les objets sont appelés "dénotation" du concept.
Contexte : les modèles sont eux-mêmes des artefacts. On les utilise dans un contexte
plus étendu qui leur donne leur pleine signification. Cela comprend l‟organisation
interne du modèle, des annotations sur l‟utilisation de chaque modèle dans le processus
de développement global, un jeu de valeurs par défaut et d‟hypothèses destinées à la
création et à la manipulation d‟éléments et une relation vers l‟environnement ou on
les utilise.
- 121 -
Plusieurs définitions sont proposées, mais il n‟existe pas de définition universelle .Nous
proposons ci-dessous trois définitions significatives.
- "A model is a simplification of a system built with an intended goal in mind. The
model should be able to answer questions in place of the actual system." [Bézivin,
2001].
- "A model is a set of statements about some system under study (SUS)." [Seidwitz,
2003]
- "A model is an abstraction of a (real or language based) system allowing predictions,
or inferences to be made." [K¨uhne, 2006] [O‟Keefe, 2008].
Malgré les différentes définitions, les modèles adaptent certains critères [K¨uhne, 2006]
[Vega, 2005] [Ludewig, 2003] :
Représentation: Il existe un système original qui est l'objet à étudier et que l'on veut
représenter par un modèle. Cette caractéristique est essentielle ; un modèle ne peut exister
sans le système qu'il représente. Un modèle doit être basé sur son original« mapping
feature».
Simplification : Le modèle donne une vue simplificatrice du système. Certaines
caractéristiques du système sont représentées, d'autres non ; tout dépend du but et de
l'utilisation du modèle. Un modèle ne représente pas toutes les propriétés du système. Il
n'est donc pas une copie du système [K¨uhne, 2006].
Autrement dit, Un modèle peut refléter seulement une partie pertinente des propriétés de
l‟original «reduction feature».
Pragmatisme : Un modèle peut remplacer un système pour un propos donné. Les
informations obtenues en consultant le modèle devraient être conformes à celles qu‟on
aurait obtenues en consultant le système. Cette caractéristique assure l'utilité du modèle
car elle permet d'obtenir les informations souhaitées plus rapidement et plus simplement
qu'en interrogeant le système. Autrement dit, Un modèle doit pouvoir être utilisé à la
place de l‟original tout en demeurant sur les mêmes objectifs « pragmatic feature ».
Les modèles, représentent une vision très étendue des systèmes, comme énonce Bézivin
"tout est modèle"[Bézivin, 2005a]. Ce slogan arrive après le célèbre slogan "tout est objet" de la
programmation orienté objet (POO). Dans la POO, le concept de classe est utilisé pour classifier
- 122 -
des objets. De la même manière, dans le monde IDM, les modèles sont classifiés selon les
langages de modélisation dans lesquels les modèles sont écrits.
Cette classification est ainsi fondée sur les formalismes dans lesquels sont exprimés les modèles.
Cependant, un modèle peut être classifié en se basant sur d'autres critères :
La nature du modèle : physique, abstrait ou numérique.
Favre dans l‟article [Favre, 2004a] distingue entre les systèmes physiques, abstraits ou
numériques. Puisqu'un modèle est lui-même un système, il peut également être physique, abstrait
ou numérique. Pour automatiser le traitement des modèles, il faut le formaliser. Certains auteurs
font cette précision dans la définition même de la notion de modèle :
«Un modèle est une description d‟un système écrite dans un langage bien-défini »
[Kleppe, 2003].
La motivation de modélisation : descriptive ou spécification.
Un modèle peut être utilisé pour décrire un système existant ou pour spécifier un système
à construire. Dans [Seidwitz, 2003], Seidewitz différencie entre les modèles descriptifs et les
spécifications. La différence entre ces deux types est que dans le premier cas, le modèle est conçu
par l'observation d'un système existant alors que dans le deuxième cas, le système est conçu par
l'observation d'un modèle [Bézivin, 2005a].
L'évolution du modèle : statique ou dynamique.
Bézivin classifie les modèles en statique et dynamique selon le changement d'état du
modèle au cours du temps [Bézivin, 2005a]. Un modèle est statique si son état est constant ; il est
dynamique si son état évolue. Il utilise cette distinction pour remarquer l'usage répandu en
informatique de modèles statiques et de modèles dynamiques : le modèle en soi ne change pas,
mais il représente l'évolution du système modélisé dans le temps [Vega, 2005].
Précision des modèles : esquisse, plan ou exécutable
Lee [Lee, 2000] définit la précision d‟un modèle comme une mesure du degré ou
granularité de son abstraction. La précision peut être réduite en éliminant des détails non
essentiels ou en faisant recours à des descriptions qualitatives et non quantitatives.
- 123 -
Le degré de précision d‟un modèle est indépendant de sa formalité et de sa justesse. Un
modèle informel et vague peut très bien être une description juste d‟un système, pour une tâche
donnée.
[Mellor, 2004] classifie les modèles selon leur degré de précision en esquisses, plans et
modèles exécutables :
- Une esquisse n‟est pas ni précise ni complète, elle sert à évaluer des nouvelles idées.
- Un plan est suffisamment précis pour servir de modèle de spécification, mais ne couvre
qu‟un aspect du système.
- Un modèle exécutable est suffisamment précis et complet pour pouvoir servir à dériver un
système exécutable.
- L'application du modèle : contemplatif ou productif.
Cette classification distingue les modèles produits par des méthodes de modélisation à la
merise qui sont en général contemplatives, interprétées par les humains, par opposition aux
modèles productifs, outillables, interprétables par des machines dans l'IDM. Un modèle dans
l'IDM est non seulement une documentation mais un artéfact central participant au processus de
développement logiciel.
Le rôle du modèle : produit ou processus.
Produit et processus sont deux faces d'un système. De ce point de vue, Bézivin a distingué
entre les modèles de produit et les modèles de processus [Bézivin, 2005a]. Dans le
développement, le mariage entre ces deux modèles est une des manières de construire un
système. De ce point de vue, on perçoit donc le problème de la construction de modèles.
Le niveau d'abstraction du modèle : PIM (Platform Independent Model), ou PSM (Platform
Specific Model)
Les modèles peuvent modéliser les systèmes à des degrés d'abstraction différents.
Ils peuvent être très abstraits ou très détaillés ; très conceptuels ou très techniques. Pour
distinguer les modèles selon les différences de niveaux d'abstraction, le standard MDA introduit
- 124 -
les concepts de modèles indépendants de la plate-forme (PIM) et dépendants de la plate-forme
(PSM).
Cette distinction est basé sur le principe du MDA selon laquelle le cycle de
développement du logiciel est un processus de transformation progressive des modèles métiers,
au niveau d'abstraction haut et qui ne dépendent d'aucune technologie d'implémentation, vers des
modèles plus spécifiques aux plates-formes techniques.
Bien que le principe de MDA soit facile à concevoir, sa réalisation n'est pas évidente.
Ceci vient de l'ambiguïté de la définition du concept de plate-forme. Cette notion est assez
vague et très dépendante du contexte, ce qui rend les notions de PIM et PSM contestées.
[Bézivin, 2003] suggère d‟autres critères de classification. Notons que, parmi les critères
que nous avons abordés, les trois premiers concernent tous les modèles, alors que les trois
derniers sont attribués aux modèles informatiques.
II.1.2 Le méta-modèle :
Un méta-modèle [Favre, 2004b] [Bézivin, 2005b] est défini simplement comme le
modèle d‟un langage de modélisation. La définition d‟un méta- modèle décrit non seulement les
concepts du formalisme de représentation, mais aussi les règles syntaxiques et sémantiques de ce
formalisme.
Un méta-modèle est la spécification d'une abstraction, d'un ou plusieurs modèles.
Cette spécification définit un ensemble de concepts importants pour exprimer des
modèles, ainsi que les relations entre ces concepts. Le méta-modèle définit la terminologie à
utiliser pour définir des modèles [Bézivin, 2001]. Pour [Erikson, 2004] c‟est un modèle qui
décrit d‟autres modèles, exprimé en métalangage, les méta-modèles sont utilisés pour décrire
UML.
Un méta-modèle est un modèle d‟un ensemble de modèles. "Meta-model is a model of
a set of models." [Favre, 2004c].
- 125 -
Un méta-modèle décrit de manière formelle les éléments de modélisation ainsi que
la syntaxe et la sémantique de la notation qui permet de les manipuler. Le gain d‟abstraction
induit par la construction d‟un méta-modèle facilite l‟identification d‟éventuelles incohérences
et encourage la généricité. [Muller, 2001]
Un méta-modèle est un modèle d‟un langage de modélisation. C‟est une abstraction d‟un
langage permettant de décrire des modèles.
L‟élément méta- vient du grec meta, qui peut signifier « au milieu », « avec » ou
« après ». Il entre dans la formation de noms et d‟adjectifs techniques ou scientifiques, dans
lesquels il exprime la succession, le changement, la participation, ou un concept qui englobe un
autre concept. [Bdl, 2010].
En linguistique, le préfixe «méta» est employé dès qu‟une opération «méta» est appliquée
deux fois. Par exemple, une discussion qui définit comment les futurs discussions doivent être
menées est une méta-discussion (les interlocuteurs définissent les règles et les concepts
nécessaires pour discuter entre eux). Dans l‟IDM7, un modèle qui vise à définir les règles et les
concepts utilisés pour décrire d‟autres modèles est un méta-modèle. De même, un modèle qui
définit les règles et les concepts pour décrire des méta-modèles est un méta-méta-modèle.
Un méta-modèle est un modèle qui définit le langage d‟expression d‟un modèle, c‟est-à-
dire le langage de modélisation [OMG, 2006a].
Selon MOF8, un méta-modèle définit la structure que doit avoir tout modèle conforme à
ce méta-modèle. Autrement dit, tout modèle doit respecter la structure définie par son méta-
modèle. Par exemple, le méta- modèle UML définit que les modèles UML contiennent des
packages, leurs packages des classes, leurs classes des attributs et des opérations, etc.
7 L‘Ingénierie Dirigée par les Modèles (IDM)
8 Le Meta-Object Facility (MOF) est un standard de l'OMG s'intéressant à la représentation des méta-
modèles et leur manipulation. Le langage MOF s'auto-définit.
Le standard MOF est situé au sommet d'une architecture de modélisation en quatre couches :
M3, le méta-méta-modèle MOF (couche auto-descriptive) ;
M2, les méta-modèles ;
M1, les modèles ;
M0, le monde réel.
- 126 -
Les méta-modèles fournissent [Blanc, 2005] la définition des entités d‟un modèle, ainsi
que les propriétés de leurs connexions et de leurs règles de cohérence. MOF les représente sous
forme de diagrammes de classes.
Rappel: les diagrammes de classes permettent de représenter les notions d‟un domaine et
leurs propriétés, que ces notions ou entités soient organisées ou non sous forme d‟objets. Cette
utilisation des diagrammes de classes a le double avantage de permettre de définir très
précisément les méta-modèles et de les rendre eux aussi pérennes et productifs.
Un méta-modèle est donc une sorte de diagramme de classes qui définit la structure d‟un
ensemble de modèles.
Un méta-modèle est un modèle d‟un langage de modélisation , le terme „„méta‟‟
indique un niveau plus élevé, soulignant le fait qu‟un méta-modèle décrit un langage de
modélisation à plus haut niveau d‟abstraction que le langage de modélisation lui-même .Un
méta-modèle possède deux caractéristiques essentielles. Premièrement, il doit capturer les
caractéristiques essentielles du langage de modélisation. Deuxièmement, il devrait être capable
de décrire la syntaxe concrète, et la sémantique de ce langage. [Clark, 2004]
La relation entre un élément d‟un modèle et un ou plusieurs éléments de son méta-modèle
est appelée la relation de conformité. Cette relation est notée χ.
II.1.3 Le langage de modélisation :
Que ce soit en linguistique (langage naturel) ou en informatique (langage de
programmation ou de modélisation), le langage est caractérisé par sa syntaxe et sa sémantique.
La syntaxe : décrit les différentes constructions du langage et les règles d‟agencement de
ces constructions (également appelées context condition).
La sémantique : désigne le lien entre un signifiant (un programme, un modèle, etc.), et un
signifié (p. ex. un objet mathématique) afin de donner un sens à chacune des constructions du
langage. [Harel, 2004].
- 127 -
Il y a donc entre la sémantique et la syntaxe le même rapport qu‟entre le fond et la forme.
Définition (Langage) : Un langage (L) est défini selon le tuple {S, Sem} où S est sa
syntaxe et Sem sa sémantique.
Cette définition est très générale et assez abstraite pour décrire l‟ensemble des langages,
quel que soit le domaine. De manière plus précise, dans le contexte de l‟informatique, on
distingue généralement :
- La syntaxe abstraite (AS) : qui décrit les constructions du langage et leurs relations. Elle
transcrit également la représentation interne (d‟un programme ou d‟un modèle)
manipulée par l‟ordinateur.
- La syntaxe concrète (CS) : qui décrit le formalisme permettant à l‟utilisateur de manipuler
les constructions du langage.
D‟autre part, on distingue également le domaine sémantique (SD) qui représente
l‟ensemble des états atteignables (c.-à-d. les états possibles du système). La sémantique d‟un
langage est alors donnée en liant les constructions de la syntaxe concrète avec l‟état auquel elles
correspondent dans le domaine sémantique (Mas).Voir la figure 3.1 qui décrit les composants
d‟un langage.
Figure 3.1 : les composants d‘un langage
- 128 -
Définition (Langage de modélisation) : Un langage de modélisation (Lm) est défini
selon le tuple {AS, CS*, M*ac, SD, Mas} où AS est la syntaxe abstraite, CS* est la (les)
syntaxe(s) concrète(s), M* ac est l‟ensemble des mappings de la syntaxe abstraite vers la (les)
syntaxe(s) concrète(s), SD est le domaine sémantique et Mas est le mapping de la syntaxe abstraite
vers le domaine sémantique.
Définition (Langage de modélisation) : Langage de modélisation est un ensemble de
modèles. "A modelling language is a set of model." [Favre, 2004c].La figure 3.2 exprime le
concept de langage de modélisation en l'intégrant avec d'autres concepts définis précédemment.
Figure 3.2 : Langage de modélisation
Dans sa version originale, l‟approche MDA ne proposait aucun mécanisme pour ces
transformations. Pour autant, pour obtenir un logiciel cohérent, il est nécessaire de s‟assurer du
bon déroulement de ces transformations et donc d‟avoir un outil sûr pour exécuter ces
constructions. Plusieurs approches ont été proposées pour cela :
- 129 -
- QVT (Query/View/Transformation) 9est aujourd‟hui le standard défini par l‟OMG. C‟est
une spécification de langage de transformations de modèles qui permet d‟adapter un
modèle à de nouvelles contraintes et de transformer n‟importe quel langage dédié vers un
autre .
- ATL (Atlas Transformation Language) 10est un langage de transformation de modèles
développé à l‟INRIA de Nantes par l‟équipe de Bézivin et disponible sous forme d‟un
plugin Eclipse.
- Les systèmes de récriture de graphes basés sur des grammaires de graphes. Plusieurs
méthodes ont été développées pour faire de manière efficace des transformations de
modèles à l‟aide des grammaires de graphes ; on peut par exemple citer l‟approche TGG
((pour triple graph grammars) introduite par Schürr11). Différents logiciels implantent ces
méthodes : les plus connus sont PROGRES, ATOM3, VIATRA2 ou bien encore AGG.
II.1.4 méta-méta-modèle :
Méta-méta-modèle : Un méta-méta-modèle est un modèle qui décrit un langage de méta-
modélisation, c'est-à-dire. Les éléments de modélisation nécessaires à la définition des langages
de modélisation. Il a de plus la capacité de se décrire lui-même.
Méta-méta-modèle modèle qui définit le langage pour exprimer un méta-modèle. La
relation entre un méta-méta-modèle et un méta-modèle est un analogue à celle qui existe entre
un méta- modèle et un modèle. [Rumbaugh, 2005] Les définitions précédentes définissent
également le moyen utilisé pour décrire un modèle. [Calvez, 1990] et [Morel, 1992] décrivent un
modèle comme un ensemble d'entité et de relations. Cette définition correspond à la description
de modèles par un méta-modèle réalisé avec le formalisme entité association.
9Object Management Group. Meta object facility (MOF) 2.0 query/view/transformation specification.
Technical report, OMG, 2008.Disponible sur : http://www.omg.org/spec/QVT/1.0/PDF/
10
Frédéric Jouault, Freddy Allilaire, Jean Bézivin, Ivan Kurtev and Patrick Valduriez. Atl: a qvt-like
transformation language. In Peri L. Tarr and William R. Cook, editors, OOPSLA Companion, pages
719 -720. ACM, 2006. 11
Andy Schürr. Specification of graph translators with triple graph grammars. In Ernst W.
Mayr, Gunther Schmidt, and Gottfried Tinhofer , editors, WG, volume 903 of Lecture Notes in Computer
Science, pages 151–163. Springer, 1994. Disponible aussi sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.31.249&rep=rep1&type=pdf
- 130 -
Un méta-méta-modèle est un modèle d‟un langage de modélisation permettant de décrire
des méta- modèles. Dans la figure 3.3, l‟objectif est la modélisation de figures géométriques
imbriquées (le système à modéliser). Une de ces figures est présentée en partie droite. L‟espace
technique est donc celui des formes qui peuvent être spécialisées et composées. C‟est le méta-
méta-modèle. Dans cet espace, un méta-modèle permet de décrire des rectangles, dont certains
comportent des carrés et d‟autres des ronds. Un carré peut posséder un rectangle (par héritage un
carré) ou un rond. Ce méta-modèle peut être utilisé pour décrire de nombreuses formes et en
particulier celles décrites en partie droite. Une modèle de cette figure est par exemple constituée
de deux carrés. Un carré est imbriqué dans le premier carré puis un rond est imbriqué dans le
second carré. Dans ce modèle, les caractéristiques de couleur ne sont pas décrites puisque le
méta-modèle ne les capture pas.
Figure 3.3 : Illustration des concepts modèle, méta-modèle et méta-méta-modèle.
- 131 -
II.2 la méta-modélisation
II.2 .1 La définition de méta-modélisation :
La méta-modélisation est l‟activité consistant à définir le méta-modèle d‟un langage de
modélisation. Elle vise donc à bien modéliser un langage, qui joue alors le rôle de système à
modéliser.
Les langages de méta-modélisation qui servent à décrire la structure de différents
formalismes tels que Méta Object Facility (MOF), Protégé, et PIR312
sont conçus pour faciliter
la définition des formalismes. [Sriplakich, 2003].
II.2.2 L‘objectif de méta-modélisation:
La modélisation est une technique de conception de systèmes en utilisant un certain
nombre de concepts prédéfinis. La méta-modélisation est une technique de définitions des
concepts à utiliser pour modéliser des systèmes. Deux expressions clés récapitulant cette
approche sont :
- «Une tentative pour décrire le monde » :
- «Dans un objectif bien particulier». De cette définition on peut déduire les aspects
suivants d‟un méta-modèle :
- Il ne peut pas y avoir un méta-modèle universel utilisable pour décrire tous les systèmes
informatiques.
- Un méta-modèle doit être défini pour un objectif précis. Et donc, qu'il existe une
multitude de méta-modèle.
- Le dernier aspect d'un méta-modèle, en plus des concepts et des relations du domaine
d'application, est la sémantique. Il est en effet important de donner un sens aux éléments
définis dans un méta-modèle.
12
N. Revault, X. Blanc, J-F. Perrot, «On Meta-Modeling Formalisms and Rule-Based Model
Transforms », In International Workshop on Model Engineering of ECOOP 2000 (IWME'00), France, June
2000
- 132 -
II.2.3 L‘architecture à quatre niveaux de la méta-modélisation adoptée par l‘OMG :
L‟approche de méta-modélisation adoptée par l‟OMG est connue comme une hiérarchie à
quatre niveaux [OMG, 2003b] (voir la Figure 3.4) :
- Niveau méta-méta-modèle (M3). M3 : est le niveau méta-méta-modèle, il définit le
langage de spécification du méta-modèle. Le MOF (Meta Object Facility) [OMG, 1997]
est un exemple d‟un méta-méta-modèle.
- Niveau méta-modèle (M2). M2 : est le niveau méta-modèle. Le méta-modèle d‟UML se
situe à ce niveau et il est spécifié en utilisant le MOF, c‟est-à-dire que les concepts du
méta-modèle d‟UML sont des instances des concepts de MOF. La Figure 3.4 montre
deux méta-classes du méta-modèle UML : Class et Association.
- Niveau modèle (M1). M1 : correspond au niveau des modèles UML des utilisateurs.
Les concepts d‟un modèle UML sont des instances des concepts du méta-modèle UML.
La Figure 3.4 montre un extrait de diagramme de classes pour une application bancaire
contenant deux classes Account et Customer liées par une association UML. Les deux classes
sont des instances de la méta-classe Class et le lien est une instance de la méta-classe Association
du méta-modèle UML.
- Niveau objets (M0). M0 correspond au niveau des objets à l‟exécution. Il s‟agit ici de
deux objets must et acc des instances des deux classes Customer et
Account respectivement.
- 133 -
Figure 3.4 :L‘architecture à quatre niveaux de la méta-modélisation
adoptée par l‘ OMG
- 134 -
III. La transformation des modèles :
La technologie MDA (Model Driven Architecture) est un standard issu de l‟OMG qui
permet d‟exploiter et de transformer les modèles UML.
Ceci permet notamment de :
- Produire d‟autres modèles (d‟analyse vers conception, par exemple),
- Produire automatiquement des documentations issues du modèle,
- Générer automatiquement du code à partir du modèle.
Une fonctionnalité essentielle de la MDA est la notion de transformation. Une
transformation regroupe un ensemble de règles et de techniques pour transformer un modèle en
un autre.
III.1 La définition transformation des modèles :
Une transformation de modèle est une fonction, t : S T, qui à partir d‟un ensemble
de modèles sources dans S crée un ensemble de modèles cibles dans T.
Les ensembles S et T sont des ensembles de modèles conformes à deux ensembles de
méta-modèles. Si ces deux ensembles de méta-modèles sont identiques alors la fonction est
endogène, sinon elle est exogène.
- Selon [Czarnecki, 2006], la transformation des modèles est définie comme étant le
processus de conversion d‟un modèle d‟un système vers un autre modèle.
- Une transformation de modèles peut également avoir plusieurs modèles source et
plusieurs modèles cibles. Une caractéristique de transformation de modèles est qu‟elle
est un modèle puisque elle doit être conforme à un méta-modèle donné [Czarnecki,
2006]. La figure 3.5 extraite de [Czarnecki ,2006] décrit l‟ensemble des concepts de la
transformation des modèles.
- 135 -
Figure 3.5 : Concepts de base de la transformation de modèles [Czarnecki, 2006].
[Kleppe, 2003] [Mens, 2005], proposent la définition suivante pour la transformation de
modèles. La transformation : est une génération automatique d‟un modèle cible (Target model) à
partir d‟un modèle source (source Model).
D‟après la définition de la transformation, La transformation est un ensemble de règles
de transformation qui décrivent ensemble comment un modèle dans un langage source est
transformé en modèle dans un langage cible.
Une règle de transformation est une description de comment un concept ou plus dans
un langage source peut être transformé en un concept ou plus d‟un langage cible.
Une transformation de modèles est une opération qui crée automatiquement un ensemble
de modèles cible à partir d'un ensemble de modèles source.
La figure 3.6 représente le contexte opérationnel de la transformation de modèles
[Jouault, 2006]. Le modèle MB, conforme au méta-modèle MMB, est obtenu par l'application de
la transformation MMA à MMB au modèle MA, conforme au méta-modèle MMA. De plus, en
suivant le principe « tout est modèle ». La transformation elle-même est un modèle dont le méta-
modèle est MMT. On dit alors que MMA à MMB est un modèle de transformation. Le langage
de transformation, ou plus précisément ses concepts et leurs relations, est donc capturé par ce
- 136 -
méta-modèle. Les trois méta-modèles MMA, MMB et MMT sont conformes au méta-méta-
modèle qui est conforme à lui-même.
Figure 3.6:La transformation de modèles [Jouault, 2006]
III.2 Le principe des transformations de modèles :
Une transformation de modèle est un ensemble de règles qui s‟appliquent aux éléments
d‟un méta-modèle définissant les modèles sources valides (c‟est-à-dire auxquels la
transformation peut s‟appliquer) et qui définissent pour chacun de ces éléments leur(s)
équivalent(s) parmi les éléments d‟un méta-modèle cible. Le moteur de transformation (aussi
appelé « transformateur de modèles ») lit le modèle source, qui doit donc être conforme au méta-
modèle source, et applique les règles définies dans la transformation de modèle afin de créer le
modèle cible qui sera conforme au méta-modèle cible. Les méta-modèles source et cible peuvent
faire partie de la définition de langages de modélisation et, dans ce sens, les transformations de
modèles peuvent être considérées comme des systèmes de traduction (ou de réécriture) d‟un
langage vers un autre.
Le principe général présenté ici pour les transformations de modèles est indépendant de la
syntaxe concrète et de la sémantique associées aux méta-modèles source et cible. Concernant les
différences de syntaxe concrète, il est à noter que les transformations modèle-à-modèle et
- 137 -
modèle-à-texte sont souvent distinguées l‟une de l‟autre dans la littérature. Le principe des
transformations de modèles est illustré aussi par la figure 3.5
Les transformations de modèle peuvent s‟appuyer sur différentes techniques sous-jacentes
telles que les « templates » (sortes de gabarits), les transformations de graphes, les grammaires de
graphes triples [Schürr, 1995], etc…
Les transformations peuvent utiliser des outils comme AGG13
, AToM314
, VIATRA215
,
et VMTS16
. [Taentzer, 2005]
III.3 Structure d‘une règle de transformation : [Bonnet ,2005]
Une règle de transformation est une description de la manière dont une ou plusieurs
constructions dans un modèle source peuvent être transformées en une ou plusieurs constructions
dans un modèle cible. [Kadima ,2005]
Une transformation de modèle est notamment caractérisée par la réunion des éléments
suivants : des règles de transformation, une relation entre la source et la cible, un
ordonnancement des règles, une organisation des règles, une traçabilité et une direction.
Règles de transformation. Une règle de transformation contient deux parties : une partie
gauche (left-hand side «LHS») et une partie droite (right-hand side «RHS»). La LHS
exprime des accès aux modèles sources, alors que la RHS indique les expansions
(création, modification, suppression) dans les modèles cibles. Chacune des deux parties
peut être représentée par une combinaison de [Czarnecki, 2003] [Prakash ,2006]:
- Variables : une variable contient un élément de modèle (source ou cible) ou une valeur
intermédiaire nécessaire à l‟expression de la règle,
13
-AGG Home page. http://user.cs.tu-berlin.de/~gragra/agg/ 14
-http://atom3.cs.mcgill.ca/ 15
-http://www.eclipse.org/gmt/VIATRA2/ 16
-VMTS Web Site, http://avalon.aut.bme.hu/~tihamer/research/vmts/
- 138 -
- Patterns : un pattern désigne un fragment de modèle et peut contenir des variables. Il peut
être représenté à l‟aide d‟une syntaxe abstraite ou concrète dans le langage des modèles
correspondants. Cette syntaxe peut être textuelle ou graphique,
- Logique : une logique permet d‟exprimer des calculs et des contraintes sur les éléments de
modèle. Cette expression peut être non exécutable (expression de relations entre modèles)
ou exécutable. Une logique exécutable peut être sous une forme déclarative ou
impérative.
Un exemple de logique déclarative : des expressions de requêtes OCL pour extraire des
éléments d‟un modèle source et la création implicite des éléments du modèle cible via les
contraintes. Une logique impérative est souvent exprimée par un langage de programmation qui
fait appel à des APIs pour manipuler directement les modèles.
Relation entre les modèles source et cible. Pour certains types de transformations, la
création d‟un nouveau modèle cible est nécessaire. Pour d‟autres, la source et la cible sont
le même modèle, ce qui revient en fait à une modification de modèle.
Organisation des règles. L‟organisation des règles définit comment composer plusieurs
règles de transformation. Les règles peuvent être organisées de façon modulaire, avec la
notion d‟importation. Les règles peuvent également utiliser la réutilisation, par le biais de
mécanismes d‟héritage entre règles, ou la composition, par le biais d‟un ordonnancement
explicite. Enfin, les règles peuvent être organisées selon une structure dépendante du
modèle source ou du modèle cible.
Ordonnancement des règles. Les mécanismes d‟ordonnancement déterminent l‟ordre
dans lequel les règles sont appliquées. Dans le cas d‟un ordonnancement implicite,
l‟algorithme d‟ordonnancement est défini par l‟outil de transformation. Dans le cas d‟un
ordonnancement explicite, des mécanismes permettent de spécifier l‟ordre d‟exécution
des règles. Cet ordre d‟exécution peut être défini de manière externe ou interne : tandis
qu‟un mécanisme externe établit une séparation claire entre les règles et la logique
d‟ordonnancement, un mécanisme interne permet aux règles d‟invoquer d‟autres règles.
Enfin, l‟ordonnancement des règles se repose également sur des conditions, des itérations
ou sur une séparation en plusieurs phases, certaines règles ne pouvant être appliquées que
dans certaines phases.
- 139 -
Traçabilité. Les transformations peuvent stocker les corrélations entre les éléments des
modèles source et cible. Certaines approches fournissent des mécanismes dédiés pour
supporter la traçabilité. Dans les autres cas, le développeur doit implémenter la traçabilité
de la même manière qu‟il crée n‟importe quel autre lien dans un modèle.
Direction. Les transformations peuvent être unidirectionnelles ou bidirectionnelles. Dans
le premier cas, le modèle cible est calculé ou mis à jour sur la base du modèle source
uniquement. Dans le second cas, une synchronisation entre les modèles source et cible est
possible.
- 140 -
III.4 Les types de transformations des modèles :
Krzystof Czarnecki et Simon Helsen ont publié une classification des différentes
approches de transformation de modèles .Cette classification est basée sur un ensemble de
critères. [Czarnecki, 2003] [Czarnecki, 2006].
Critère Notion
Spécification Certaines approches fournissent un
mécanisme dédié pour spécifier les transformations
Règles de transformation Unités de base de l‟expression de
transformation
Contrôle de l‘application des règles
Stratégies de localisation des modèles et
de détermination de l‟ordre d‟exécution des règles
de transformation
Organisation des règles Structuration, modularité et réutilisation
des règles
Relation entre source et cible Concerne l‟identité des modèles sources et
cibles ; sont-ils différents ou non ?
Incrémentation
Possibilité de mise à jour des modèles
cibles lorsque les modèles sources correspondants
changent
Directivité ou réversibilité Détermine si la transformation est
unidirectionnelle ou multidirectionnelle
Traçabilité
Mécanisme d‟enregistrement des liens
entre éléments de modèles sources et éléments des
modèles cibles
Tableau 3.1 : Critères de classification des approches de transformations de modèles
Différents types de transformations de modèle sont étudiés :
La transformation verticale/La transformation horizontale/ La transformation
oblique : [De Lara ,2005] [Azaiez ,2007]
- La transformation verticale : La source et la cible d‟une transformation verticale
sont définies à différents niveaux d‟abstraction. Une transformation qui baisse le
- 141 -
niveau d‟abstraction est appelée un raffinement. Une transformation qui élève le
niveau est appelée une abstraction. (Exemple : génération de code).
- La transformation horizontale : Une transformation horizontale modifie la
représentation source tout en conservant le même niveau d‟abstraction. La
transformation peut être l‟ajout, la modification, la suppression ou la restructuration
d‟informations. (Exemple : la refactorisation).
- La transformation oblique : Une transformation oblique combine une
transformation horizontale et une verticale. Ce type de transformation est
notamment utilisé par les compilateurs, qui effectuent des optimisations du code
source avant de générer le code exécutable.
La transformation endogène / La transformation exogène : transformer un modèle Ma
en un modèle Mb, si les méta-modèles respectifs MMa et MMb sont identiques
(transformation endogène), ou différents (transformation exogène). [Bézivin, 2004].
- Les transformations endogènes mettent en jeu des modèles exprimés dans un
même langage (possédant donc le même méta-modèle). Il peut ainsi s‟agir de :
L‟optimisation : la transformation a pour but d‟améliorer par
exemple la qualité d‟exécution (en termes de performance) du
modèle, tout en préservant la sémantique du modèle,
La restructuration : la transformation entraine un changement de
la structure interne du modèle afin d‟améliorer la qualité de
certaines caractéristiques comme la modularité et la réutilisation,
sans modifier le comportement du modèle,
La simplification : la transformation va permettre de simplifier la
complexité de la syntaxe du modèle.
- La transformation exogène, quant à elle, met en jeu des modèles exprimés dans
des langages différents. De même que pour la transformation endogène, on
peut citer plusieurs exemples de transformation exogène :
La migration : la transformation d‟un modèle écrit dans un certain langage en un modèle écrit
dans un autre langage, tout en gardant le même niveau d‟abstraction.
La synthèse : la transformation d‟un modèle de haut niveau, très abstrait (spécification,
modèle fonctionnel) vers un modèle de bas niveau plus concret (code généré, exécutable)
- 142 -
Le « reverse engineering » : il s‟agit d‟une transformation de synthèse inverse qui permet
d‟extraire des spécifications de haut niveau d‟un modèle de bas niveau. [Guihal, 2007].
La figure 3.7 extraite de [Combemale, 2008] récapitule les types de transformation et leurs
principales utilisations.
Figure3.7: Types de transformation et leurs principales utilisations [Combemale, 2008]
Transformations PIM- PIM et PSM -PSM / Transformation PIM-PSM/
Transformation PSM–code/ Transformations inverses PIM-PSM et PSM-code.
Rappel sur : Typologie des modèles dans l‘approche MDA
L‟OMG17
a défini une typologie de modèles, ainsi qu‟un ensemble de relations de
transformation qui permettent de passer de l‟un à l‟autre. Les quatre principaux types de modèles
définis dans l‟approche MDA [Bézivin, 2002] sont les suivants :
17
Object Management Group est une association américaine à but non-lucratif créée en 1989 dont l‘objectif
est de standardiser et promouvoir le modèle objet sous toutes ses formes.
L‘OMG est notamment à la base des standards UML (Unified Modeling Language), MOF (Meta-Object
Facility), CORBA (Common Object Request Broker Architecture) et IDL (Interface Definition Language).
- 143 -
CIM (Computation Independant Model) : Aussi appelé modèle de domaine ou modèle
métier, le CIM capture les exigences en termes de besoins et décrit la situation dans
laquelle le système sera utilisé. Son but est d‟aider à la compréhension du problème mais
aussi de fixer un vocabulaire commun pour un domaine particulier. Dans la pratique,
l‟appellation « CIM » est très peu utilisée.
PIM (Platform Independant Model) : Le PIM décrit le système indépendamment de la
plate-forme cible sur laquelle il s‟exécutera. Il présente donc une vue fonctionnelle
détaillée du système, sans détails techniques. Il peut être raffiné progressivement jusqu‟à
intégrer des détails d‟architecture spécifiques à un type de plate-forme (machine virtuelle,
système d‟exploitation, etc.) Mais il doit rester technologiquement neutre.
PDM (Platform Description Model) : Le PDM est le modèle qui décrit une plate-forme
d‟exécution. Il fournit un ensemble de concepts techniques représentant les différentes
parties de la plate-forme et/ou les services qu‟elle fournit. Un PDM peut représenter, par
exemple, des plates-formes à base de composants comme CCM18 [OMG, 2006c] ou EJB.
PSM (Platform Specific Model) : Le PSM est le résultat de la combinaison du PIM et du
PDM. Il représente une vue technique détaillée du système. Il peut exister avec différents
niveaux de détails. Dans sa forme la plus détaillée, il sert de base à la génération de
l‟implémentation.
Plusieurs types de transformations de modèle sont définis dans la MDA.
Transformations PIM PIM : PIM vers PIM : Ce type de transformation est utilisé
pour étendre ou spécialiser un modèle sans ajout d'information dépendant de la plate-
forme. Typiquement, cette projection est mise en œuvre pour l'analyse et la conception de
modèles. Ce type de transformation est en règle générale liée au raffinement de modèles.
Elle est elle- même exprimée sous la forme d'un modèle de transformation. [Marvie,
2002].
Transformations PIM PSM : PIM vers PSM : Ce type de transformation est utilisé
dès lors qu'un PIM est suffisamment raffiné pour être projeté vers la plate-forme
L‘OMG est aussi à l‘origine de la recommandation MDA (Model Driven Architecture) ou ingénierie dirigée
par les modèles, avec en particulier le langage standardisé de transformation de modèles QVT
(Query/View/Transformation).
18
CORBA Component Model
- 144 -
d'exécution. Les caractéristiques de la plate-forme servent de base à la projection et
doivent être décrites dans un formalisme de modélisation, comme UML par exemple. Le
passage d'un modèle abstrait de composants à un modèle technologique comme le CCM
représente une projection de type PIM vers PSM [Marvie ,2002].
Les transformations de type PIM vers PIM ou PSM vers PSM tentent d‟enrichir, filtrer ou
spécialiser le modèle. Il s‟agit de transformations de modèle à modèle [Czarnecki ,2006]. Elles
sont automatisables (ou partiellement automatisable) dans certains cas comme la traduction vers
un autre langage mais les transformations de type raffinement ne le sont généralement pas.
Transformation PIM PSM : La transformation de PIM vers PSM permet de
spécialiser le PIM en fonction de la plate-forme cible choisie. Elle n‟est effectuée qu‟une
fois le PIM suffisamment raffiné. Cette transformation de modèle à modèle est réalisée en
s‟appuyant sur les informations fournies par le PDM.
Transformation PSM code : La transformation de PSM vers l‟implémentation (le
code) est une transformation de type modèle à texte [Czarnecki ,2006]. Le code est
parfois assimilé par certains à un PSM exécutable. Dans la pratique, il n‟est généralement
pas possible d‟obtenir la totalité du code à partir du modèle et il est alors nécessaire de le
compléter manuellement.
Transformations inverses PIM PSM et PSM code : Ces transformations sont
des opérations de rétro-ingénierie (reverse engineering). Ce type de transformation pose
de nombreuses difficultés mais il est essentiel pour la réutilisation de l‟existant dans le
cadre de l‟approche MDA. La figure 3.8 réunit les modèles ainsi que les transformations
dans l‟approche MDA.
Figure 3.8: Modèles et transformations dans l‘approche MDA
- 145 -
Transformation modèle vers modèle / modèle vers code : [Czarnecki, 2003]
De manière perpendiculaire à cette classification, on peut distinguer les transformations
de type modèle vers modèle et celles de type modèle vers code. En fait, même si les secondes
peuvent être considérées comme un cas particulier des premières ; il suffit de fournir un méta-
modèle pour le langage de programmation cible. La distinction est néanmoins justifiée car le code
est le plus souvent généré comme du texte simple.
Dans [Czarnecki, 2003], Krzystof Czarnecki et Simon Helsen proposent la classification
schématisée dans la figure 3.9
Figure 3.9: Approches de transformations de modèles (modèle vers modèle / modèle vers
code)
- 146 -
Transformations de type modèle vers code : Dans cette catégorie, on distingue deux
approches, basées sur les principes visiteur19 ou patron20.
- Les transformations basées sur le principe du visiteur : consistent à traverser
le modèle en lui ajoutant des éléments qui réduisent la différence de sémantique
entre le modèle et le langage de programmation cible. Le code est obtenu en
parcourant le modèle enrichi pour créer un flux de texte. Le projet Jamda21destiné
à la génération de code Java fournit un bon exemple de cette approche.
- Les transformations basées sur le principe des patrons : sont actuellement les
plus courantes. Le code cible contient des morceaux de méta-code utilisés pour
accéder aux informations du modèle source. Parmi les outils basés sur cette
approche, on peut citer AndroMDA 22un générateur de code qui se repose
notamment sur Velocity23pour l‟écriture des patrons.
Transformations de type modèle vers modèle : Dans cette catégorie, on distingue :
- Les transformations basées sur la manipulation directe : ces
transformations se basent sur une représentation interne des modèles source et
cible, et sur un ensemble d‟APIs, une API permet de manipuler la
représentation interne des modèles.
Elles sont en général implémentées comme un framework 24
orienté objet qui
fournit une infrastructure pour organiser les transformations (par exemple, la définition de classes
abstraites pour les transformations). Les utilisateurs doivent eux-mêmes réaliser les règles de
transformations au moyen d‟un langage de programmation comme Java. La combinaison JMI
(Java Metadata Interface) et Java est souvent utilisée dans la mise en œuvre de cette approche.
JMI est une API basée sur le MOF et permet de créer, sérialiser, accéder aux éléments
d‟un modèle défini à l‟aide du MOF ou Ecore.
19
Visitor- based approach dans le vocabulaire anglo-saxon. 20
Template-based approach dans le vocabulaire anglo-saxon 21
Le projet Jamda. Disponible à : http://jamda.sourceforge.net/ 22
AndroMDA, site Internet. Disponible à : http://www.andromda.org 23
Velocity 1.4, The Apache Jakarta Project, site Internet. Disponible à
http://velocity.apache.org/ 24
En programmation informatique, un Framework est un kit de composants logiciels structurels, qui
définissent les fondations ainsi que les grandes lignes de l'organisation de tout ou partie d'un logiciel
(architecture). En programmation orientée objet un framework est typiquement composé de classes mères qui
seront dérivées et étendues par héritage en fonction des besoins spécifiques à chaque logiciel qui utilise le
framework
- 147 -
- Les transformations relationnelles : cette transformation consiste à établir une relation
entre les éléments des modèles sources et cibles. Ces relations seront spécifiées à l‟aide de
contraintes. Elles sont purement déclaratives et leur spécification n‟est pas exécutable. La
programmation logique25 avec les principes d‟unification, de recherche et de backtracking
est notamment adaptée dans cette transformation. Les transformations produites
généralement sont bidirectionnelles.
- Les transformations des graphes : Les modèles et méta-modèles possèdent souvent une
représentation graphique apparentée à un graphe. Un modèle, dans ce cas, peut être
considéré comme un graphe étiqueté, contraint par des règles de cohérence
essentiellement définies comme un méta-méta-modèle MOF. Les techniques de réécriture
de graphes et de transformation de graphes peuvent être appliquées pour des
transformations de modèles. D‟une manière générale, les systèmes de réécriture de
graphes combinent une notation graphique et une notation textuelle afin d‟exprimer ces
transformations. Un programme de transformation essentiellement composé de règles de
réécriture va d‟abord sélectionner un fragment d‟un graphe source identifié grâce à un
langage de navigation. L‟application d‟un filtre sur ce fragment sélectionné permet de le
modifier avant de le recopier dans le graphe cible.
Cette catégorie de transformation est mise en œuvre dans : VIATRA [Csertan ,2002],
UMLX [Chen, 2003] et BOTL [Marschall, 2003].
- Les transformations basées sur la structure : Ces transformations spécifient
deux phases. La première consiste à créer la structure hiérarchique du modèle
cible. La seconde consiste à ajuster les attributs et références dans le modèle
25
La programmation logique est une forme de programmation qui définit les applications à l'aide d'un
ensemble de faits élémentaires les concernant et de règles de logique leur associant des conséquences plus ou
moins directes. Ces faits et ces règles sont exploités par un démonstrateur de théorème ou moteur d'inférence,
en réaction à une question ou requête.
Cette approche se révèle beaucoup plus souple que la définition d'une succession d'instructions que
l'ordinateur exécuterait. La programmation logique est considérée comme une programmation déclarative
plutôt qu‘impérative, car elle s'attache davantage au quoi qu'au comment, le moteur assumant une large part
des enchaînements. Elle est particulièrement adaptée aux besoins de l‘intelligence artificielle, dont elle est un
des principaux outils.
- 148 -
cible. On peut citer comme exemple : OptimalJ26, Interactive Objects and
Project Technology (IOPT)27 .
- Les transformations hybrides : Elles représentent une combinaison entre plusieurs
transformations précédentes. Le langage de transformation de règles est une
combinaison d‟approches déclarative et impérative. Une combinaison se traduit par des
:
- Mapping rules qui spécifient les relations entre les éléments sources et
cibles,
- Operational rules qui décrivent les règles exécutables (réalisation de la
transformation).
Comme exemple citons : (ATL)28, Kermeta29et ModTransf30 qui sont des approches de
cette catégorie.
26
Compuware. Disponible sur : http://www.compuware.com/about/history.asp 27
Interactive Objects and Project Technology, 2003. MOF query/Views/Transformations, Revised
Submission. OMG Document: ad/03-08- 11, ad/03-08-12, ad/03-08-13. 28
The atlas transformation language (atl). http://www.sciences.univ-nantes.fr/
lina/atl/. 29
http://www.kermeta.org/ 30
Cédric Dumoulin. ModTransf : A model to model transformation engine, November
2010. Disponible sur. http://www.lifl.fr/west/modtransf/
- 149 -
VI. ATOM3
VI.1 Présentation d‘ATOM3 :
AToM3 (A Tool for Multi-formalism and Meta-Modelling [Vangheluwe, 2002] est un
outil de modélisation multi-paradigmes développé par le laboratoire MSDL (Modelling,
Simulation and Design Lab.) à l'université de McGill Montréal, Canada. Cet outil a été conçu en
collaboration avec Juan de Lara de Universidad Autónoma de Madrid (UAM), Espagne.
Les deux principales fonctionnalités d'AToM3 sont la méta-modélisation et la
transformation de modèles. La méta-modélisation est la description ou la modélisation de
différents types de formalismes. La transformation de modèles est une technique consistant à
transformer, traduire ou modéliser automatiquement un modèle décrit dans un certain
formalisme, vers un autre modèle qui peut être décrit soit dans le même formalisme soit dans un
autre. Il permet aussi de définir la syntaxe abstraite et concrète des langages visuels31
[Taentzer,
2005].
Dans AToM3 les formalismes et les modèles sont décrits comme des graphes. Cet
environnement génère un outil de manipulation graphique des modèles décrits dans un
formalisme donné, à partir d'une méta-spécification de ce formalisme (décrite dans le formalisme
entité/relation). Les transformations entre modèles sont ensuite effectuées par réécriture des
graphes et peuvent être décrites comme ces derniers. La figure
3.10 présente l‟interface d‟ATOM3.
31
Un langage de programmation graphique ou visuel est un langage de programmation dans lequel les
programmes sont écrits par assemblage d'éléments graphiques. Sa syntaxe concrète est composée de symboles
graphiques et de textes, qui sont disposés spatialement pour former des programmes. De nombreux langages
visuels se basent sur les notions « de boîtes et de flèches » : les boîtes (ou d'autres d'objets) sont traités comme
des entités, reliées par des flèches ou des lignes qui représentent des relations.
- 150 -
Figure3.10: l‘interface d‘ATOM3
VI. 2. L‘architecture d‘ATOM3 :
AToM3 est un outil écrit en Python. Le composant principal d‟ATOM3 est son
processeur (noyau, kernel) [De Lara ,2002d] qui est responsable de charger, sauvegarder, créer
et manipuler les modèles (dans tout méta-niveau). Il permet aussi de générer du code pour les
méta-modèles. [Bardohl, 2003]
Les méta-modèles et les méta-méta-modèles sont chargés lorsqu‟ATOM3 est lancé.
Le premier type de modèles permet la construction des modèles valides dans un certaine
formalisme .Les méta-méta-modèles sont utilisés pour décrire un certain formalisme. Les
derniers sont utilisés pour décrire le formalisme lui- même.
Dans ATOM3 les modèles de n‟importe quel niveau sont traités de la même manière.
- 151 -
Le formalisme ER [Entité Relation] est étendu par les contraintes disponibles dans le
méta-méta-niveau, les contraintes disponibles en méta-méta-niveau peuvent être spécifiées en
python ou en OCL. La figure 3.11exprime un travail de méta-modélisation de l‟environnement
proposé par les auteurs de l‟article [de Lara, 2002b]. La 3.12 synthétise l‟architecture d‟ATOM3
[De lara, 2002a].
Figure 3.11: Travail propose un schéma de méta-modélisation de l‘environnement
ATOM3 (Proposed working scheme for a Meta-Modelling environment) [De Lara, 2002b]
[De Lara, 2002c]
- 152 -
Figure 3.12 : l‘architecture d‘ATOM3 [De lara, 2002a]
VI. 3 les niveaux de méta-modélisation sous ATOM3 :
Une des caractéristiques des systèmes complexes est la diversité de leurs composants.
En conséquence, il est souvent souhaitable de modéliser les différents composants en
utilisant les différents formalismes de modélisation. C'est certainement le cas, quand les équipes
interdisciplinaires collaborent sur le développement d'un système simple. Une méthode prouvée
pour réaliser la flexibilité requise pour un langage de modélisation qui soutient beaucoup de
formalismes et des paradigmes de modélisation est pour modéliser le langage de modélisation
elle-même.
Un tel modèle de langage de modélisation s'appelle un méta-modèle. Il décrit les
structures possibles qui peuvent être exprimé en langage. Un méta-modèle peut facilement être
conçu en fonction des besoins spécifiques des domaines particuliers. Ceci exige le méta-modèle
- 153 -
modélisant le formalisme pour être assez riche à soutenir les constructions requises pour définir
un langage de modélisation.
Prenant à la méthodologie une autre mesure, le formalisme méta-modélisation lui-même
peut être modélisé au moyen d‟un méta-méta-modèle. Ces spécifications de méta-méta-modèle
saisissent les éléments de base requis pour concevoir un formalisme. [Posse, 2002][De lara,
2002a]
Level Description Example
Meta-Meta-
Model
Model used to specify modeling
languages
Entity-Relationship Diagrams,
UML class Diagrams
Meta-Model
Model used to specify simulation
models
Finite State Automata, Ordinary
differential equations (ODE).
Model
The description of an object in a
certain formalism
F’(x)= −sin x,f(0)=0(in the ODE
formalism0
Tableau 3.2 : Les niveaux de méta-modélisation (Meta-Modelling Levels) [Vangheluwe,
2002b] [De lara, 2002a]
VI. 4 les concepts d‘ATOM3 : [De lara, 2002a]
Dans ATOM3 les méta-modèles sont construit à partir des entités et relations (entité/
relation formalisme). La description des deux : les entités et les relations comporte la définition
des éléments suivants [Antkiewicz, 2003] :
Nom (Name), attributs (Attributes), Contraintes (constraints), Cardinalities (cardinalités),
Apparence (appearance).
Les entités : représentent les éléments de base du modèle, elles sont définis en indiquant
leurs : attributs, contraintes, cardinalités, actions et leurs apparences graphiques .Voir la
figure 3.13.
- 154 -
Figure 3.13 : boite de dialogue de l‘édition des entités (classes).
Les relations : La relation lie entre un ou plus d‟entités, elle peut exprimer une
association ou un héritage entre les entités participantes à cette relation. Chaque relation
est caractérisée par une contrainte en termes de cardinalités. Voir la figure 3.14.
Figure 3.14 : de l‘édition des relations sous ATOM3.
- 155 -
Les attributs : ATOM3 offre deux types d‟attributs :
- Les attributs réguliers (regular Attributes) sont utilisés pour identifier les
caractéristiques d‟une entité courante.
- Les attributs générateurs (generated attributes), permettent de générer de nouveaux
attributs. Chaque attribut d‟ATOM 3 possède un nom, un type et une valeur
initiale [De Lara, 2002a]. la figure 3.15 présente une boite de dialogue de
l‟édition des attributs d‟ATOM3.
Figure 3.15 : boite de dialogue de l‘édition des attributs d‘ATOM3.
Les types : sous ATOM3, les attributs des entités doivent avoir un type .Tous les types
héritent de la classe abstraite nommée ATOM3Type et doit fournir des méthodes.
ATOM3 possède deux sortes de type basic : les types réguliers (par exemple integers,
floats, lists of some types, enumerates types, etc) et les types génératifs (utiliser pour
engendrer des attributs, les contraintes ou les attributs graphiques de méta-niveau
inférieur .Il y‟a quatre types génératifs d‟ATOM3 (ATOM3Attribute,
ATOM3Constraint, ATOM3Appearance, ATOM3Cardinality) .Voir la figure
3.15.
Les cardinalités : La syntaxe de cardinalité est la suivante [Antkiewicz, 2003] :
Pour l‟entité E, ça signifie que l‟entité E peut être la source ou la destination pour un
minimum (min) jusqu'à un maximum (max) de relations (Relationship).
- 156 -
Pour la relation R, ça veut dire que la relation R peut avoir de min jusqu'à max
d‟entités participants à cette relation. Pour l‟apparence, elle crée en utilisant l‟éditeur
graphique. Les cardinalités possèdent la forme suivante :
<name>dir
= [source/destination],<min>,<max>
Les contraintes : Une contrainte sou ATOM3 est écrit en Python ou exprimé en OCL,
elle est défini par :
- Un nom de contrainte.
- Un événement déclenchant l‟évaluation de la contrainte, l‟événement exprime un
aspect sémantique tel que la sauvegarde d‟un modèle, création d‟une entité ou un
aspect graphique ou Structurel tel que le déplacement ou la sélection d‟une entité.
- Une spécification quand la contrainte doit être évaluée, avant l‟événement (pré-
condition) ou après (post-condition). Une zone pour écrire un code Python ou en
OCL.
Si la pré-condition d‟un événement échoue, alors ce dernier ne s‟exécutera pas. Si la
post-condition d‟un événement échoue, alors ce dernier ne s‟accomplira pas. Il y a deux Types de
contraintes :
- Des contraintes locales liées à une entité, elle doit manipuler que des attributs de
cette entité.
- Des contraintes globales, ou les informations de toutes les entités du modèle sont
manipulées. La Figure 3.16 présente la structure d‟une contrainte.
Figure 3.16 : la structure d‘une contrainte.
- 157 -
Les actions : L‟action sous ATOM3 est défini par :
- Un nom d‟action.
- Un événement déclenchant l‟action, l‟événement exprime un aspect sémantique tel
que la sauvegarde d‟un modèle, création d‟une entité ou graphique ou un aspect
structurel tel que le déplacement ou la sélection d‟une entité.
- Une spécification quand le code de l‟action doit être exécuté, avant l‟événement (pré
condition) ou après (post-condition).
- Une zone pour écrire un code Python.
Une action est analogue à une contrainte ; mais elle se diffère par d‟autres effets et elle
est programmée en Python seulement. La Figure 3.17 présente la structure d‟une contrainte.
Figure 3.17 : La structure d‘une action.
- 158 -
IV.5 Python :
Python est un langage portable , dynamique , extensible , gratuit [Python,2010] qui
permet une approche modulaire et orienté objet de la programmation à. Python est développé
depuis 1989 par GUIDO VAN ROSSUM et de nombreux collaborateurs bénévoles.
L‟utilisation de python dans notre approche est limitée à certaines instructions liées à la
gestion des fichiers sous python( création, lecture, écriture) et d‟autres instructions qui sont
propre à ATOM3 (définition de la grammaire ).
Les programmes ou les modules en python seront écrits dans des fichiers dont
l‟extension sera „.py‟ et seront exécutés par la suite en tapant la commande python suivi le nom
de fichier .py . [Campbell, 2009].
Stéphane Fermigier32
expose dans [Linux-center, 2010] les principales caractéristiques
de python :
Python est portable, non seulement sur les différents variantes d‟UNIX, mais aussi sur les
OS propriétaires : Mac OS, Be OS, NEXT Step, MS-DOS et les différents variantes de
WINDOWS.
Python est gratuit, mais on peut l‟utiliser sans restriction dans les projets commerciaux.
Python convient à des scripts d‟une dizaine de lignes qu‟a des projets complexes de
plusieurs milliers de lignes.
La syntaxe de python est très simple et combinée à des types de données évolués (listes,
dictionnaires ,…..) qui conduit à des programmes à la fois très compactes et très lisibles
à fonctionnalités égales [un programme python est souvent 3 à5 fois plus court qu‟un
programme c ou c++ ou même java équivalent .
Python gère les ressources (mémoire, descripteurs de fichiers) sans intervention de
programmeurs, par un mécanisme de comptage de références.
Pas de pointeurs explicites dans python.
Python est optionnellement multi threadé.
32
Stéphane Fermigier est le président de L‘AFUL (association francophone des utilisateurs de linux et des
logiciels libres .ce texte est extraite d‘un article paru dans le magazine programmes ! en décembre 1998.
- 159 -
Python est orienté –objet, c‟est pour cela, il supporte l‟héritage multiple et la surcharge
des opérateurs.
python intègre un système d‟exceptions, qui permettent de simplifier la gestion des
erreurs, comme java et les versions récentes de C++.
Python est introspectif (un grand nombre d‟outils de développement sont implantés par
python lui-même) ; réflectif ( il supporte la méta-programmation comme par exemple la
capacité pour un objet de rajouter ou supprimer des attributs ou des méthodes , ou
même changer la classe en cours d‟exécution. ; orthogonal (un petit nombre de
concepts suffit à engendrer des construction très riches ) ; dynamique ( l‟interpréteur
peut évaluer des chaines de caractères représentant des expressions ou des instructions
python.
Python est dynamiquement typé comme Scheme ou Small Talk (c‟est –dire que tout
objet manipulable par le programmeur possède un type bien définie à l‟exécution , qui
n‟as pas besoin d‟être déclaré à l‟avance .
Le code source en python n‟est pas compilé contrairement à des langages comme C ou
PASCAL, mais exécuté à la volé, on parle alors de langage interprété [Ziadé, 2006a]
La syntaxe du langage Python est simple, concise et terriblement efficace. Cette
particularité a été dès le départ une volonté de Guido van Rossum, alias GvR, pour en
faire un langage le plus productif possible. Et le fossé en termes d‟efficacité entre Python
et d‟autres langages modernes se voit ligne après ligne pour les développeurs : le code
saisi est en général immédiatement fonctionnel et s‟écrit sans hésitation. [Ziadé, 2006b].
- 160 -
V. Travaux connexes :
L‟auteur de l‟article [Antkiewicz, 2003] expose une approche de transformation de
type modèle vers modèle, cette transformation consiste de générer un modèle simplifié
de bases de données relationnel ( BD relationnel) cible à partir d‟un modèle source
simplifié d‟ UML.
Le modèle UML est modélisé par des classes, des attributs et des associations
par contre le modèle relationnel est caractérisé par des tables, des colonnes, des clés
primaires et des clés étrangères .Cette transformation utilise un méta-modèle inclut quatre
entités (class, table, attribute, column) et cinq relations (contains, type , association , traceability,
consists Of) ,ou la relation association est réflexive.la figure 3.18 extraite de [Antkiewicz, 2003]
présente un méta-modèle commun pour modéliser le modèle d‟UML et le modèle de base de
données relationnel.
Figure 3.18 un méta-modèle commun pour modéliser le modèle d‘UML et le modèle
de base de données relationnelle (Common Uml and Rdbms Meta-model) [Antkiewicz,
2003]
- 161 -
Cette approche convertit le modèle UML source vers le modèle de bases de données
relationnel cible suivant une grammaire de transformation nommée (Uml2Rbms), elle comporte
un ensemble de règles de transformation .la figure3.19 extraite de [Antkiewicz, 2003] présente
une boite de dialogue utilisée pour éditer la transformation „‟Uml2Rdbms‟‟, à la droite de chaque
règle le nombre indique l'ordre d‟exécution du règle.
Figure 3.19 Une Boite de Dialogue utilisée pour éditer la transformation ‘Uml2Rdbms‘‘
Dans l‟article [Ximeng ,2007], Ximeng étudie la possibilité de modéliser les
diagrammes de séquence « Sequence Diagram », de les transformer automatiquement
vers les Statecharts (diagrammes d‟´états-transitions), et de générer automatiquement de
texte de conditions des diagrammes de séquence .Il a réalisé un outil de modélisation qui
convertit les diagrammes de séquence vers les diagrammes d‟état transition et de générer
du texte en s‟ appuyant sur une transformation constituée de quarante règles .
[Vangheluwe, 2004] crée un méta-modèle pour modéliser la syntaxe de réseau du
trafic de véhicule, en s‟appuyant sur le formalisme E/R.
La sémantique a été attribuée par la transformation des modèles de trafic vers le modèle
de Pétri Nets (mapping Traffic models onto Petri Net models).
- 162 -
Les auteurs de l‟article [Kerkouche, 2009], proposent une approche pour la
transformation des diagrammes de Statechart et de collaboration d‟UML vers le modèle
de réseau de Petri colorés. (Transformation de graphes).
L‟objectif de cette transformation est d‟établir un lien entre la notation informel
(diagrammes d'UML) et une notation plus formel (modèles de réseaux de Pétri colorés).
L‟architecture de cette transformation est présentée dans la figure 3.20.
Figure 3.20: L‘architecture de la transformation [Saldhana, 2001]
Pour convertir les Statechart vers les modèles FSM, ils ont suggéré vingt-trois règles de
transformation appliquées dans un ordre ascendant, ces règles constituent la grammaire de
transformation proposée „‟Statechart2FSM‟‟, la règle de transformation n022 est donnée dans la
figure 3.21.
Figure 3.21 : la présentation de la règle 22
- 163 -
Dans l‟article [De Lara ,2004], les auteurs décrivent une transformation de type modèle
vers code (génération de code OOCSMP33 à partir de modèle graphique OOCSMP).
Cette tâche peut être effectuée en utilisant une grammaire de transformation, dont
l'action initiale est de créer un fichier pour stocker le code d'OOCSMP et ajoute un
attribut supplémentaire (visité) à tous les nœuds du graphe (c'est-à-dire, à toutes les
classes dans le modèle). Cet attribut indique si le code pour ce nœud a été déjà produit, et
est initialisé à 0).
Les auteurs de [De Lara ,2004], affirment qu‟il y a des manières plus efficaces pour
générer du code à partir des modèles visuels .Par exemple, écrire des algorithmes en Python
pour accéder à API34
d‟ATOM3 et rechercher les éléments de modèle puis générer le code
équivalent à chaque élément..
D‟une manière similaire de l‟approche précédente, les auteurs de L‟article [De Lara
,2002c] suggèrent un méta-modèle pour les diagrammes CBD (Causal Block Diagram)
édité par l‟outil de modélisation multi-paradigmes (ATOM3), puis les convertir vers le
code OOCSMP .La figure 3.21 englobe le méta-modèle de cette transformation.
33
OOCSMP (Object Oriented Continuous Simulation Language) Il est basé sur l'ancien langage de simulation
CSMP, avec quelques extensions:
Est orienté objet.
Est capable de résoudre des équations aux dérivées partielles, et il a un générateur de maillage graphique
(MGEN).
Peut gérer des événements discrets.
Il est possible d'inclure des éléments multimédias dans la simulation, et de les synchroniser avec l'exécution de
la simulation.
C-OOL est le compilateur pour ce langage, il travaille dans Windows 95 et il est capable de générer trois
langues objet différent avec les modèles OOCSMP:
Plain C + +.
C + + / Amulet.
Java. 34
Une interface de programmation (Application Programming Interface ou API) est une interface fournie par
un programme informatique. Elle permet l'interaction des programmes les uns avec les autres de manière
analogue à une interface homme-machine rend possible l'interaction entre un homme et une machine.
- 164 -
Figure 3.22 : Un méta-modèle pour les CBDs, exprimés en formalisme E/R (Meta-model of
CBDs, expressed in the ER formalism)
[Sen, 2009], cet article décrit la transformation les diagrammes de classes, leurs
propriétés et l‟ensemble des contraintes vers les facts d‟ALLOY.
ALLOY 35
est un langage déclaratif qui exprime les structures complexes des contraintes ,
elle fournit un outil de modélisation basé sur la logique de premier ordre .Les fondements
mathématiques de ce langage ont été fortement influencés par la notation Z .Les modèles d‟
ALLOY sont de nature relationnelle ,et sont composés de plusieurs différent types de
déclarations . La section suivante inclut la transformation d‟une classe vers une signature
d‟ALLOY.
sig State
{
label: Int,
outgoing Transition: set Transition,
35
http://alloy.mit.edu/alloy4/
- 165 -
incomingTransition: set Transition,
fsmCurrentState: one FSM,
fsmStates: one FSM,
isFinal:oneBool,
isInitial:oneBool
}
[Spencer, 2003] propose une transformation des Statecharts vers DEVS36 en utilisant
l'environnement de méta-modélisation AToM3. Spencer présente un générateur de code
qui convertit automatiquement les Statecharts vers DEVS.
Dans l‟article [Boudiaf ,2009], les auteurs proposent une traduction automatique de
réseau de Pétri colorés37 « Colored Petri Nets » (CPN) vers Maude (basée sur la logique
de réécriture) .L‟outil suggéré par [Boudiaf ,2009] permet d‟éditer et simuler les graphes
GPN, puis les traduire automatiquement vers les spécifications Maude.
36
DEVS (de l'anglais Discrete Event System Specification) est un formalisme modulaire et hiérarchique pour
la modélisation, la simulation et l'analyse de systèmes complexes qui peuvent être des systèmes à événements
discrets décrits par des fonctions de transitions d'états et des systèmes continus décrits par des équations
différentielles, par exemple et des systèmes hybrides (continus et discrets). 37
Définition formelle : Un réseau de Petri coloré est un 6-uplet <P, T, C, W-, W+, M0>
• P est l‘ensemble des places, T est l‘ensemble des transitions (P ∩ T = Ø, P ∪ T ≠ Ø)
• C définit pour chaque place et chaque transition son domaine de couleur
• W- (= Pré) (resp. W+ = Post), indexée sur P x T, est la matrice d‘incidence arrière (resp. avant) du réseau
• W-(p, t) et W+ (p, t) sont des fonctions linéaires de couleurs définies de Bag(C(t)) dans Bag(C(p))
•M0 est le marquage initial du réseau ; c‘est un vecteur indexé par P et M0(p) est un élément de Bag(C(p))
• Les transitions peuvent être gardées par une fonction Bag(C(t)) → {0, 1}
• Les domaines de couleurs sont généralement des produits cartésiens
Soit CN = <P, T, C, W-, W+, M0> un réseau coloré.
• Un marquage M de CN est un vecteur indexé par P, avec M(p) ∈ Bag(C(p))
• Une transition t est franchissable pour une instance ct ∈ C(t) et un marquage M si et seulement si :
– Soit t est non gardée, soit la garde vaut 1 (= vrai) pour ct
– ∀ p ∈ P, M(p) ≥ W-(p, t)(ct)
•Le marquage M‘ atteint après le franchissement de t pour une instance ct à partir du marquage M est défini
par :
∀ p ∈ P, M‘(p) = M(p) - W-(p, t)(ct) + W+(p, t)(ct)
On note : M [(t, ct)> M‘
(t, ct)
M → M‘
- 166 -
Dans [El Mansouri, 2008], ils ont proposé une approche basée sur la combinaison de la
méta-modélisation et la grammaire des graphes afin générer un outil visuel pour
modéliser les ECATNets ; les ECATNets représentent une catégorie de réseau de pétri
algébrique. Dans leur progression, ils sont créé un méta-modèle pour ECATNets en
utilisant le formalisme des digrammes de classe d‟UML.
L'outil de méta-modélisation ATOM3, lui est utilisé pour produire un outil de
modélisation visuel selon le méta-modèle proposé d'ECATNets. Puis ils ont proposé une
grammaire de graphe composé de sept règles de transformation pour générer la description en
Maude.
- 167 -
VI- Conclusion
La transformation modèle vers code ou génération de code demeure l‟une des
transformation pertinente, elle consiste de réaliser un méta-modèle pour spécifier les concepts
appropriés de sous-système à modéliser puis de parcourir le méta-modèle en traduisant les
fragments de ce méta-modèle vers un langage cible .Une telle transformation a pour objectif est
d‟établir un lien entre la notation informel et la notation plus formel et d‟enrichir la sémantique
de modèles ambigües.
Parmi les langages cibles adoptées le langage MAUDE.
Maude est un langage formel, il s‟appuie sur la logique de réécriture et il bénéficie
d‟une forte sémantique mathématique.
Maude est un langage parfait pour la spécification de système. Comparativement à des
langages tels Object-Z38
ou B39
, Maude aura l‟avantage absolu de permettre la définition de ses
propres notations (Maude est un méta langage). Ceci rend Maude beaucoup plus expressif et
beaucoup plus aisé à comprendre comparativement aux notations abstraites et mathématiques
d‟Object-Z et autres.
38
http://www.itee.uq.edu.au/~smith/objectz.html 39
http://www.methode-b.com/
- 168 -
CHAPITREIV
LA LOGIQUE DE REECRITURE
ET MAUDE
I- Introduction.
II- La logique de Réécriture.
III- Maude.
IV- Travaux connexes.
V- Conclusion.
- 169 -
III. Introduction
La logique de réécriture (II) a été introduite par José Meseguer [Meseguer, 1992]
[Bruni, 2006], Elle propose une sémantique saine et complète pour décrire les systèmes
concurrents. Basée sur un outil mathématique formel, la logique de réécriture unifie plusieurs
modèles formels qui expriment la concurrence. D‟une part et d‟une autre part elle enrichie les
modèles possédant une syntaxe puissante mais une sémantique pauvre ou insuffisante comme
les diagrammes d‟UML. Car UML étant un langage à caractère plutôt visuel, il souffre d‟un
manque de sémantique formelle.
La logique de réécriture (II.1) suggère une manière correcte de raisonnement sur les
systèmes concurrents non-déterministes ayant des états qui évoluent à travers des transitions. La
sémantique de la logique de réécriture dite sémantique de „vraie concurrence‟ permet de
modéliser n‟importe quel comportement concurrent des systèmes concurrents en utilisant des
déductions de cette logique.
Dans la logique de réécriture les unités de base de la spécification sont appelées théories
(II.2) qui sont de deux types : les théories fonctionnelles et les théories systèmes.
Pour définir les théories fonctionnelles et systèmes, la logique de réécriture utilise des
concepts de base (II.3).
Mais comment la logique de réécriture offre cette sémantique saine et puissante, pour
décrire des techniques développées et appliquées pour modéliser les systèmes concurrents
basés sur les spécifications formelles efficaces , la logique de réécriture réunit un ensemble de
règles de réécriture .
Par conséquent, une règle de réécriture [Meseguer, 2006] a été habituellement interprétée
comme équation dirigée t = t'. La logique de réécriture est un élargissement cohérent de la
sémantique donnée aux règles de réécriture. La lecture équationnelle est abandonnée, en faveur
d'une interprétation plus dynamique. Il y a maintenant en fait deux lectures complémentaires
d'une règle, une lecture informatique, et une lecture logique différente :
(i) informatique, la règle de réécriture est interprétée comme transition locale dans un
système concurrent.
- 170 -
(ii) logique, la règle de réécriture est interprétée comme règle d'inférence. L'expérience
acquise suggère jusqu'ici fortement que la réécriture soit en effet un formalisme très
flexible et général pour des applications informatiques et logiques. Ceci signifie que
la logique de réécriture de point de vue sémantique est très expressif, dans lequel
beaucoup de différents modèles simultanées, de systèmes distribués peuvent être
spécifiés et programmés ; et d'un point de vue logique il offre un cadre logique
général dans lequel beaucoup de différentes logiques peuvent être représentées et
mises en application.
Maude (III) est un langage de haut niveau, il est aussi doté d‟un système de haut
performance [Clavel ,2001].
Maude (III.1) est un langage basé sur la logique de réécriture. Maude est l‟un des
langages les plus puissants dans la spécification formelle, la programmation et la vérification des
systèmes concurrents.
En plus d‟être un langage simple, expressif et performant, Maude basé sur de solides
fondements mathématiques, Maude qui permet la définition de ses propres notations (MAUDE
est un méta langage) peut être désigné principalement pour enrichir la sémantique des
systèmes et modéliser la concurrence (III.2).
Maude permet de programmer à deux niveaux différents (III.3) : Core Maude et Full
Maude.
L‟unité de base pour le développement Maude est le module. Il en existe trois types (III.4)
: les modules fonctionnels, les modules système et les modules orientés-objet.
La programmation des différents modules inclut la définition des concepts du language
MAUDE (III.5).
Les travaux connexes (V) représentent un survol sur la transformation des diagrammes
d‟UML vers Maude.
Ce chapitre présente les concepts principaux de la logique de réécriture et de Maude, et
discute les concepts et les théories proposées par ces deux axes.
- 171 -
II. La logique de Réécriture
II. 1 Présentation de la logique de Réécriture
La logique de réécriture, introduite par José Meseguer [Meseguer, 1992], est une logique
dans laquelle les théories sont des systèmes de réécriture. Les règles de réécriture sont étiquetées,
et sont donc de la forme l : l r où l est une étiquette. Chaque règle de réécriture étiquetée
peut être considérée dans cette logique comme une action élémentaire. Les formules sont des
séquents de la forme π : t t‘ indiquant que t se réécrit en t‟ via π, avec π = t [`l (σ x)] ϖ un
terme de preuve.
On peut définir un pas de réécriture simple par t l ,σ , ϖt '
Ce terme de preuve sert à garder la trace des différentes applications de règles de
réécriture étiquetées qui permettent de décrire la dérivation qui mène de t à t‟. Il contient les
informations sur quelle règle est appliquée à quel terme, avec quelle substitution, et à quelle
position. La logique de réécriture utilise les règles de réécriture pour calculer une relation de
“réécrivabilité” entre les termes. Elle permet d‟exprimer qu‟un terme peut être réécrit en un autre.
Dans la logique de réécriture, les systèmes concurrents sont représentés par une théorie
de réécriture = (Σ, E, L, R). Ou la structure statique est décrite par la signature (Σ, E), tandis
que la structure dynamique est décrite par les règles de réécriture R.
Une théorie de réécriture est une description statique d'un système concurrent. Sa
sémantique est définie par un modèle mathématique qui décrit son comportement. Le modèle
pour une théorie de réécriture étiquetée = (Σ, E, L, R), est une catégorie (X) dont les objets
(états) sont des classes d'équivalence des termes [t] TΣ, E (X) et dont les morphismes
(transitions) sont des classes d'équivalence des termes-preuves (proof-terms) représentant des
preuves dans la déduction de réécriture.
- 172 -
II.2 Les théories de la logique de réécriture :
La logique de réécriture est basée sur des unités de spécification appelées théories qui
sont de deux variantes [Megzari, 2004] : les théories fonctionnelles et les théories systèmes.
Les théories fonctionnelles : représentent des théories dans la logique équationnelle
d‟appartenance appelée MEL (MembeShip Equational Logics) qui est équivalente à la
logique de Horn. Les phrases dans MEL sont des égalités de la forme t=t‘ ou bien des
assertions d‟appartenance de la forme t:s exprimant que t est de sorte s. Une telle logique
inclut la logique équationnelle des sortes ordonnées (order-sorted OBJ3) et inclut ainsi
les sortes, les relations sous-sorte, la surcharge des opérateurs, et la définition des
opérations.
Les théories fonctionnelles spécifient les sortes de données et les opérations sur ces
données à travers des théories équationnelles. Les sortes de données se composent des éléments
qui peuvent être appelés par des termes. Deux termes dénotent le même élément si et seulement si
ils appartiennent à la même classe d'équivalence déterminée par les équations. La sémantique
d'une théorie fonctionnelle est son algèbre initiale. Les théories fonctionnelles ont la propriété
suivante : l'application répétée des équations comme règles de simplification jusqu'à l‟obtention
par la suite un terme à laquelle aucune autre équation ne s'applique. Le résultat, appelé forme
canonique, est le même quelque soit l'ordre de l'application des règles. Ainsi chaque classe
d'équivalence a un représentant normal, sa forme canonique, qui peut être calculé par
simplification équationnelle.
Une théorie fonctionnelle est déclarée suivant la syntaxe :
fmod<Théorie Name> is [<DeclarationsAndStatements>] endfm
Les théories systèmes : elles spécifient le modèle initial TR0 d'une théorie de réécriture
TR. Ce modèle initial est un système de transitions dont :
- Les états sont des classes d'équivalence [t]des termes t modulo les équations E
définies dans R,
- Les transitions sont des « α-Preuves » de la forme : [t] → [t'].
Une théorie système de la logique de réécriture définit une théorie de réécriture. Une
théorie de réécriture inclut des sortes, et des opérations, et peut avoir des : équations, axiomes
d‟appartenance, et règles qui peuvent être conditionnelles. Par conséquent, n'importe quelle
- 173 -
théorie de réécriture inclut une théorie équationnelle fondamentale, contenant les équations et les
appartenances, plus les règles de réécriture.
Informatiquement, les règles spécifient les transitions concourantes locales qui peuvent
être exécuté dans un système si le patron dans le côté gauche de la règle correspond à un
fragment de l'état de système et la condition de la règle est satisfaite. Dans ce cas, la transition
indiquée par la règle peut s‟exécuter, et le fragment de l'état correspondant est transformé en
l‟instance correspondante du côté droit. Une théorie système est déclarée suivant la syntaxe :
mod<Théorie Name>is<DeclarationsAndStatements>endm
La théorie système inclut : importations, sortes et sous-sortes, opérations, variables,
équations et axiomes d‟appartenance (conditionnels et non conditionnels) et règles de réécriture
(conditionnelles et non conditionnelles).
Les théories systèmes ajoutent les règles de réécriture par rapport aux théories
fonctionnelles.
II. 3 Les concepts de théorie de Logique de Réécriture
Plusieurs concepts de base sont liés à la logique de réécriture, citons [Reilles ,2006]
[Reilles ,2003] [Alouini ,1997] :
Définition 4.1 : (opérateurs) est un ensemble d‟opérateurs (symboles de fonctions) muni de
la fonction arité : N qui associe à un symbole de fonction l‟arité du symbole. n
désigne le sous ensemble de fonctions d‟arité n.
Définition 4.2 : (signature) une signature dans la logique de réécriture est une paire
(avecalphabet de symboles de fonctions et E un ensemble de équations .la réécriture
opère sur les classes d‟équivalence modulo l‟ensemble d‟équations E.
Définition 4.3 : (Termes) les termes sur sont définis comme un ensembleT (, X),par les règles
:
Chaque variable x X est un terme de T (, X).
Si t1,…, tn sont des termes de T (, X), respectivement, et si falors f (t1,…, tn) est un terme
de T (, X).
Définition 4.4 : (algèbreune algèbre A est alors u ensemble non vide de valeurs A et
avec une fonction fA : An A pour chaque f
navec n N.
- 174 -
Définition 4.5 : (Algèbre quotient des termes) soient ± un ensemble d‟opérateurs, X un
ensemble de variables et E l a plus petite relation de congruence contenant l‟ensemble des
axiomes E , alors l‟ensemble quotient des termes T E (X) est l‟ensemble
T E (X) ={[u]E / u T(X) }ou [u]
E est la classe d‟équivalence définie par
[u]E= {v/v T( E),v
E
u }.
Définition 4.6 (formules de la logique de réécriture) : les formules de la logique de réécriture
pour une signature (S, E) sont de la forme[t]E
[t‘]E
Où [t]E. [t‘]E
sont de classes d‟’équivalences
de termes t, t‘dans l‟ensemble quotient des termes modulo E.
Définition 4.7 (substitution) : soittT ({x1,………… x
n}), et les termes u
1,…..u
n,
c‟est le terme obtenu à partir de t, par une des substitutions simultanéesuipour x
i ,i=1,…..n.
.Notée (u~/x~)
Définition 4.8 : (Séquent de réécriture) Soit la signature (, X.). Les formules dans la
logiquede réécritures ont des ‘’séquents‟‟ de la forme(π : [t]E
[t’]E ,ou t,t’
Tx),π(L{;}F Txouest un opérateur binaire infixe ,π est appelée terme
de preuve .
Les sens informel du séquent (π : [t]E
[t’]E est que le calcul π permet de dériver
t’ de t .Les termes de preuves formalisent les preuves de la logique de réécriture en affectant à
chaque preuve un terme d‟une structure algébrique des preuves .Un terme de preuve est une
formalisation d‟une preuve en logique de réécriture .il contient les informations sur la
construction d‟une formule valide .(les informations sur les règles de déduction appliquées et
sur les paramètres )
Définition 4.9 (Une théorie de réécriture) : est une 4-tuple = (Σ, E, L, R), tel que (Σ, E)
est une signature ;
- Σ est un ensemble des sortes et opérations, et E est un ensemble de Σ-équations.
- La signature (, E) est une théorie équationnelle qui décrit la structure algébrique
particulière des états du système (multi-ensemble, arbre binaire, etc...) qui sont distribués
selon cette même structure.
- 175 -
- L‟ensemble R L (T,E(X))2 est l‟ensemble des pairs tel que le premier composant est
une étiquette et le second est un pair des classes d‟équivalence des termes modulo les
équations E, avec X = {x1,…,xn,…} un ensemble comptable et infini des variables. Les
éléments de R s'appellent les règles conditionnelles de réécriture. Ils décrivent les
transitions élémentaires et locales dans un système concurrent. Chaque règle de réécriture
correspond à une action pouvant se produire en concurrence avec d'autres actions. La
réécriture opérera les classes d'équivalence des termes, modulo l'ensemble des équations
E.
- Pour une règle réécriture (r, [t], [t’]), ([u1],[v1]),…., ([uk],[vk]) ), nous utilisons la
notation : r : [t] [t’] if [u1] [v1] … [uk] [vk], tel que [t] représente la classe
d‟équivalence du terme t. Une règle r exprime que la classe d‟équivalence contenant le
terme t a changé à la classe d‟équivalence contenant le terme t’ si la partie conditionnelle
de la règle, [u1] [v1] …. [uk] [vk], est vérifiée. Etant donné une théorie , nous
disons qu'une séquence r : [t] [t’] est prouvable dans ou r:
[t] [t’] est -réécriture concurrente et nous écrivons - r : [t] [t‘]
Ssi [t] [t‘]
Définition4.10 : (les règles de déduction de la logique de réécriture) soit une théorie de
réécriture = (Σ, E, L, R), nous disons que R implique un séquent
[t] [t‘] et on écrit R [t] [t‘] si et seulement si le séquent peut être obtenu par une
suite finie d‟application des règles de déduction suivantes [Narciso, 2001] [Oliet ,1996] :
1- Réflexivité. Pour chaque ,[ ] ( ),Et T X[ ] [ ]t t
2- Congruence. Pour chaque n
nf ,
' '
1 1
' '
1 1
[ ] [ ] ... [ ] [ ]
[ ( ,..., )] [ ( ,..., )]
n n
n n
t t t t
f t t f t t
3- Remplacement. Pour chaque règle de réécriture 1 1:[ ( ,..., )] [ '( ,..., )]n nr t x x t x x dans R,
' '
1 1
_ _ _ _
[ ] [ ] ... [ ] [ ]
[ ( / )] [ '( '/ )]
n nw w w w
t w x t w x
Tel que _ _
( / )t w x indique la substitution simultanée des iw pour ix dans t.
- 176 -
4- Transitivité.1 2 2 3
1 3
[ ] [ ] [ ] [ ]
[ ] [ ]
t t t t
t t
La règle de transitivité dit comment créer un séquent par composition de séquents. La
congruence dit que la relation de réécriture est compatible avec la structure algébrique et exprime
la réduction parallèle .La règle de remplacement décrit la réduction simultanée de deux radicaux
compatibles
Tandis que la logique équationnelle (modulo un ensemble d‟axiomes E) est définie à partir de
la logique de réécriture en ajoutant les règles de déduction suivantes : [Meseguer, 1990]
5. Symétrie :
Cette règle de symétrie rend les séquences dérivées dans la logique équationnelle
bidirectionnelle, d‟où la notation [t] [t‘] est permise, cette séquence bidirectionnelle est
appelée une équation. [Oliet ,1996].
La figure 4.1 schématise les règles d‟inférence d‟une théorie de réécriture
- 177 -
Figure4.1 : Visualisation des règles d‘inférence d‘une théorie de réécriture
Définition 4.11 : soit une théorie de réécriture = (Σ, E, L, R), un (Σ, E) séquent
[t] [t‘] est appelé R-réécriture concurrente si et seulement si, il peut être dérivé à partir de R
par l‟application finie des règles 1-4.
Il existe plusieurs systèmes basés sur la logique de réécriture, souvent utilisés comme
systèmes de spécification. Pour certains de ces systèmes, cette logique n‟est pas seulement un
outil d‟implantation, mais aussi un paradigme de calcul offert à l‟utilisateur. Parmi ceux-ci, on
peut citer ASF-SDF40
[Deursen, 1996], Maude41
[Clavel, 1998a], ELAN42
[Borovanský, 1998]
et CafeOBJ43
.
40
- http://www.meta-environment.org/Meta-Environment/ASF%2BSDF 41
- http://maude.cs.uiuc.edu 42
- http://www.elan.com 43
- http://www.ldl.jaist.ac.jp/cafeobj
- 178 -
III. Maude
III. 1 Présentation de Maude
Représente un système développé au SRI44
par l‟´équipe de José Meseguer [Clavel
,1998b]. Maude [Meseguer, 2000] représente aussi un langage de spécification et de
programmation basé sur la logique de réécriture. Il intègre actuellement les paradigmes de
programmation fonctionnelle et objet.
Maude offre peu de constructions syntaxiques mais il offre une sémantique bien définie.
Sa sémantique est fondée sur la logique équationnelle d‟appartenance [Meseguer, 1998]
[Bouhoula, 1996] [Bouhoula ,1997].Cette logique, similaire à celle développée dans
[Hintermeier, 1994], [Hintermeier,1995], est une extension conservatrice de la logique
équationnelle avec sortes ordonnées et de la logique équationnelle partielle. Maude permet le
sous-typage, la définition d‟opérateurs partiellement définis et la surcharge d‟opérateurs.
Maude est un language marqué par [Clavel, 2010] :
- La simplicité : Un programme doit être le plus simple possible et aussi facile à
comprendre. Il doit également posséder une sémantique très claire.
- La performance : Maude est un langage concurrentiel en termes d'exécution avec
d‟autres langages de la programmation impérative, il peut exécuter des millions de
réécriture par seconde, cela permet la vérification de différents chemins d‟exécution
possibles dans une spécification.
- L‘expressivité : Il est possible d‟exprimer naturellement une vaste gamme d‟applications.
Il est aussi possible de le faire autant pour un programme déterministe que pour un
programme hautement concurrentiel. Maximiser l‟expressivité du langage est sans doute
l‟une des avantages les plus remarquables du langage Maude. Dans ce contexte, Maude
devrait alors être vu comme un métalangage avec lequel il est très aisé de développer un
langage spécifique.
44
http://www.sri.com.
- 179 -
III. 2 Les caractéristiques de Maude
Les caractéristiques clés de Maude peuvent être résumées comme suit [Clavel, 1996a] :
Maude est un langage déclaratif de haut niveau et aussi un système de haute performance
défini par J. Meseguer, il constitue la seule implémentation de la logique de réécriture qui
emploie d‟une manière systématique et efficace le mécanisme de réflexivité.
Maude est un langage basé sur la logique de réécriture (Based on rewriting logic), ou les
programmes sont des théories de la logique de réécriture, c‟est à dire une signature et un
ensemble de règles de réécriture.
Maude est multi paradigme (Multiparadigm), il supporte et combine la programmation
fonctionnelle, système et orienté objet et il inclut en plus un certain nombre de modules
prédéfinis permettant de faciliter la tâche de spécification et de vérification.
Maude est réflective [Clavel ,1998 b] [Clavel, 1996b] [Clavel, 1996c], la logique de
réécriture est réflective. le design de Maude capitalise pour cela le fait de supporter un
nouveau style de méta programmation ( metaprogramming ) avec le pouvoir des
opérations des combinaison de modules (module-combining) et la transformation de
module (module-transformation), pour dépasser la programmation traditionnelle
paramétrée et augmenter la réutilisation et l‟adaptabilité du software .
Maude est caractérisé par un spectre large (wide-Spectrum), la logique de réécriture
présente une structure sémantique et logique dans laquelle la spécification, le
prototypage rapide et l‟efficace exécution parallèle et distribuée , aussi bien que la
transformation formelle depuis les spécifications vers les programmes peut être
naturellement supportés [Lincoln, 1994].
Maude est un méta langage, il permet la définition de ses propres notations. Ceci rend
Maude beaucoup plus expressif et beaucoup plus aisé à comprendre comparativement aux
notations abstraites et mathématiques d‟Object-Z et autres.
Maude est qualifié par les stratégies internes (internalstrategies) : ces stratégies
permettent de contrôler et de guider le processus de réécriture dont la sémantique est
définie par les règles de réécriture à l‟intérieur de la logique. Pour Maude la logique
inclut le contrôle „‟control logic ‟‟.
Maude est aussi utilisé pour : la spécification, le prototypage, la vérification d‟une large
gamme d‟applications. Différents formalismes et logiques ont été décrits en Maude.
- 180 -
Maude est influencé par le langage OBJ345, plus précisément la partie équationnelle de
Maude inclut OBJ3 comme sous langage.
Maude est doté d‟un ensemble d‟outils permettant de simplifier la fonction de la
vérification, par exemple :
- Le Model Checker : cet outil vérifie les propriétés temporelles linéaires des
modèles de systèmes spécifiés en Maude et il éprouve aussi les propriétés
invariantes à l‟aide de la commande search.
- Prouveur de Théorème ("Inductive Theorem Prover") (ITP) : cet outil vérifie
interactivement les propriétés des spécifications équationnelles.
- Le vérificateur de cohérence Maude Coherence Checker (MCC) : cet outil vérifie
la cohérence des modules systèmes.
- Le vérificateur Church-Rosser (Church-Rosser Checker) (CRC) : cet outil teste
si une spécification équationnelles à sortes ordonnées respecte ou non la propriété
Church-Rosser.
- L‟analyseur de terminaison (Maude TerminationTool) (MTT) : cet outil inspecte
la terminaison des spécifications équationnelles Maude.
Maude est basé sur une logique très mathématique et dispose d‟une forte sémantique. Ainsi,
Maude satisfait au critère suivant : être basé sur les mathématiques que les langages de
spécifications formelles ont tous en commun. De fait, un programme Maude doit être vu
comme un énoncé d‟une théorie de réécriture. Ainsi, l‟exécution de ce programme doit être
interprétée comme une déduction logique à partir des axiomes définis dans le programme. La
figure 4.2 présente les équivalences qui existent entre l‟exécution d‟un programme
informatique, une théorie de réécriture et la logique mathématique.
45
http://cseweb.ucsd.edu/~goguen/sys/obj.html
- 181 -
Figure 4.2 : Parallèle entre un programme informatique, une théorie de réécriture et la
logique mathématique
- 182 -
III.3 Les niveaux de programmation de Maude :
Maude permet de programmer selon deux niveaux distincts : Core Maude et Full Maude
Core Maude : Core Maude représente le niveau de base de Maude, il est programmé
directement en C++. Il implémente toutes les fonctionnalités de base du logiciel, les
modules fonctionnels et les modules systèmes.
- Les modules fonctionnels sont principalement utilisés pour la définition de types de
données et d‟opérateurs via la théorie des équations.
- Les modules système : Les modules systèmes, quant à eux, sont utilisés pour définir des
théories de réécriture. D‟une certaine façon, tout comme la logique de réécriture est plus
générale que la logique des équations, un module système englobe un module fonctionnel.
Full Maude : Full Maude représente le niveau supérieur, il est programmé en Core
Maude développé par Francisco Durân, Full Maude est une extension du premier niveau
(Core Maude), avec lequel il est possible de combiner des modules pour améliorer le
développement. Full Maude offre de nombreux avantages. Il est surtout utilisé pour
spécifier le paradigme de programmation orienté-objet et les modules orientés-objet
Maude. [Clavel, 2007a] [Clavel, 2007b] [Durán, 1999].
- Les modules orientés objets : Ce dernier type de module est développé spécifiquement
pour le paradigme de développement orienté-objet. Ce type de module est utilisé au
niveau de Full Maude. Il permet de définir la syntaxe nécessaire pour déclarer des classes,
des sous classes et des messages.
- 183 -
III.4 Les modules de Maude :
Maude propose trois types de modules :
Modules systèmes : Tout comme la logique de réécriture qui inclut la logique des
équations ensemblistes, les modules systèmes incluent les modules fonctionnels.
Un module système spécifié une théorie de réécriture, il a donc la forme :
Mod(∑, E,R) endm où (∑, E,R) correspond à une théorie de Réécriture. Ce type de
modules établit une extension des modules fonctionnels par l‟introduction des règles de
réécriture conditionnelles et non conditionnelles.
Sémantiquement, les règles de réécriture expriment le comportement dynamique d‟un
système. Une règle spécifie une „transition concurrente locale‟ qui peut se produire dans un
système si la partie gauche de la règle correspond à un fragment de l‟état du système avec la
condition étant satisfaisante.
Syntaxiquement, Une règle de réécriture sous Maude peut avoir deux variantes:
Une règle de réécriture non conditionnelle est déclarée comme suit :
rl [<Label >] : <Term-1 > =><Term-2 > [< attributs de la règle >] .
Une règle de réécriture conditionnelle est déclarée comme suit:
crl [<Label >] : <Term-1 > =><Term-2 > if <Condition-1 > /\ ... /\ <Condition-k >
[< attributs de la règle >].
Où les conditions d‟application des règles peuvent contenir en plus des équations et des
assertions d‟appartenance des expressions de réécriture de la forme t t‟.
Figure 4.3: Un Petri Net
- 184 -
La figure 4.4 illustre un exemple d‟un module système nommé VENDING-MACHINE
extrait de [Clavel, 2010].Il consiste en la représentation Maude du système décrit à la figure 4.3 à
l‟aide d‟un Petri Net, un des modèles de concurrence les plus simples. Le programme consiste en
un automate représentant une machine distributrice très simple. Les entrées sont les suivantes :
- $ représente l‟entrée d‟une pièce de 1$ dans la machine ;
- c représente un bonbon ;
- a représente une pomme ;
- q représente une pièce de 25 cents.
Le système permet donc l‟achat d‟un bonbon à 1 $ et l‟achat d‟une pomme pour 0,75 $.
La machine fait aussi la monnaie : pour quatre pièces de 0, 25 $, elle retourne une pièce de 1$.
mod VENDING-MACHINE is
including VENDING-MACHINE-SIGNATURE .
var M : Marking .
rl [add-q] : M => M q .
rl [add-$] : M => M $ .
rl [buy-c] : $ => c .
rl [buy-a] : $ => a q .
rl [change] : q qqq => $ .
endm
La figure 4.4 : Le module système VENDING-MACHINE [Clavel, 2010]
- 185 -
Modules fonctionnels : un module fonctionnel représente une théorie équationnelle dont
ses équations sont utilisées de gauche à droite comme des règles de simplification pour
atteindre la forme canonique. Un module fonctionnel a donc la forme : fmod (∑, E) endfm
avec (∑, E) correspond à une théorie équationnelle d‟appartenance.
Un module fonctionnel spécifie les types de données et les opérations appliquées sur
ces types en exécutant un ensemble d‟équations conditionnelles et/ou non conditionnelles. Les
équations non conditionnelles sont déclarées en utilisant le mot clé eq, suivi par un terme, suivi
par le signe d‟égalité =, suivi par un autre terme, et optionnellement suivi par une liste d‟attributs
équationnels, et terminé par un espace et un point, alors le schéma général d‟une équation non
conditionnelle et comme suit :
eq<Term-1 > = <Term-2 > [<attributs de l‘équation>] .
Pour les équations conditionnelles, leur forme est la suivante :
ceq<Term-1 > = <Term-2 > if <EqCondition-1 > /\ ... /\ <EqCondition-k > [<attributs
de l‘équation>] .
Où EqCondition-i représente la condition d‟exécution de l‟équation, elle peut avoir trois
interprétations :
- Des équations dites ordinaires de forme t = t';
- Des équations dites d‟affectation de forme t:=t';
- Des équations dites booléennes abrégées de la forme t, où t est un terme de sorte Bool.
La figure 4.5 illustre un exemple d‟un module fonctionnel nommé BOOL-OPS extrait
de[Clavel, 2010].Le module BOOL-OPS [Clavel, 2010] importe TRUTH-VALUE et ajoute
les opérations logiques usuelles : la conjonction, la disjonction, Le ou exclusif , la négation, l‟
implication.
- 186 -
fmod BOOL-OPS is
protecting TRUTH-VALUE .
op _and_ : BoolBool ->Bool [assoccommprec 55] .
op _or_ : BoolBool ->Bool [assoccommprec 59] .
op _xor_ : BoolBool ->Bool [assoccommprec 57] .
op not_ : Bool ->Bool [prec 53] .
op _implies_ : BoolBool ->Bool [gather (e E) prec 61] .
vars A B C : Bool .
eq true and A = A .
eq false and A = false .
eq A and A = A .
eq false xor A = A .
eq A xor A = false .
eq A and (B xor C) = A and B xor A and C .
eq not A = A xor true .
eq A or B = A and B xor A xor B .
eq A implies B = not(A xor A and B) .
endfm
La figure 4.5 : Le module fonctionnel BOOL-OPS [Clavel, 2010].
Modules orienté-objet : qui sont spécifiés uniquement dans full Maude.
En plus des modules fonctionnels et systèmes Full Maude offre au développeur un
troisième type de modules qui sont les modules orientés objet, ce type de module permet de
supporter la programmation orienté objet par l‟usage d‟une notation approprié.
Les modules objets permettent la définition des systèmes concurrents orientés objets.
Dans les systèmes concurrents orientés objets l‟état concurrent est appelé „une
configuration‟, elle est représentée par une structure d‟un multi-ensemble constitué d‟objets et
de messages. Ces derniers évoluent par réécriture concurrente modulo l‟associativité,
commutativité, et l‟élément identité en utilisant des règles décrivant les effets des événements de
communication entre les objets et les messages [Clavel, 2001]. Tous les modules orientés objets
- 187 -
incluent un module nommé „CONFIGURATION‟ qui définit les concepts de base des systèmes à
objets concurrents. Les modules orientés objet sont introduit par le mot clé „omod‟. Ils incluent
la déclaration des sortes suivantes :
Sorte Signification
Oid identificateurs d‟objets,
Cid identificateurs de classes
Objsect pour les objets •
Msg pour les messages
Tableau 4.1 : quelques sortes du modules orienté objet. [Clavel, 2010].
Un objet dans une configuration donnée est représenté par un terme :
<O : C | a1 : v1, …, an : vn>,
Où O est le nom ou l‟identificateur de l‟objet, C est l‟identificateur de la classe, les ai
représentent les identificateurs des attributs de l‟objet et les vi représentent leurs valeurs.
Les messages des modules orientés objets [Clavel, 2010] n‟ont pas une forme
syntaxique fixée, leur syntaxe est définie par l‟utilisateur pour chaque type d‟application, la seule
contrainte est que le premier argument du message doit être l‟identificateur de l‟objet destination.
La figure 4.6 présente un module orienté objet extrait de [Clavel, 2010].
- 188 -
(omod ACCOUNT is
protecting QID . *** importation du module ‗quotedidentifiers‘
protecting INT . *** importation du module des entiers.
subsortQid<Oid . *** déclarer Qid comme sous sorte de Oid
class Account | bal : Int . *** déclaration d‘une classe Account avec un attribute
de balance‘bal‘ de type int.
msgs credit debit : OidInt ->Msg . Déclarer deux messages ‗credit‘ et ‗debit‘ de type
Oid et Int respectivement.
msgfrom_to_transfer_ : OidOidInt ->Msg .
vars A B : Oid .
var M : Nat .
vars N N‘ : Int .
rl [credit] :
credit(A, M)
< A : Account | bal : N >
=>< A : Account | bal : N + M > . *** une règle de réécriture inconditionnelle crl
[debit] :
debit(A, M)
< A : Account | bal : N > =>< A : Account | bal : N - M > if N >= M . *** une règle de
réécriture conditionnelle
crl [transfer] :
(from A to B transfer M)
< A : Account | bal : N >< B : Account | bal : N‘ >
=>< A : Account | bal : N - M >< B : Account | bal : N‘ + M > if N >= M .
endom)
La figure 4.6 : Le module orienté-objet ACCOUNT [Clavel, 2010].
- 189 -
III.5 Les concepts du Maude : [Clavel, 2010] [Clavel, 2009] [Clavel, 2007a]
Le tableau 4.2 présente les éléments de base communs aux modules fonctionnels et
systèmes qui sont : les sortes, les relations de sous sorte, les opérations, les attributs des
opérations, les variables et .l‟importation de modules.
Les
concepts de
base
Définition et syntaxe Exemple
Identificateurs
(identifiers)
Dans Core Maude, les identificateurs sont des éléments syntaxiques
de base, employés pour nommer les modules et sortes, et pour former des noms
d'opérateur. Par exemple, « NAT », et « hello-Word » sont des identificateurs.
Généralement l‟identificateur dans Maude est une séquence finie de
caractères d'ASCII.
Modules dans Maude, les unités de base de spécification et de la
programmation s'appellent les modules. Le module consiste en une
déclaration de syntaxe, qui fournit un langage approprié pour décrire le
système courant, et les expressions, affirmant les propriétés d'un tel système.
La partie de déclaration s'appelle une signature et se compose de :
• sortes : donnent des noms pour les types de données,
• les subsorts : organisant les types de données dans une hiérarchie,
• les kinds (les genres ) : elles sont implicites et intuitivement
correspondent aux « super types d'erreur » cela, en plus des données normales,
peuvent contenir des « expressions d'erreur, »
• opérateurs : fournissant des noms pour les opérations qui agissent
sur les données et en nous permettant d'établir des expressions (ou termes) se
référent à telles données.
Module système :
mod
MODULENAME is
BODY
endfm.
Module fonctionnel :
fmod
MODULENAME is
BODY
endfm.
Module orienté objet
:
(omod
MODULENAME is
…..
Endom)
- 190 -
Sorte et sous
sorte
(sortesand sub
sortes )
La première chose à déclarer dans une spécification est l‟ensemble de
nouveaux types de données utilisés, dans la communauté de spécification
algébrique ces types sont appelés sorte.
Dans Maude une sorte est déclarée de la manière suivante :
sort < Sort >.
où < Sort > est l‟identificateur de la sorte, de multiple sortes peuvent être
déclarées en suivant la forme :
sorts < Sort-1> … <Sort-K>.
Les sortes dans Maude sont partiellement ordonnée via une relation de
sous sorte, cette relation est équivalente à la relation de sous ensemble dans le
type de donnée ensemble, alors
nous pouvons déclarer une relation de sous sorte en employant le mot
clé subsort ou subsorts
comme suit :
subsort<Sort-1><<Sort-2> .
subsorts<Sort-1> … <Sort-j>< … <Sort-k> … <Sort-l> .
Exemple 1 :
sort Zero .
sort Nat.
sort NzNat .
subsort
Zero< Nat.
subsortNzNat< Nat
Les
genres (kinds)
Les genres (en Maude, kinds) ne sont pas déclarés explicitement. Ils
sont plutôt inférés par le système et sont identifiés à l‟aide des classes
d‟équivalences (S,).
- 191 -
Opérations Dans le langage Maude une opération est déclarée à l‟aide du mot clé
op suivi par le nom de l‟opération, suivi par deux points, suivi par la liste des
sortes arguments de l‟opération (appelé le domaine), suivi par le symbole à
suivi par la sorte du résultat de l‟opération (appelée le Co-arité ou le rang de
l‟opération) et optionnellement suivi par la déclaration des attributs de
l‟opération suivi par un espace et un point, donc le schéma général est de la
forme :
op <OpName> : <Sort-1> .. <Sort-k> à><Sort> [<attributs de
l‟opération>] .
Exemple 2 :
op zero : -> Zero .
op s_ : Nat ->NzNat .
op sd : Nat Nat -> Nat
.
ops _+_ _*_ : Nat Nat
-> Nat
Attributs des
opérations
Le langage Maude permet la déclaration d‟un ensemble d‟attributs
pour les opérations, ces attributs sont introduits entre crochet après la sorte
résultat de l‟opération et avant le point final.
Le rôle essentiel de ces attributs est d‟offrir des informations :
syntaxiques, sémantiques, pragmatiques additionnelles sur les opérations.
Maude support plusieurs types d‟attributs nous citons à titre
d‟exemple :
ctor : pour exprimer que l‟opération est constructeur de la sorte résultat.
assoc : pour exprimer l‟associativité d‟une opération.
comm : pour représenter la commutativité
idem : pour exprimer l‟idempotence.
id:<term> : pour énoncer que le terme <term> est l‟élément neutre de
l‟opération .
Example 3 :
fmod TRUTH-
VALUE is
sort Bool .
op true : ->Bool [ctor
special (...)] .
op false : ->Bool [ctor
special (...)] .
endfm
- 192 -
Surcharge
d'opérateurs
(Operator
overloading)
les opérateurs peuvent être surchargés, c'est-à-dire que nous pouvons
avoir plusieurs déclarations d'opérations pour le même opérateur avec
différents arités et co-arités. Voici un exemple sur la surcharge d'opérateur dans
la logique de réécriture :
L'opérateur _+_ est surchargé et à trois déclarations (une dans
l'exemple cité auparavant). Cependant, il y a deux types de surcharge dans
l'exemple. La déclaration de _+_ avec le premier argument NzNat est un
exemple de la surcharge de subsort où les deux opérateurs sont censés avoir le
même comportement [Megzari, 2004]
Exemple 4 :
Op _+_ : NzNat Nat
NzNat .
Sort Nat3 .
Ops 0 1 2 : Nat3 .
Op _+_ : Nat3
Nat3Nat3 .
Variables une variable représente une valeur indéfinie d‟une sorte, les variables sont
déclarées avec une syntaxe constituée du mot clé var suivi par l‟identificateur
de la variable suivi par deux points, suivi par le nom de la sorte et se termine
par un point.
À titre d‟exemple une variable N de sorte Nat est déclarée comme suit :
var N : Nat .
Une déclaration de plusieurs variables de même sorte peut se faire
aussi en une seule ligne
comme suit :
vars N M : Nat .
Une variable peut être déclarée aussi à la volée, ceci par l‟ajout de
deux points superposés et la sorte de la variable au nom de la variable comme
suit N:Nat.
Exemple 5 :
vars M N : Nat .
vars X Y : [Nat] .
Importation
de modules
cette façon de spécification permet d‟inclure toutes les déclarations et
définitions des modules importés, par conséquent cela permet de minimiser la
redondance dans la spécification mais aussi permet d‟offrir une meilleure
modularité.
Le langage Maude permet l‟inclusion de modules par l‟usage de trois
clauses : including, extending et protecting.
La syntaxe d‟utilisation de ces trois clauses est comme suit :
Including NomModule ou extending NomModule ou encore
protecting NomModule
Le mode protecting : signifie que les éléments déclarés dans le
module importés n‟accepte pas la modification c'est-à-dire toutes
les opérations et toutes les sortes sont utilisées strictement comme
elles sont définies initialement.
Exemple 6 :
mod VENDING-
MACHINE is
including VENDING-
MACHINE-
SIGNATURE .
var M : Marking .
- 193 -
Le mode including : veut dire qu‟on peut changer le sens des
éléments déclarés dans le module importé
le mode extending : lorsqu‟on utilise le mode extending l‟ajout de
nouveaux termes (constructeurs et constants) à une sorte est
autorisé mais la modification de la signification des opérations à
l‟aide des équations n‟est pas autorisée.
rl [add-q] : M => M q
rl [add-$] : M => M $
rl [buy-c] : $ => c .
rl [buy-a] : $ => a q .
rl [change] : q qqq =>
$ .
endm
Les attributs
de priorité
(parsing)
Pour fournir des grammaires non ambiguës, qui sont fréquentes, on
emploie des parenthèses pour casser les ambiguïtés possibles. Mais Maude
offre une alternative plus puissante qui réduit de telles ambiguïtés en
employant un mécanisme basé sur des valeurs de priorité et en recueillant des
modèles. La valeur maximale permise de précédence est 231
– 1. On peut
assigner une priorité à un opérateur avec un attribut de priorité (prec abrégé),
qui prend la valeur de priorité comme argument.il sont développés par J.
Quesada [Quesada, 1997] [Quesada, 1999.]
Exemple 7 :
op _+_ : Nat Nat ->
Nat [prec 33] .
op _*_ : Nat Nat ->
Nat [prec 31] .
pour que la
multiplication soit
évaluée avant
l‟addition. On peut
donner les priorités,
par exemple, 33 et 31
aux opérateurs _+_ et
au _*_,
respectivement.
Tableau 4.2 : les concepts du language Maude [Clavel, 2010] [Clavel, 2009] [Clavel, 2007a]
- 194 -
IV Travaux connexes :
Plusieurs travaux de recherches s‟intéressaient à la transformation vers Maude, citons :
Dans [Mokhati, 2009], ils ont proposé une approche générique qui permet de translater
les spécifications décrites par les diagrammes de cas d‟utilisation vers les spécifications
formelles en Maude. Cette thématique était adressé dans plusieurs articles publiées, mais
l‟aspect structural et /ou concurrentiel des systèmes n‟est pas étudié.
L‟approche proposée prend en considération l‟aspect structurel et dynamique des
systèmes (individuel et collectif) et utilise Maude qui est apte de décrire les systèmes orienté
objet concurrent. Le language Maude est supporté par un outil qui permet de valider le code
généré par simulation en Maude.
Cette approche présente une génération de code par simulation et une vérification
automatique des propriétés en utilisant le model checker implémenté dans l‟environnement
Maude, qui emploie la logique temporelle linéaire (LTL) pour vérifier des propriétés parmi les
modèles développés. La figure 4.7 illustre la méthodologie de l‟approche.
La figure 4.7 : la méthodologie de l‘approche [Mokhati, 2009]
- 195 -
L‟idée principale de ce travail [Lucas, 2008] et de spécifier le méta modèle en utilisant les
modules orientés objet de Maude ; les règles de transformations sont des règles de
réécriture qui réécrit Les éléments du modèle source vers les éléments de modèle
destination.
La recherche présentée montre la faisabilité d'intégrer des techniques formelles avec des
normes courantes de technologie de la programmation (MDA-QVT). Cette approche peut être
particulièrement utile dans des processus de MDE pour développer les systèmes critiques ou
sujets aux erreurs de qualité. La spécification du méta-modèle de cette approche est une manière
puissante de vérifier le type propriétés et l'exactitude des modèles sans perdre la lisibilité et le
caractère pratique d'autres langues de transformation. En outre, dans le cadre formel proposé les
transformations sont représentées pendant que les entités mathématiques permettent de tirer
profit de toute la puissance des mécanismes d'inférence mathématique. Ceci permet d'impliquer
l'information et de prouver des propriétés des transformations. La figure 4.8 extraite de [Lucas,
2008] représente un exemple de diagramme d‟UML et leur correspondance en MAUDE.
La figure 4.8 : un exemple de diagramme d‘UML et leur correspondance en MAUDE.
[Lucas, 2008].
- 196 -
Dans ce document [Mokhati, 2007], les auteurs ont proposé une vérification formelle de
l'interaction des protocoles décrits en employant AUML4647
. L'approche adoptée est
basée sur des techniques de modèle-checking soutenue par Maude.
Le modèle-checking offre plusieurs avantages relatifs aux approches traditionnelles
basées sur la simulation, les méthodes de test, ou le raisonnement déductif. Son avantage
principal est que, au moins pour des systèmes dites finished-states, il peut être exécuté d'une
manière complètement automatique et efficace [Clarke, 2002] Basée sur une logique saine et
complète, appelée la logique de réécriture [Meseguer, 1992a], [Meseguer, 1992c], le language
Maude [Meseguer, 1992c], [Clavel, 1999], [McCombs ,2003], semble dans ce contexte un
candidat intéressant. Il offre, en fait, par ses diverses constructions, une manière intéressante pour
spécifier et programmer les systèmes concourants. Il offre tous les éléments de base laissant
formellement spécifier et vérifier des interactions de multi-agent.
La logique de réécriture et Maude, en particulier, unifient plusieurs modèles de
simultanéité. Des réseaux de Pétri, les systèmes d'états-transitions, Lotos, la logique modale, la
46
http://www.auml.org 47
La méthodologie AUML (Agent UnifiedModelling Language)
Le langage de modélisation unifiée (Unified Modelling Language) est un essai d'unifier les divers
paradigmes d'analyse et de conception orientée objet du logiciel et offrir une notation unique pour la
modélisation des systèmes orientés objet. Il faut noter qu'UML n'est pas une méthodologie, mais, comme
son nom le dit, un langage pour faire la documentation des modèles de systèmes. Il y a aussi une
méthodologie associée à UML qui s'appelle "Rational Unified Process».
Dans ce contexte, ils ont proposé d'adapter les notations d'UML pour décrire la modélisation orientée
agent. Les modifications proposées à UML sont :
soutien pour la représentation des threads simultanés d'interaction (par exemple transmission de
messages à plusieurs agents) permettant ainsi à UML de modéliser les protocoles d'interactions
entre agents, par exemple le réseau contractuel ;
la notion de rôle qui étend celle fournie par UML et permet de modéliser un agent qui joue
plusieurs rôles. L'initiative la plus connue pour étendre UML avec des facilités permettant de décrire les agents s'appelle
AUML (Agent Unified Modelling Language) et a comme but de :
recommander une technologie pour l'adoption d'une sémantique, un meta-modèle et une syntaxe
abstraite communes pour l'analyse et la conception des méthodologies basées sur agents ;
recommander une technologie qui permet l'interopérabilité à travers le cycle de vie des produits
et d'outils de travail AUML ;
être en accord avec les spécifications existantes de FIPA (Fondation for Intelligent Physico
Agents) et OMG (Object Management Group). Il faut noter que, actuellement, AUML est plutôt un but qu'un langage de modélisation existant. L'OMG
(Object Management Group) et la FIPA appuient le développement des notations UML pour la
modélisation des systèmes multi-agents et prévoient des efforts considérables dans cette direction.
- 197 -
logique temporelle et d'autres formalismes sont intégrés dans la logique de réécriture [Gabriel,
2004], [Verdejo, 2003]. Le choix de Maude a été non seulement basé sur sa puissance
expressive, mais également sur sa possibilité de soutenir des simulations, donc permettant la
vérification formelle. La vérification d'un système dans Maude est basée sur les concepts de
Modèle-checking et les techniques de vérification modèles [Clarke, 2002], [Thierry-Mieg ,2005]
prendre de plus en plus l'importance dans le domaine de la vérification de systèmes concourants.
Le modèle-checking de Maude [Eker, 2002] a été conçu en combinant Maude et la logique
temporelle linéaire (LTL), tirant profit des deux formalismes. D'ailleurs, Maude offre une
puissance descriptive remarquable et le LTL offre des techniques récentes et avancées de
vérification modèle. Comparé à d'autres modèle-checking, comme la ROTATION [Holzmann,
1997], Maude semble plus expressif. Il laisse spécifier facilement différents genres de systèmes
concourants [Eker, 2003].
Ce papier se concentre sur la vérification formelle des protocoles d'interactions décrits par
des diagrammes d'AUML en utilisant le modèle checking de Maude. Ils ont illustré la
possibilité, par l'utilisation de l'environnement Maude, de modéliser et d'évaluer les propriétés du
MAS (Multi-Agents Systems). Certaines propriétés dépendent du comportement interne des
agents, tel que la prise de décision, et d'autres sont relativement au comportement collectif des
agents tel que la vérification de la synchronisation et de l'arrêt de système.
[Gagnon, 2007] [Gagnon, 2008], Les objectifs poursuivis tout au long de ces deux papiers
étaient de développer un cadre formel par lequel il serait possible de translater des
diagrammes UML vers une notation formelle du langage Maude. Par la suite, cette
description formelle Maude sera validée à l‟aide de deux des outils de l‟environnement
Maude : les simulations et la vérification de modèles. Le processus développé se divise en
quatre étapes majeures :
a) La description d‟un système OO à l‟aide de diagrammes UML.
b) La validation inter-diagramme entre les divers diagrammes UML développés pour
décrire le modèle du système. Cette étape de vérification consiste principalement
à s‟assurer que tous les bons éléments sont présents dans chacun des diagrammes.
c) Génération d‟une description formelle Maude. Cette étape consiste à dériver
systématiquement une description formelle basée sur le langage Maude.
- 198 -
d) Vérification de la description formelle du système à l‟aide du vérificateur intégré
de l‟environnement Maude. Cette étape se fait à l‟aide du vérificateur intégré de
l‟environnement Maude et des propriétés comportementales du système énoncées
à l‟aide de la logique LTL.
VI- Conclusion
La logique de réécriture a été proposée par J. Meseguer comme une sémantique
concurrente des systèmes de réécriture de termes ou les opérateurs peuvent être associatifs,
commutatifs, idempotents ou dotés d‟un élément neutre à gauche ou à droite. Elle formalise le
processus de réécriture, qui utilise les règles de réécriture pour calculer une relation de
« réécrivabilité » entre les termes.
La logique de réécriture est utilisée comme une structure sémantique qui supporte un
large spectre d‟applications, elle est utilisée pour spécifier et unifier de modèles de calcul
concourant et elle offre aussi un langage déclaratif ou les programmes parallèles ou séquentiels
peuvent être spécifiés par des règles de réécriture .
Parmi les systèmes basés sur la logique de réécriture, souvent utilisés comme systèmes de
spécification. Pour certains de ces systèmes, cette logique n‟est pas seulement un outil
d‟implantation, mais aussi un paradigme de calcul offert à l‟utilisateur. Citons le système Maude
qui un langage caractérisé par la simplicité, la performance et l‟expressivité. Maude est un
candidat idéal pour la spécification de système car il est basé sur une logique très mathématique
et dispose d‟une forte sémantique.
- 199 -
CHAPITRE V
CONTRIBUTION
I- Rappels
II- L’approche proposée
III- Conclusion
- 200 -
I. Rappels
I.1 UML :
Unified Modeling Language (UML) est un langage essentiellement visuel de
modélisation dite orientée objet. Standardisé en 1997 par l‟OMG, UML est aujourd‟hui
l‟environnement quasi-incontournable et de référence dans l‟industrie en termes de modélisation
orientée objet.
Selon [OMG, 2003a] [OMG, 2002] : « UML C‟est un langage relevant des formalismes
objets et qui permet de spécifier, de visualiser, de construire et de documenter les concepts d'un
système » .UML un langage unifié de la modélisation qui s'est dégagé pour devenir le standard
de modélisation objet. En effet, UML n‟est pas une méthode mais plutôt une notation qui
fusionne les notations d‟OOD, OMT et d‟OOSE.UML a été standardisée par l'Object
Management Group (OMG). La version 2.0 a été l'occasion d‟un changement majeur du langage
UML dont les spécifications ont été mises en accord avec celles du Meta Object Facility(MOF)
méta-méta-modèle du langage UML. UML fournit un ensemble de notations graphiques
standardisées regroupées en treize types de diagrammes dont 4 nouveaux diagrammes introduits
par UML2.
UML se décompose en plusieurs vues. Les vues présentent les différents aspects d'un
système. Une vue n'est pas un élément graphique ou un diagramme, mais une abstraction qui
unit un nombre de diagrammes afin de décrire le système d'un point de vue donné.
Le langage UML est extensible, citons : les stéréotypes, OCL - Object Constraint
Language, Tagged value.
La caractéristique essentielle qui distingue la notation UML des autres notations consiste
en sa base formelle appelée méta-modèle. Le méta-modèle est défini à l‟aide de quatre couches
d‟architecture de méta-modélisation.
UML est semi-formel pour cela une grande partie (pour être plus précis, la majeure partie)
d‟UML n'a pas encore de sémantique précise. La caractéristique « semi-formel » provoque
l‟ambigüité et l‟imprécision.
- 201 -
I.2 Les diagrammes d‘états-transitions :
Le diagramme d‟état transition ou diagramme de machine d‟états, y compris les états
simples, les transitions et les états composites imbriqués. Le concept d‟origine a été inventé par
David Harel, qui leur a donné le nom de diagrammes d‟états- transitions.
Une machine d‟état modélise les historiques de vie possibles d‟un objet de classe. Elle
contient des états reliés par des transitions. Chaque état modélise une période de vie d‟un objet
ou il remplit certaines conditions. Lorsqu‟un événement se produit, il déclenche une transition
qui envoie l‟objet vers un nouvel état. Lorsqu‟une transition a lieu, un effet (action à la
transition) s‟exécute.
Les diagrammes de machines d‟états illustrent ces machines d‟état, Pour l‟origine les
diagrammes d‟états-transitions « statecharts » proviennent de David Harel avec des modifications
mineures.
Formellement, le SM (state -machine, machine- d‟état) de Diagrammes d‟états-transitions
est un ensemble fini de modèles d'états -transitions, où le modèle d'états-transitions est défini
comme suit :
ST = (S, T, E, C, A, i, f) où
• S est un ensemble fini d'états.
• E est un ensemble fini d'événements.
• C est un ensemble fini de conditions.
• A est un ensemble fini d'actions
• Le T ⊂ S×E×C×2A×S de T est un ensemble fini de transitions, Là où 2
A dénote
l'ensemble de puissance d'A
• i ∈ S est un état initial
• f ∈ S est un état final.
- 202 -
I.3 Transformation des modèles :
Selon [Czarnecki, 2006], la transformation des modèles est définie comme étant le
processus de conversion d‟un modèle d‟un système vers un autre modèle.
Une transformation de modèles peut également avoir plusieurs modèles source et
plusieurs modèles cibles. Une caractéristique de transformation de modèles est qu‟elle est un
modèle puisque elle doit être conforme à un méta-modèle donné [Czarnecki, 2006].
[Kleppe, 2003] [Mens, 2005], proposent la définition suivante pour la transformation de modèles.
La transformation : est une génération automatique d‟un modèle cible (Target model) à partir
d‟un modèle source (source Model). Les transformations peuvent utiliser des outils comme
AGG, AToM3, VIATRA2….
La taxonomie des transformations des modèles est variée, la figure 5.1 récapitule la
classification proposée par MDA. L‟approche proposée est classifié parmi les transformations
(PSM vers code) ou génération de code. Figure 5.1 examine les transformations préposées par
l‟approche MDA et signale la génération de code.
Génération de code
Figure 5.1 : Les transformations dans l‘approche MDA
- 203 -
I.4 La génération de code :
Est une transformation de type modèle à texte [Czarnecki ,2006]. Le code est parfois
assimilé par certains à un PSM exécutable. Dans la pratique, il n‟est généralement pas possible
d‟obtenir la totalité du code à partir du modèle et il est alors nécessaire de le compléter
manuellement.
La génération de code est basée sur les principes visiteur ou patron :
- Les transformations fondées sur le principe des patrons : sont actuellement les plus
courantes. Le code cible contient des morceaux de méta-code utilisés pour accéder aux
informations du modèle source.
- Les transformations fondées sur le principe du visiteur : consiste à traverser le modèle en
lui ajoutant des éléments qui réduisent la différence de sémantique entre le modèle et le
langage de programmation cible. Le code est obtenu en parcourant le modèle enrichi pour
créer un flux de texte. L‟approche que nous proposons adopte le principe de visiteur.
I.5 ATOM3:
AToM3 (A Tool for Multi-formalism and Meta-Modelling [Vangheluwe, 2002] est un
outil de modélisation multi-paradigmes développé par le laboratoire MSDL (Modelling,
Simulation and Design Lab.) à l'université de McGill Montréal, Canada. Cet outil a été conçu en
collaboration avec Juan de Lara de Universidad Autónoma de Madrid (UAM), Espagne.
Les deux principales fonctionnalités d'AToM3 sont la méta-modélisation et la
transformation de modèles. La méta-modélisation est la description ou la modélisation de
différents types de formalismes. La transformation de modèles est une technique consistant à
transformer, traduire ou modéliser automatiquement un modèle décrit dans un certain
formalisme, vers un autre modèle qui peut être décrit soit dans le même formalisme soit dans un
autre. Il permet aussi de définir la syntaxe abstraite et concrète des langages visuels.
Dans AToM3 les formalismes et les modèles sont décrits comme des graphes. Cet
environnement génère un outil de manipulation graphique des modèles décrits dans un
formalisme donné, à partir d'une méta-spécification de ce formalisme (décrite dans le formalisme
entité/relation).
- 204 -
I.6 Maude :
Représente un système développé au SRI par l‟´équipe de José Meseguer [Clavel
,1998b]. Maude [Meseguer, 2000] représente aussi un langage de spécification et de
programmation basé sur la logique de réécriture. Il intègre actuellement les paradigmes de
programmation fonctionnelle et objet.
Maude offre peu de constructions syntaxiques mais il offre une sémantique bien définie.
Le choix de Maude est fondé sur les caractéristiques:
Maude est un langage déclaratif de haut niveau et aussi un système de haute performance
défini par J. Meseguer.
Maude est un langage basé sur la logique de réécriture (Based on rewriting logic
Maude est multi-paradigme (Multiparadigm).
Maude est réflectif [Clavel ,1998 b] [Clavel, 1996b] [Clavel, 1996c], la logique de
réécriture est réflective.
Maude est caractérisé par un spectre large (wide –Spectrum).
Maude est qualifié par les stratégies internes (internalstrategies) : ces stratégies
permettent de contrôler et de guider le processus de réécriture dont la sémantique est
définie par les règles de réécriture à l‟intérieur de la logique.
Maude est aussi utilisé pour : la spécification, le prototypage, la vérification.
Maude est doté d‟un ensemble d‟outils permettant de simplifier la fonction de la
vérification : Le Model Checker, Prouveur de Théorème, Le vérificateur de cohérence
Maude CoherenceChecker (MCC)...
- 205 -
Dans cette approche nous intéressons aux modules systèmes de Maude.
I.7 Modules systèmes :
Un module système définit une théorie de réécriture, il a donc la forme :
mod (∑, E,R) endm où (∑, E,R) correspond à une théorie de Réécriture. Ce type de
modules établit une extension des modules fonctionnels par l‟introduction des règles de
réécriture conditionnelles et non conditionnelles.
Sémantiquement, les règles de réécriture expriment le comportement dynamique d‟un
système. Une règle spécifie une „transition concurrente locale‟ qui peut se produire dans un
système si la partie gauche de la règle correspond à un fragment de l‟état du système avec la
condition étant satisfaisante.
Syntaxiquement, Une règle de réécriture sous Maude peut avoir deux variantes:
Une règle de réécriture non conditionnelle est déclarée comme suit :
rl [<Label >] : <Term-1 > =><Term-2 > [< attributs de la règle >].
Une règle de réécriture conditionnelle est déclarée comme suit:
crl [<Label >] : <Term-1 > =><Term-2 > if <Condition-1 > /\ ... /\ <Condition-k >
[< attributs de la règle >] .
- 206 -
II. L‘approche proposée
II.1 Présentation de l‘approche
Cette approche réunit en réalité deux transformations : la première translate les
diagrammes d‟états-transitions composites (concurrents/séquentiels) vers les diagrammes d‟états-
transitions à plat en appliquant les algorithmes de Saldhana, [Saldhana, 2001].
La deuxième transforme les diagrammes d‟états-transitions à plat vers Maude, en utilisant
l‟outil ATOM3.
Dans cette approche, ATOM3 est utilisé pour créer un méta-modèle pour les diagrammes
d‟états-transitions à plat, éditer les apparences visuels des constituants du méta-modèle (les
classes et les associations), générer automatiquement l‟outil de modélisation des diagrammes
d‟états-transitions à plat, spécifier les règles de la grammaire de transformation puis exécuter la
grammaire qui génère le code Maude. La figure 5.2 expose un schéma descriptif de l‟approche
proposée.
- 207 -
Figure 5.2 : Schéma descriptive de l‘approche proposée
L‘application de
l‘algorithme A/B
Création d‘un
méta-modèle
Génération d‘un
outil de
modélisation
Création de la
grammaire
(spécification des
règles)
Exécution de la
grammaire
1
2
3
4
6
Transformation des diagrammes
d‘états-transitions composites
vers les digrammes d‘états-
transitions à plat en appliquant
les algorithmes de Saldhana.
Transformation des diagrammes
d‘états-transitions à plats vers
Maude (génération de code) en
utilisant ATOM3.
Diagrammes d‘états transitions composites
(concurrents/séquentiels) 1
Diagramme d‘états-transitions à plat 2
Méta-modèle crée (*._MDL.py).
3
L‘outil de modélisation généré par ATOM3
(*._META.py) 4
La grammaire de transformation éditée
par ATOM 3 (*._GG_mdl
)
5
5
Le code généré en Maude
Le code généré en Maude
6
- 208 -
II.2 Les étapes de l‘approche
II.2.1 Transformation des diagrammes d‘états-transitions composites
(séquentiel/concurrent) vers diagrammes états-transitions à plat en utilisant l‘algorithme
A/B
Dans cette étape, l‟objectif est de convertir les diagrammes d‟états-transitions composite
séquentiel/concurrent vers les diagrammes d‟états-transitions à plat.
Deux algorithmes sont proposés par [Saldhana, 2001], pour convertir les diagrammes
d‟états-transitions composite vers les diagrammes d‟états-transitions à plat (simple) :
L‟algorithme A : convertit un diagramme d‟états-transitions composite séquentiel vers un
diagramme d‟états- transitions plat, ou l‟entrée de l‟algorithme est un diagramme d‟états-
transitions composite séquentiel et la sortie est un diagramme d‟états-transitions à plat.
La figure 5.3 extraite de [Saldhana, 2001], illustre un exemple de l‟application de l‟algorithme
A.
Figure 5.3 : Conversion de diagramme d‘états-transitions séquentiel composite vers un
diagramme d‘états-transitions plat (Conversion of a sequential composite state (X) to flat).
- 209 -
Algorithm A [Saldhana, 2001]: Convert a sequential composite state into a flat state machine.
Input: A UML statechart diagram S containing a sequential composite state scs.
Output: Flat state machine O.
BEGIN
1. Let O be a flat state machine with zero states and zero transitions.
2. For all states s εS and s ≠ scs, add state s and all its transition arcs into O.
3. If s εS and s = scs,
• Add each state sxεscsand all its transition arcs into O.
• For each transition from a state s≠ scsto a state sxεscs, add a transition from s εO to sxεO.
• For each transition from a state sxεscsto a state s≠ scs, add a transition from sxεO to s εO.
• For an entry transition from a state s εS and s ≠ scsto state scs, add a transition from s εO to sxεO such that
sxcorresponds to an initial state of state scs.
• For an exit transition from state scsto a state s εS and s ≠ scs, if the transition is triggered by an event, add a
transition from each state sxεO to s εO such that sxεscs.
• For an exit transition from state scsto a state s εS and s ≠ scs, if the transition is triggerless, add a transition
from state sxεO to s εO such that sxcorresponds to an ending state of state scs.
END
- 210 -
L‟algorithme B: convertit un diagramme d‟états- transitions composite concurrent vers un
diagramme d‟états- transitions plat, ou l‟entrée de l‟algorithme est un diagramme d‟états-
transitions composite concurrent et la sortie est un diagramme d‟états-transitions à plat .la
figure5.4 extraite de [Saldhana, 2001], illustre un exemple de l‟application de l‟algorithme
B.
Figure 5.4 : Conversion de diagramme d‘états –transitions concurrent composite vers un
diagramme d‘états –transitions plat (Conversion of a concurrent composite state (X) to flat)
- 211 -
Algorithm B [Saldhana, 2001]: Convert a concurrent composite state into a flat state machine.
Input: A UML statechart diagram S containing a concurrent composite state ccs.
Output: Flat state machine O.
BEGIN
1. Let O be a flat state machine with zero states and zero transitions.
2. For all states s εS and s ≠ ccs, add state s and all its transition arcs into O.
3. If s εS and s = ccs,
• Add all the states along each distinct path in s into O.
• Add a state fork into O and add a transition from fork to each state in O that corresponds to an initial state on a
distinct path in s.
• Add a state join into O and add a transition to join from each state in O that corresponds to an ending state on
a distinct path in s.
4. For all states s εS such that s ≠ ccs and there is a transition from s to ccs, add a transition from s εO to state
fork εO.
5. For all states s εS such that s ≠ ccs and there is a transition from ccs to s, if the transition is triggerless add a
transition from state join εO to s εO.
END
- 212 -
II.2.2Transformation des diagrammes d‘états-transitions à plat vers Maude :
Elle regroupe les sous étapes suivantes effectuées en utilisant l'ATOM3:
II.2.2.1 La création d‘un méta-modèle
Cette étape consiste à créer un méta-modèle pour les diagrammes d‟états-transitions à plat.
Ou un méta-modèle, selon MOF définit la structure que doit avoir tout modèle conforme à
ce méta-modèle. Autrement dit, tout modèle doit respecter la structure définie par son méta-
modèle. Par exemple, le méta- modèle UML définit les modèles UML qui contiennent des
packages, leurs packages des classes, leurs classes des attributs et des opérations, etc.
Les méta-modèles fournissent [Blanc, 2005] la définition des entités d‟un modèle, ainsi
que les propriétés de leurs connexions et de leurs règles de cohérence. MOF les représente sous
forme de diagrammes de classes.
Le méta-modèle crée par ATOM3 est un fichier de type MODEL files (*._MDL.py).
Le méta-modèle encapsule les concepts principales des diagrammes d‟états-transitions qui
sont : les états, les transitions, les événements, les gardes,….
En se basant sur le modèle E/R, le concepteur doit spécifier les entités du modèle et
définit les relations entre eux.
En utilisant ATOM3, le concepteur doit spécifier les classes, leurs attributs, leurs
associations (soit binaire ou une association d‟héritage), ainsi que leurs cardinalités. La figure
5.5 décrit le méta-modèle associé aux diagrammes d‟états-transitions à plat.
- 213 -
Figure 5. 5: Le méta-modèle des diagrammes –d‘états-transitions à plat
II.2.2.2 La génération d‘un outil de modélisation
Après la création du méta-modèle, la sauvegarde de méta-modèle et l‟édition de
l‟apparence visuelle. ATOM3 génère un outil de modélisation des diagrammes d‟états-
transitions. L‟outil de modélisation est un fichier de type Meta_ Model files (*_Meta.py).
Cet outil offre un ensemble de boutons pour l‟édition des diagrammes d‟états-transitions à
plat. Figure 5.6 illustre l‟outil de modélisation généré par ATOM3 pour les diagrammes d‟états-
transitions à plat.
L‟outil de modélisation généré par ATOM3 permet la création, la modification et la
manipulation des modèles.
- 214 -
Figure 5.6 L‘outil de modélisation généré par ATOM3 pour les diagrammes d‘états-
transitions à plat
- 215 -
II.2.2.3 La définition de la grammaire de transformation
Dans ATOM3, après le chargement du modèle il peut être transformé vers un autre
modèle équivalent, exprimé par un autre formalisme ou dans le même formalisme. Dès que les
modèles sont représentés à l‟intérieur sous forme de graphes équivaux lorsqu‟il s‟agit d‟une
transformation de type modèle vers code.
La transformation entre modèles s‟effectue par la grammaire de transformation.
La grammaire de transformation est éditée par l‟éditeur de la grammaire d‟ATOM3
(Editing GraphGrammarEdit), il dispose un ensemble de menus qui permettent la manipulation
de la grammaire comme : Le chargement de la grammaire, la sauvegarde de la grammaire, la
génération de document latex depuis la grammaire, la génération de code de la grammaire et
l‟‟exécution de la grammaire.la figure 5.7 décrit l‟éditeur de la grammaire d‟ATOM3.
Figure 5.7 L‘éditeur de la grammaire de transformation
- 216 -
Une grammaire de transformation est constitué de :
- Une action initiale : l‟action initiale liée à l‟approche proposée permet d‟initialiser les
variables, de localiser le chemin des fichiers, d‟ouvrir les fichiers, d‟écrire les déclarations
de l‟entête de fichier de spécifier les états (state)….
- Une action finale : l‟action finale liée à l‟approche proposée permet de supprimer les
attributs visités, compléter la fin du fichier, fermer le fichier et supprimer le contenu du
fichier.
- Les règles de transformation : la grammaire de transformation est composée d‟un
ensemble de règles. Les spécificités de la grammaire de l‟approche proposée et que le
graphe de la partie droite et le graphe de la partie gauche sont équivaux, certaines règles
produisent la génération de code, d‟autres non selon la sémantique produite.
Chaque règle de transformation est constituée de:
- Un nom spécifique de la règle.
- Une priorité indiquant l‟ordre dans lequel la règle est appliquée.
- Une partie gauche (Left Hand Side : LHS) qui est un graphe.
- Une partie droite (Right Hand Side : RHS) qui est équivalent à sa partie gauche ((Left
Hand Side : LHS) dans le cas d‟une transformation de type modèle vers code.
- Une condition (Un code en Python) qui doit être vérifiée avant l‟application de la règle.
- Une action (Un code en Python) qui doit être exécutée une fois que la règle est
appliquée.la figure 5.8 décrit la grammaire nommé Statecharts2Maude
Figure 5.8 la grammaire nommé Statecharts2Maude
- 217 -
La figure 5.9 présente une description de deux règles (règle1, règle6) de la grammaire nommé
Statecharts2Maude.
Figure 5.9 la description de deux règles (règle1, règle6) grammaire nommé
Statecharts2Maude
Rule #1(Order 1): rule11 cette règle génère le code en Maude correspondant à une state liée à une transition par un
arc entrant.
Rule #6(Order 6): rule66 cette règle vérifié si la transition possède une condition ou non, selon le cas soit elle
provoque la génération d’une règle de réécriture conditionnelle ou d’une règle de réécriture non conditionnelle.
- 218 -
II.2.2.4 L‘exécution de la grammaire de transformation vers Maude.
La figure 5.10 propose un exemple de l‟exécution de la grammaire nommé Statecharts2Maude
sur l‟ (exemple_MLD).
Figure 5.10 : exemple de l‘exécution de la grammaire nommé Statecharts2Maude
L‟exécution de la grammaire Statecharts2Maude sur le modèle (exemple_MLD), génère le
fichier(System) en Maude :
- 219 -
III. Conclusion:
Cette approche réunit en réalité deux transformations : la transformation initiale qui
convertit les diagrammes d‟états-transitions composites (concurrents/séquentiels) vers les
diagrammes d‟états-transitions à plat en appliquant les algorithmes de Saldhana, [Saldhana,
2001].
La transformation secondaire qui convertit les diagrammes d‟états-transitions à plat vers
Maude, en utilisant l‟outil ATOM3.
Le processus de transformation parcourt les fragments de modèle créé par l‟utilisateur, et
exécute les règles de transformation dans leur ordre de priorité, jusqu‟a aucune règle ne peut être
exécuté.la particularité des transformations de type modèle vers code est que le graphe de la
partie droite est identique au graphe de la partie gauche .en plus certains règles produisent le
code enrichissant la sémantique des diagrammes d‟états- transitions.
L‟approche que nous proposons adopte le principe de visiteur qui consiste à parcourir le
modèle en lui ajoutant des éléments qui réduisent la différence de sémantique entre le modèle et
le langage de programmation cible. Le code est obtenu en parcourant le modèle enrichi pour
générer un flux de texte.
Dans cette approche, ATOM3 est employé pour concevoir un méta-modèle pour les
diagrammes d‟états-transitions ,créer les apparences visuels des constituants du méta-modèle
(les classes et les associations), produire automatiquement l‟outil de modélisation des
diagrammes d‟états-transitions à plat , définir les règles de la grammaire de transformation, leurs
priorités ,leurs pré-conditions ,leur post-conditions puis exécuter la grammaire qui génère le code
Maude.
- 220 -
CONCLUSION GENERALE
- 221 -
Conclusion GENERALE
Dans ce mémoire, le language UML et les statecharts ont été revues afin d‟en présenter
les notions et définitions importants. Ces deux titres ont fait l‟objet d‟un chapitre chacun,
respectivement les chapitres 1 et 2, sous la forme d‟une revue de la littérature, tout en résumant
les concepts primordiaux.
Les définitions des concepts : modèle, méta-modèle, langage de modélisation, méta-méta-
modèle, transformations de modèles proposées par MDA et leur taxonomie sont explorés dans le
chapitre 3.L‟outil de méta-modélisation et de transformation ATOM 3 a fait l‟objet d‟une
description détaillée.
L‟environnement Maude a également fait l‟objet d‟une étude approfondie au chapitre 4,
notamment sur ses fondements mathématiques, ces modules, ces niveaux de programmation et
son langage. Maude est un langage de spécification et de programmation basé sur la logique de
réécriture. Cette dernière a été tout particulièrement développée en vue de spécifier plus aisément
les systèmes concurrentiels.
La logique de réécriture inspire une manière correcte de raisonnement sur les systèmes
concurrents non-déterministes ayant des états qui évoluent à travers des transitions. La
sémantique de la logique de réécriture dite sémantique de „vraie concurrence‟ permet de
restreindre les carences des statecharts.
Ce mémoire a pour objectif de développer une grammaire pour la transformation des
diagrammes d‟états-transitions vers Maude en utilisant l‟ATOM3 .Ce processus est décrit au
chapitre 5.
- 222 -
Approche proposée
Les objectifs pourchassés tout au long de ce mémoire étaient de développer une
grammaire de transformation par laquelle il serait possible de translater des diagrammes d‟états –
transitions vers une notation formelle du langage Maude.
Le processus développé se divise en deux étapes majeures :
- Transformation des diagrammes d‟états-transitions composites vers les digrammes d‟états
transitions à plat en appliquant les algorithmes de Saldhana.
- Transformation des diagrammes d‟états-transitions à plats vers Maude (génération de
code) en utilisant ATOM3.cette étape est devisée lui –même en sous étapes traités par
l‟outil de méta-modélisation comme suit :
- Création d‟un méta modèle lié aux diagrammes d‟états-transitions à plat.
- Génération d‟un outil de modélisation.
- Création de la grammaire (spécification des règles).
- Exécution de la grammaire et génération de code.
Le choix d‟ATOM3 est fondé sur la capacité de cet outil en matière de méta-modélisation
et en matière de transformation de modèles.
Le choix de Maude est justifié de point de vue théorique et pratique pour cette tâche. Les
caractéristiques de Maude permettent de remplir les besoins des statecharts en termes de
spécification, programmation, simulation et vérification.
- 223 -
Travaux Futurs
Comme perspectives, nous envisageons à l‟avenir la réalisation des travaux suivants :
La plupart des diagrammes d‟UML sont qualifiés par la syntaxe riche et la sémantique
pauvre provoquant des interprétations ambigües et non précises, pour cela nous
prévoyons d‟autres transformations des diagrammes d‟UML vers la spécification formelle
Maude, particulièrement : les diagrammes comportementaux, diagrammes
d‟interactions…..
La plupart des approches cités dans les travaux connexes proposaient des spécifications
formelles en Maude et des vérifications assurées par l‟outil modèle checker de Maude,
pour cela nous envisageons de combiner entre les deux puissants ATOM3 et Maude pour
automatiser les deux tâches : la transformation vers MAUDE et la vérification des
modèles.
La plupart des systèmes sont désignées par des structures complexes et sémantiques
ambigües, pour diminuer cette complexité, nous projetons : la transformation des
systèmes multi- agents, les systèmes embarquées…..
- 224 -
BIBLIOGRAPHIE
- 225 -
[Alouini ,1997]
E. Alouini. Etude et mise en œuvre de la réécriture conditionnelle concurrente sur des
machines parallèle à mémoire distribuée. .PhD thesis, Université Henri Poincaré-Nancy
I, Mai1997.
[Alur, 1990]
R. Alur, C. A. Courcoubetis, D. L. Dill: Model-checking for real-time systems. In 5th
IEEE Symposium on Logic in Computer Science, p. 414_425, Philadelphia, PA , juin
1990.Disponible sur : http://www.it.uu.se/research/group/darts/papers/texts/fct95.ps.gz
[Antkiewicz, 2003]
M.Antkiewicz. Model transformation of simpliefd UML Model into Rdbms Model Using
ATOM3 Meta-Modeling TOOL .final project report for generative programming
course, University of Waterloo, 2003.Disponible
sur:http://gsd.uwaterloo.ca/sites/default/files/2003-antkiewicz-Uml2Rdbms-report.pdf
[Atilf.2010] http://atilf.atilf.fr/tlf.htm
[Aoki, 2001]
T. Aoki, T. Tateishi, T. Katayama. An axiomatic formalization of UML models. In
Practical UML-Based Rigorous Development Methods - Countering or integrating the
eXtremists. Workshop of the pUML -Group held together with UML 2001, volume P-7
of LNI, pages 13-28. German Informatics Society, 2001. Disponible sur :
http://subs.emis.de/LNI/Proceedings/Proceedings07/anAxioFormofUML_2.pdf
[Ambler, 2005] Scott w. Ambler. The elements of UML2.0 style. Cambridge University Press. 2005.
[Ambler, 2004] Scott W. Ambler. The Object Primer, Third Edition, Cambridge University Press ©
2004, ISBN: 0521540186
[Audibert, 2006] UML2. Disponible à : http://laurent-audibert.developpez.com/Cours-UML/html/Cours-
UML.html, Date de publication : 31/10/2006, Date de mise à jour : 01/12/2009.
[Azaiez ,2007]
Selma Azaiez .Approche dirigée par les modèles pour le développement de systèmes
multi-agents. Thèse de doctorat. L‘université de SAVOIE, décembre 2007.Disponible
sur :
http://www.polytech.univ-
savoie.fr/fileadmin/polytech_autres_sites/sites/listic/Theses/these_Azaiez.pdf
[Balzert, 2006]
H. Balzert. UML 2.0 compact, Eyrolles, 2006 les pages 22-30 disponible
surhttp://www.eyrolles.com/Chapitres/9782212117530/pages_22_30_Balzert.pdf?xd=072
b9ba5a0e3faf16a61261df355b233.
[Barbier, 2005] Franck Barbier, Ingénierie des modèles avec étude de cas, DUNOD, 2005.
[Bardohl, 2003]
Roswitha Bardohl, Hartmut Ehrig, Juan de Lara, Olga Runge, Gabi Taentzer, Ingo
Weinhold .Node Type Inheritance Concept for Typed Graph Transformation,
2003.Disponible sur :
http://cs.tu- berlin.de/~rosi/publications/BELRTW03_TR03-19.ps.gz
[Bdl, 2010] Banque de dépannage linguistique. Disponible sur :
http://66.46.185.79/bdl/gabarit_bdl.asp?id=4340
[Blanc, 2005] Xavier, Blanc .MDA en action : ingénierie logicielle guidée par les modèles, Eyrolles,
2005. (Avec la contribution d‘Olivier Salvatori).
[Bézivin, 2005a]
J. Bézivin, On the Unification Power of Models, on Software and SystemsModeling. 4
(2005), no. 2, 171_188.Disponible sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.105.8513&rep=rep1&type=pdf
[Bézivin, 2005b]
Bézivin j., Blay M., Bouzeghoub M., Estublier, Favre J-M. Rapport de Synthèse : Action
Spécifique CNRS sur l‘Ingénierie Dirigée par les Modèles, Centre National de la
Recherche Scientifique CNRS,
2005. - Disponible sur : http://wwwesto.ump.ma/mounir/mda/these%20mda/AS-MDA-
IDM-BasesDeDonees-1.1.pdf
[Bézivin, 2004]
Jean Bézivin .Sur les principes de base de l‘ingénierie des modèles.
RSTI-L‘Objet, 10(4):145–157, 2004.Disponible sur :
http://atlanmod.emn.fr/www/papers/LObjet2004.pdf
[Bézivin, 2003]
Jean. Bézivin, S.Gérard, P.-A. Muller, and L. Rioux, MDA Components: Challenges and
Opportunities, Proceedings of Metamodelling for MDA (York, England),
2003.Disponible sur:
http://atlanmod.emn.fr/www/papers/MDAComponents-
ChallengesOpportunities.V1.3.PDF
- 226 -
[Bézivin ,2002]
Bézivin, J, X. Blanc. Promesses et interrogations de l‘approche MDA. Développeur
Référence – Septembre 2002, Disponible sur :
http://pagesperso.lina.univ-nantes.fr/~vailly-
a/Enseignement/Documents/MDA.Partie2.JBXB.Last.prn.pdf
[Bézivin, 2001]
Jean Bézivin, Olivier Gerbé: Towards a Precise Definition of the OMG/MDA
Framework, presented at ASE'01, Automated Software Engineering, San Diego, USA,
November 26-29, 2001.Disponible sur:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.95.6645&rep=rep1&type=pdf
Ou: http://atlanmod.emn.fr/www/papers/ASE01.OG.JB.pdf
[Bonnet ,2005]
Stéphane Bonnet .Une démarche dirigée par les modèles pour la personnalisation des
applications embarquées dans les cartes à puce. PhD. thesis, Université de LILLE 1,
Mai 2005..Disponible sur :https://iris.univ-lille1.fr/dspace/bitstream/1908/565/1/50376-
2005-Bonnet.pdf
[Borovanský, 1998]
P. Borovanský, C. Kirchner, H. Kirchner, P.-E. Moreau, and C. Ringeissen. . In Claude
Kirchner and Hélène Kirchner, editors, Proceedings of the 2nd International Workshop
on Rewriting Logic and its Applications, WRLA ‘98, volume 15, Pont-à-Mousson
(France), September 1998. Electronic Notes in Theoretical Computer Science.
Disponible sur
http://www.loria.fr/~moreau/Papiers/BorovanskyKKMR-WRLA1998.pdf
[Boudiaf ,2009]
Noura Boudiaf , Abdelhamid Djebbar. Towards an Automatic Translation of Colored
Petri Nets to Maude Language. International Journal of Computer Science and
Engineering 3:1 2009. Disponible sur: http://www.waset.org/journals/ijcse/v3/v3-1-2.pdf
[Bouhoula, 1997]
Bouhoula, A., Jouannaud, J.- P. et Meseguer, J. Specification and proof in membership
equational logic, in M. Bidoit et M. Dauchet (eds), Proceedings Theory and Practice of
Software, TAPSOFT‘97, Development, (Lille, France), Vol. 1214 of Lecture Notes in
Computer Science, (1997, Springer-Verlag, pp. 67–92.
[Bouhoula, 1996]
Bouhoula, A., Jouannaud, J.-P. et Meseguer, J. (1997). Specification and proof in
membership equational logic, in M. Bidoit et M. Dauchet (eds), Proceedings Theory
and Practice of Software, TAPSOFT‘97, Development, (Lille, France), Vol. 1214 of
Lecture Notes in Computer Science, Springer-Verlag, pp. 67–92. Disponible sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.948&rep=rep1&type=pdfO
u
ftp://ftp.lri.fr/LRI/articles/jouannaud/spmel-taps
ou http://www.loria.fr/~bouhoula/BouhoulaJM-CAAP97.ps
[Booch ,2000] Booch, G., Rumbaugh, J. & Jacobson, Guide de l'utilisateur UML. 2éme édition.
Eyrolles .2000.
[Börger, 2002]
E. Börger, The Origins and the Development of the ASM Method for High Level System
Design and Analysis, In Journal of Universal Computer Science, Vol. 8, no.1, January
2002. Disponible sur
http://www.jucs.org/jucs_8_1/the_origins_and_the/Boerger_E.pdf.
http://www.jucs.org/jucs_8_1/the_origins_and_the/Boerger_E.pdf
Ou http://www.jucs.org/jucs_8_1/the_origins_and_the/Boerger_E.html
[Börger, 2000]
E. BÖrger, A. Cavarra, and E. Riccobene. Modeling the dynamics of UML
state machines. In Proceedings of the International Workshop on Abstract State
Machines,
The theory and Applications, volume 1912 of Lecture Notes in Computer Science, pages
223- 241. Springer, 2000.Disponible sur :
http://www.di.unipi.it/~boerger/Papers/SwEngg/UMLStatecharts.pdf /
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.8282&rep=rep1&type=pdf
- 227 -
[Börger, 1995]
E. Börger, Why Use Evolving Algebras for Hardware and Software Engineering, In
Proc. SOFSEM‘95, 22nd Seminar on Current Trends in Theory and Practice of
Informatics, Milovy , Czech Republic, LNCS 1012, pp : 236-271, Springer Verlag,1995.
Disponible sur :
http://bigfoot.eecs.umich.edu/.1/groups/Ealgebras/whyuse.ps.gzOu
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=D2FEA3A2DE4488F604404331
03FB23DE?doi=10.1.1.42.48&rep=rep1&type=pdfOu
www.springerlink.com/index/p971095h0m6gp158.pdf
[Bruni, 2006]
R. Bruni and J. Meseguer. Semantic foundations for generalized rewrite
theories.Theoretical Computer Science, 360(1-3):386–414, 2006. Disponible sur :
http://www.di.unipi.it/~bruni/publications/tcs-grt.ps.gz
[Bunke , 2000] H. Bunke. Graph matching for visual object recognition. Spatial vision, 2000.
[Clavel, 2010]
Manuel Clavel, Francisco. Durán, Steven Eker, Patrick Lincoln , Narciso Marti'-Oliet
,José Meseguer, Carolyn Talcott. Maude manual (Version 2.5), June 2010.Disponible
sur: http://maude.cs.uiuc.edu/maude2-manual/maude-manual.pdf
[Clavel, 2009]
Clavel,Francisco , Durán Steven , , EkerPatrick Lincoln,Narciso ,Marti'-Oliet ,José
Meseguer ,Carolyn Talcott.Maude manual (Version 2.4), October 2008.Disponible sur :
http://maude.cs.uiuc.edu/maude2-manual/maude-manual.pdf
Ou :http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=BB2B1C9090692520F8CB
2DAAAE7D4497?doi=10.1.1.159.3218&rep=rep1&type=pdf
[Clavel, 2007a]
Manuel M. Clavel, F. Durán, S. Eker, P. Lincoln, N. Martí-Oliet,
J. Meseguer, and C. Talcott. All About Maude - A High-Performance Logical
Framework, volume 4350 of Lecture Notes in Computer Science. Springer, 2007.
[Clavel, 2007b]
M.Clavel F. Duran, S. Eker, P. Lincoln, N. Marti'-Oliet, J. Meseguer, C.Talcott.
MAUDE MANUAL (Version 2.3), SRI Inter, 2007, web
http://maude.cs.uiuc.edu/maude1/manual/
[Clavel, 2001]
M. Clavel , F. Durán , S. Eker , P. Lincoln , N. Martí-Oliet , J. F. Quesada Meseguer ,
J. F Maude: Specification and Programming in Rewriting Logic, SRI International,
June 2001.Disponible sur : http://maude.cs.uiuc.edu/papers
[Clavel, 1999]
M. and al. ―Maude: Specification and Programming in Rewriting Logic‖. Internal
report, SRI International, 1999.Disponible sur :
http://maude.csl.sri.com/papers/postscript/CDELMMQspecprog_2001.ps.gz
Ou http://maude.csl.sri.com/papers/postscript/CDELMMQmanual_1999.ps.gz
[Clavel, 1998 a]
M. Clavel, F. Durán, S. Eker, P. Lincoln, N. Mart-Oliet, J. Meseguer, and F. Quesada.
Maude as a metalanguage. In Claude Kirchner and Hélène Kirchner, editors,
Proceedings of the 2nd International Workshop on Rewriting Logic and its Applications,
WRLA‘98, volume 15, Pont-à-Mousson (France), September 1998. Electronic Notes in
Theoretical Computer Science. Disponible sur:
http://maude.cs.uiuc.edu/papers/postscript/CDELMMQmetalanguage_1998.ps.gz
[Clavel ,1998 b]
Manuel Clave. Reflection in General Logics, Rewriting Logic, and Maude (1998).
Disponible sur:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.25.2109&rep=rep1&type=pdf
[Clavel, 1996a]
P.M. Clavel , S. Eker , P, Lincoln, J. Meseguer ,Principles of Maude ,Electronic notes
in theoretical computer science 4,1996. Disponible sur :
http://www.csl.sri.com/papers/rwl96b/rwl96b.pdf
[Clavel, 1996b]
Manuel Clavel, José Meseguer. Reflection and Strategies in Rewriting Logic. In 1st
International Workshop on Rewriting Logic and its Applications (WRLA'96). Electronic
Notes in Theoretical Computer Science, Vol. 4. 1996 .Disponible sur :
http://maude.cs.uiuc.edu/papers/postscript/tcs4009.ps.gz
[Clavel, 1996c]
Manuel G. Clavel , José Mesegue.r Axiomatizing Reflective Logics and Languages 1996
,Proceedings of Reflection'96. Disponible sur :
http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/meseguer/meseguer.pdf
[Calvez, 1990] Calvez (J. P.). Spécification et conception des systèmes - Une méthodologie : MCSE.
Masson, 1990.
- 228 -
[Campbell, 2009]
J Campbell, P Gries , J Montojo, G Wilson , practical programming :An introduction
to computer science using python .the pragmatic bookshell , avril 2009.[Charroux, 2010]
Benoît Charroux,Aomar Osmani, Yann Thierry-Mieg. UML 2 Pratique de la
modélisation - Collection Synthex 3e édition 2010, le chapitre 1 disponible aussi sur :
http://www.pearson.fr/resources/download.cfm?GCOI=27440100954210&thefile=7466_c
hap01.pdf
[Charroux, 2008]
Benoît Charroux , Aomar Osmani, Yann Thierry-Mieg. UML 2 Pratique de la
modélisation - Collection Synthex 2e édition 2008, disponible aussi sur :
http://perso.efrei.fr/~charroux/livre/index.html
[Cheesman, 2000] John Cheesman, john Daniels. UML Components: A Simple Process for Specifying
Component-Based Software. Addison-Wesley, USA, 2000.
[Chen, 2003]
E. Chen,Y. Shi, D. Zhang, and G. Xu. A programming framework for service association
in ubiquitous computing environments. In Proceedings of the 2003 Joint Conference of
the fourth Pacific Rim Conference on Multimedia (ICICS-PCM 2003, 2003. Disponible
sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.155.4591&rep=rep1&type=pdf
Ou : http://media.cs.tsinghua.edu.cn/~pervasive/paper/2003/2003PCM-
CHEN%20Enyi.pdf
[Chomsky, 1956]
N. Chomsky. Three models for the description of language. IRE transactions on
Information Theory, 2 :113_124, 1956. Disponible sur :
http://www.chomsky.info/articles/195609--.PDF
[Clark, 2008]
Tony Clark, Andy Evans, Paul Sammut, and James Willans, Applied Metamodelling A
Foundation for Language Driven Development, Second Edition. Août2004.Disponible
sur :
http://www.ceteva.com/home/Papers/Applied%20Metamodelling%20%28Second%20E
dition%29.pdfOu
http://itcentre.tvu.ac.uk/~clark/docs/Applied%20Metamodelling%20%28Second%20Ed
ition%29.pdf
[Clark, 2004]
Clark. T, Evans. A, Sammut. .P, Willans. J, ―Applied Metamodelling A Foundation for
Language Driven Development Version 0.1―, 2004.Disponible sur:
http://www.uio.no/studier/emner/matnat/ifi/INF5120/v06/undervisningsmateriale/Applie
dMetamodelling.pdf
[Clarke, 2007]
Edmund M. Clarke. The Birth of Model checking .February 2007 School of Computer
Science, Carnegie Mellon University .Disponible sur:
http://www.cs.cmu.edu/~nishants/trs/cmu-cs-07-110.pdf
[Clarke, 2002] E. M. Clarke, O. Grumberg, D. A. Peled. .Model Checking. MIT Press, 2002.
[Clarke, 1999] E. M. Clarke, O. Grumberg , D. A. Peled . Model checking. MIT Press, 1999.
[Clarke, 1986]
E. M. Clarke, E. A. Emerson et A. P. Sistla .Automatic verification of finite state
Concurrent systems using temporal logic specifications. ACM Transactions on
Programming Languages and Systems, 8(2):244_263, Avril 1986. Disponible sur:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.9102&rep=rep1&type=pdf
Ou : http://research.microsoft.com/~qadeer/cse599f/papers/clarke-toplas.pdf
[Clarke, 1981]
E.M. Clarke , E. Emerson: Design and synthesis of synchronization skeletons using
branching time temporal logic. In Logics of Programs, volume 131 De LNCS. Springer-
Verlag, 1981.Disponible sur:
http://repository.cmu.edu/cgi/viewcontent.cgi?article=1451&context=compsci
[Combemale, 2008]
Combemale benoît. Approche de méta-modélisation pour la simulation et la vérification
de modèle. Thèse soutenu à l‘ENSEEIHT, juillet 2008.Disponible sur :
http://hal.archives-ouvertes.fr/docs/00/32/18/63/PDF/phd-combemale-finalversion.pdf
[Crane, 2005]
M. L. Crane, J. Dingel. On the Semantics of UML State Machines: Categorization and
Comparison, Technical Report 2005-501, School of Computing, Queen‘s University,
Canada, 2005. Disponible sur:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.69.4450
Ou : http://research.cs.queensu.ca/TechReports/Reports/2005-501.pdf
- 229 -
[Csertan, 2002]
G. Csertan, G. Huszerl, I. Majzik, Z. Pap, D. Pataricza, A. Varro. Viatra visual
automated transformations for formal verification and validation of ump models.
In Proceedings. ASE 2002. 17th IEEE International Conference. Automated Software
Engineering, September 2002 .Disponible sur
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.19.6762&rep=rep1&type=pdf
[Czarnecki, 2003]
k. Czarnecki, S. Helsen. Classification of model transformation approaches. 2003.
OOPSLA‘03 Workshop on Generative Techniques in the Context of Model-Driven
Architecture, University of Waterloo, Canada. Disponible sur
http://www.swen.uwaterloo.ca/~kczarnec/ECE750T7/czarnecki_helsen.pdf
[Czarnecki, 2006]
k. Czarnecki, S. Helsen .feature –based survey of model transformation approaches,
IBM SYSTEMS JOURNAL, VOL45, NO3, 2006.Disponible sur:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.124.9674&rep=rep1&type=pdf
[Diaz, 2009] Michel Diaz. Petri Nets: Fundamental Models, Verification and Applications. ISTE Ltd
and John Wiley & Sons, 2009
[Demuynck, 1997]
M. Demuynck , B. Meyer. Les langages de spécification : bulletin de la direction des
études et recherches , série C-Mathématiques .informatique No 1. 1979. Pp. 39.60.
Disponible sur :
http://se.ethz.ch/~meyer/publications/specification/langages_specif.pdf
[De Lara ,2005]
J., E. Guerra. Formal Support for Model Driven Development with Graph
Transformation Techniques.Disponible sur :
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-
157/paper04.pdfOu http://users.dsic.upv.es/workshops/dsdm05/files/DSDM2005-
Proceedings.pdf#page=38Ou :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.142.9190&rep=rep1&type=pdf
[De Lara ,2004]
Juan De Lara, Hans Vangheluwe, Manuel Alfonseca. Meta-modelling and graph
grammars for multi-paradigm modelling inAToM3. Software and Systems Modeling
3(3), Aug (2004) 3: 194–209 / Digital Object Identifier (DOI) 10.1007/s10270-003-0047-
5.Disponible sur:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.78.7106&rep=rep1&type=pdf
[De lara, 2002a]
.J De Lara, H Vangheluwe, ATOM3: A Tool for Multi formalism Modelling and Meta-
modelling .Disponible sur:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.24.2450&rep=rep1&type=ps
[De Lara, 2002b]
Juan de Lara, Hans Vangheluwe.Using AToM3 as a Meta-CASE Tool. In Proceedings of
the 4th International Conference on Enterprise Information Systems ICEIS‘2002, Area
3: Information Systems Analysis and Specification. pp.: 642-649. Ciudad Real. Spain.
April 2002. Disponible sur:
http://www.cs.mcgill.ca/~hv/publications/02.ICEIS.MCASE.pdf
[De Lara ,2002c]
Juan de Lara Jaramillo, Hans Vangheluwe, Manuel Alfonseca Moreno. Using Meta-
Modelling and Graph Grammars to Create Modelling Environments. Electronic Notes
in Theoretical Computer Science 72 No. 3 (2002) Disponible
sur:http://www.cs.mcgill.ca/~hv/publications/02.ICGT.GT-VMT.pdf
[De Lara ,2002d]
Juan de Lara, Hans Vangheluwe. Using Meta-Modelling and Graph Grammars to
process GPSS models, 2002. Disponible sur :
http://www.cs.mcgill.ca/~hv/publications/02.ESM.AToM3GPSS.pdfOu :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.5731&rep=rep1&type=pdf
[De lara,] J de Lara, H Vangheluwe, Types for Multi-Paradigm Modelling. Disponible sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.15.9281&rep=rep1&type=pdf
[Dershowitz, 1990]
N. Dershowitz, J.-P. Jouannaud. Rewrite systems. In J. van Leeuwen, éditeur:
Handbook of Theoretical Computer Science, Vol. B, pages 243–320. Elsevier, 1990.
Disponible sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.54.7995&rep=rep1&type=pdf
[Durán ,1999] F. Durán , J. Meseguer. The Maude specification of Full Maude. Manuscript, May 1999.
- 230 -
Disponible sur: http://maude.cs.uiuc.edu/papers/
[Gabriel, 2004]
[Gagnon, 2008]
[Gagnon, 2007]
C. Gabriel, Dorel Lucanu: ‗‘Specification and Verification of Synchronizing Concurrent
Objects ‘‘. IFM 2004: 307-327.Disponible sur:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.64.7860&rep=rep1&type=pdfo
u http://thor.info.uaic.ro/~tr/tr03-05.ps Patrice Gagnon, Farid Mokhati, Mourad Badri. Applying Model Checking to
Concurrent UML Models. University of Québec at Trois - Rivières, Canada, Vol. 7, No.
1, January-February 2008 . Disponible sur
:http://www.jot.fm/issues/issue_2008_01/article1.pdf Patrice Gagnon. Vérification
formelle de diagrammes UML : une Approche basée sur la logique de réécriture. Thèse
de la maitrise en mathématiques et informatique appliquées. L‘université de QUÉBEC
à Trois-Rivières Aout 2007 Disponible sur :
http://dmi.uqtr.ca/actrecherche/maitrises/memoires/147.pdf
[Ehrig , 1990] H. Ehrig , H.-J. Kreowski, editors. Graph grammars and their application To computer
Science, ISBN 3-540-54478-X. Springer-Verlag, 1990.
[Eker, 2003]
S. Eker, J. Meseguer, A. Shridharanarayannan. ‗‘The Maude LTL model checker and
its Implementation‘‘, T. Ball and SK Rajamani (Eds.): SPIN 2003, LNCS 2648, pp. 230–
234, 2003. Disponible sur
http://spinroot.com/spin/Workshops/ws03/Maude.pdfOu :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.10.7486&rep=rep1&type=pdf
[Eker, 2002]
S. Eker, J. Meseguer, A. Shridharanarayannan. ‗‘The Maude LTL model checker‘‘. In:
proc. WRLA‘02. Volume 71 of ENTCS., Elsevier (2002).Disponible sur :
http://maude.cs.uiuc.edu/papers/postscript/EMSltl_2002.ps.gzOù
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.6.7023&rep=rep1&type=pdf
[El Mansouri, 2008]
, Raida El Mansouri, Elhillali Kerkouche, and Allaoua Chaoui. A Graphical
Environment for Petri Nets INA Tool Based on Meta-Modelling and Graph
Grammars.World Academy of Science, Engineering and Technology 44 2008.
Disponible sur: http://www.waset.org/journals/waset/v44/v44-80.pdf
[Engelfriet , 1997]
J. Engelfriet , G. Rozenberg. Handbook of Graph Grammars and Computing by Graph
Transformation, ISBN 981-02-2884-8, chapter Node Replacement Graph Grammars,
World Scientific Publishing, 1997.
[Epi, 2009] extrait de :http://www.epi.asso.fr/revue/articles/a0509b03.gif.
[Erikson, 2004] H.E. Erikson, M. Penker, B. Lyons, D. Fado, UML 2 ToolKit, Wiley publishing, USA,
2004.
[Favre, 2004a]
Favre, J-M. .Foundations of Meta-Pyramids: Languages vs. Metamodels. Proceedings of
the International Seminar on Language Engineering for Model-Driven Software
Development, Dagstuhl Castle, Allemagne, 2004. – Disponible sur:
http://drops.dagstuhl.de/opus/volltexte/2005/21/pdf/04101.FavreJeanMarie.Paper.pdf
[Favre, 2004b]
Jean-Marie Favre: Towards a Basic Theory to Model Driven Engineering. In Workshop
on Software Model Engineering (WISME), joint event with UML, 2004, Lisboa,
2004.Disponible sur:
http://astreo.ii.uam.es/~jlara/doctorado.2006/TowardsABasicTheoryToModelModelDriv
enEngineering.pdf
[Favre, 2004c]
J.-M. Favre, Foundations of Meta-Pyramids : Languages vs. Metamodels – Episode II :
Story of Thotus the Baboon1, Dagstuhl Seminar 04101 on Language Engineering for
Model-Driven Software Development (Dagsthul, Germany), 2004.Disponible sur :
http://megaplanet.org/jean-marie-
avre/papers/FoundationsOfMetaPyramidsLanguagesVsMetamodelsEpisodeIIStoryOfTh
otusTheBaboon.pdf
[Frankel, 2003] David S. Frankel. Model Driven Architecture Applying MDAto Enterprise Computing.
Wiley Publishing, Inc, 2003.
[Fowler, 2005] M. Fowler, UML 2.0 la meilleure ressource pour la compréhension et l‘utilisation
d‘UML 2.0 et des versions antérieures, CampusPress, édition 2005.
[Fowler, 2004] M. Fowler, Kendall Scott .UML Distilled : A brief guide to the standard object modeling
language,third edition, Addison-Wesley, USA, 2004
- 231 -
[Fowler, 2003] M. Fowler, Kendall Scott UML Distilled third edition: A brief guide to the standard
object modeling language, Addison-Wesley, USA, 2003.
[Gabay, 2008] J. Gabay, YD .Gabay. UML2 analyse et conception mise en ouvre guidée avec études de
cas, DUNOD, 2008
[Grässle, 2005] Patrick Grässle, Henriette Baumann, Philippe Baumann. UML2 in Action: A Project-
Based Tutorial, Copyright © 2005 Packt Publishing, 2005.
[Gerber, 2002]
A. Gerber, M. Lawley, K. Raymond, J. Steel et A. Wood, Transformation: The Missing
Link of MDA, In proceedings of the First international conference on Graph
Transformation (ICGT 2002), Barcelona, Espagne, October 2002.Disponible sur :
http://lawley.id.au/publications/missing-link.pdf
[Guihal, 2007]
Guihal David. Modélisation en langage EN LANGAGE VHDL-AMS Des systèmes
pluridisciplinaires. Thèse de Doctorat, le 25 Mai 2007, Laboratoire d‘analyse et des
systèmes du CNRS, l‘Université Toulouse III. Disponible sur :
http://tel.archives-ouvertes.fr/docs/00/15/75/70/PDF/These_GUIHAL_Biblio.pdf
[Guiochet, 2003]
Jérémie Guiochet, Maitrise de la sécurité de la robotique de service : approche
UML basée sur une analyse du risque système. Thèse de doctorat, INSA Toulouse,
novembre 2008.Disponible sur :
http://tel.archives-
ouvertes.fr/index.php?halsid=738hqfq75ov49cok7p6fldgni5&view_this_doc=hal-
00003462&version=1.
[Harel, 2004]
David Harel, Bernhard Rumpe . Meaningful Modeling: What‘s the Semantics of
"Semantics", Computer, 37(10):64–72, 2004.Disponible sur:
http://rumpe.net/~rumpe/publications20042008/HR_ModSemantics_IEEEComp_04.pdf
[Harel, 1987]
Harel, David, ―Statecharts: A Visual Formalism for Complex Systems,‖ Science of
Computer Programming, 8, 1987, pp. 231–274 .Disponible sur:
http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf
[Hintermeier, 1995]
Hintermeier, C., Kirchner, C. et Kirchner, H. (1995). Sort Inheritance for Order-Sorted
Equational Presentations, Recent Trends in Data Types Specification, Vol. 906 of
Lecture Notes in Computer Science, Springer-Verlag, pp. 319–335.Disponible sur:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52.8709&rep=rep1&type=pdf
[Hintermeier, 1994]
Hintermeier, C., Kirchner, C. et Kirchner, H. Dynamically-Typed Computations for
Order-Sorted Equational Presentations (Extended Abstract), (1994).in S. Abiteboul et E.
Shamir (eds), Proceedings 21st International Colloquium on Automata, Languages, and
Programming, Vol. 820 of Lecture Notes in Computer Science, Springer-Verlag, pp.
450–461.Disponible sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.37.8871&rep=rep1&type=pdf
[Idani, 2006]
Akram IDANI .B/UML : Mise en relation de spécifications B et de descriptions UML
pour l'aide à la validation externe de développements formels en B. Thèse de doctorat,
l‘université de Grenoble, novembre 2006.Disponible sur
:http://tel.archives-ouvertes.fr/docs/00/11/87/18/PDF/theseAkram.pdf
[Jacobson, 2003]
JACOBSON, I. Use Cases -- Yesterday, Today, and Tomorrow, (2003) .Disponible
sur:http://www.ibm.com/developerworks/rational/library/775.html#ibm-pcon
[Jacobson, 2000]
Jacobson, I., Booch, G. & Rumbaugh, J. le processus unifié de développement logiciel,
Eyrolles, juin 2000 traduit de l‘anglais par Virgine Zaim., validation technique : Jérôme
Desquilbet.
[Jacobson, 1999] Jacobson. I, Booch. G., Rumbaugh, J. The Unified Software Development Process.
Addison Wesley, 1999.
[Jansamak, 2004]
S. Jansamak and A. Surarerks. Formalization of UML statechart models using
concurrent regular expressions. In Proceedings of the 27th Australasian Computer
Science Conference (ACSC 2004), volume 26 of CRPIT, pages 83-88. Australian
Computer Society, 2004.Disponible sur :
http://crpit.com/confpapers/CRPITV26Jansamak.pdfOu:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.6.347&rep=rep1&type=pdf
- 232 -
[JÄurjens, 2002]
J. JÄurjens. A UML statecharts semantics with message-passing. In Proceedings of the
2002 ACM Symposium on Applied Computing (SAC'02), pages 1009-1013. ACM Press,
2002 .Disponible sur : 3
http://www4.in.tum.de/publ/papers/Jur02e.pdfOu :
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.3196
[Jin, 2004]
Y. Jin, R. Esser, and J.W. Janneck. A method for describing the syntax and semantics of
UML Statecharts. Software and Systems Modeling, 3(2):150-163, 2004.Disponible Sur:
http://www.cs.adelaide.edu.au/users/esser/publications/SoSyM_291003.pdf
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.130.5060
[Jouault ,2006]
Frédéric Jouault. Contribution à l'étude des langages de transformation de modèles,
THÈSE DE DOCTORAT, Le 26 septembre 2006, l'UFR Sciences & Techniques,
Université de Nantes. Disponible sur:
http://archive.bu.univ-nantes.fr/pollux/show.action?id=5c85b1f5-71cc-4940-bba7-
69d2b3205be4
[Kadima ,2005] Hubert Kadima. Conception orienté objet guidée par les modèles. Dunod, 2005.
[Kerkouche, 2009] E Kerkouche, A Chaoui, K Khalfaoui, Transforming UML Models to Colored Petri Nets
Models using Graph Grammars.2009
[Kimmel, 2005] P. Kimmel, UML Demystified,McGraw-Hill Osborne Media, October 2005.
[Kleppe, 2003] Anneke Kleppe , Jos Warmer, Wim Bast . MDA Explained: The Model-Driven
Architecture: Practice and Promise. Addison Wesley (2003).
[Kruchten, 1999] Philippe Kruchten. The Rational Unified Process: An introduction, 1999 3éme edition.
Addison-Wesley Professional.1999.
[Kruchten, 1995a]
. Philippe Kruchten. Architectural Blueprints—the ―4+1‖ View Model of Software
Architecture .Paper published in IEEE Software 12(6), November 1995, pp. 42-50
.Disponible sur:
http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
[Kruchten, 1995b]
. Philippe Kruchten. , Rational software.The ―4+1‖ View Model of Architecture .Paper
published in IEEE Software 12(6), November 1995, pp. 42-50.Ddisponible sur:
http://www.ics.uci.edu/~andre/ics223w2006/kruchten3.pdf
[K¨uhne, 2006]
Thomas K¨uhne. Matters of (meta-) modeling. Software System Modeling, 2006.
Disponible sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.118.526&rep=rep1&type=pdf
[Lai, 2000] M. Lai. UML la notation unifiée de modélisation objet, de java aux EJB, Dunod, 2e
édition 2000.
[Lamport, 1977]
L. Lamport. Proving the correctness of multiprocess programs. IEEE Transactions on
Software Engineering, 1977.Disponible sur:
http://www.cis.umassd.edu/~hxu/courses/cis481/references/Lamport-1977.pdfOu:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.9454&rep=rep1&type=pdf
[Lano, 2000]
K. Lano, J. Bicarregui, A. Evans. Structured axiomatic semantics for UML models. In
Rigorous Object-Oriented Methods (ROOM 2000). Electronic Workshops in
Computing (eWiC), 2000. Disponible sur:
http://www.bcs.org/upload/pdf/ewic_ro00_paper5.pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.102.8339&rep=rep1&type=pdf
[Larman, 2006] C. Larman, UML 2 et les design patterns analyse et conception et développement
itératif, Pearson Education, 3e édition 2006.
[Larman, 2002 a] C. Larman, UML et les Design Patterns, Campus Press ,2002
[Larman, 2002b] Larman, C. Applying UML and Patterns: an Introduction to Object-Oriented Analysis
and Design and the Unified Process, 2ème edition. Prentice Hall PTR.
[Lee, 2000]
LEE M. Model-based Reasoning: a Principled Approach for Software Engineering:
Software – Concepts and Tools. . 2000, Vol. 19, No. 4, p.179-189. 2000 Springer-Verlag
Disponible sur :
http://www.it.iitb.ac.in/~palwencha/mtp/MBR_APP1.pdf
[Lincoln, 1994] Patrick Lincoln , Narciso Martí-Oliet , Jos , José Meseguer , P. Lincoln , N. Mart I-
oliet , J. Meseguer .Specification, Transformation, and Programming of Concurrent
- 233 -
Systems in Rewriting Logic .In G.E Blelloch ,K. M. Chandy , S. Jagannathan ,editors,
Specification of Parallel Algorithms, pages 309--339. DIMACS Series ,vol. 18, Americain
Mathematical Society,1994 . Disponible sur :
http://www.csl.sri.com/users/lincoln/papers/dimacs
[Linux-center,
2010]
.Disponible sur :
http://www.linux-center.org/articles/9812/python.html
[Llados, 2003]
J. Llados, G. Sanchez. Symbol recognition using graphs. In IEEE International
Conference on Image Processing, volume 3, pages II_ 49_52, Barcelona, Spain,
September 2003.
[Lopez, 2000] N. Lopez, J. Migueis, E. Pichon. Intégrer UML dans vos projets, Paris, 2000.
[Lu, 1991] S. W.Lu, Y. Ren, and C.Y. Suen. Hierarchical attributed graph representation and
recognition of handwritten Chinese characters. Pattern Recognition, 24:617_632, 1991.
[Lucas, 2008]
Francisco J. Lucas, Ambrosio Toval .Model Transformations powered by Rewriting
Logic. Software Engineering Research Group. Department of Informatics and Systems
University of Murcia (Spain). Disponible sur :
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-344/paper11.pdf
[Ludewig, 2003] Ludewig J. – Models in Software Engineering – An Introduction. - Software and System
Modeling.– 2003, Vol. 2, No. 1, p. 5-14 .
[Manna, 1991] Manna, Z. Pnueli, A. The Temporal Logic of Reactive and Concurrent Systems:
Specification.1991. Springer.
[Marschall, 2003]
F. Marschall and P. Braun. Model transformations for mda with botl. Disponible sur:
http://www4.in.tum.de/publ/papers/marschall_braun-mdafa03.pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.2.7991&rep=rep1&type=pdf
[Marvie ,2002]
Raphael Marvie .Séparation des préoccupations et méta-modélisation pour
environnements de manipulation d'architectures logicielles à base de composants. Thèse
de Doctorat, LIFL (laboratoire d‘Informatique Fondamentale de Lille), Université des
sciences et technologies de Lille. décembre 2002. Disponible sur :
http://www.lifl.fr/~marvie/pubs/marvie_phd.pdf.
[McCombs ,2003] , T. McCombs. ―Maude 2.0 Primer, Version 1.0‖. Internal report, SRI International,
August 2003.Disponible sur : http://maude.cs.uiuc.edu/primer/maude-primer.pdf
[Megzari, 2004]
K. Megzari, REFINER : Environnement logiciel pour le raffinement d‘architectures
logicielles fondé sur une logique de réécriture, thèse de doctorat, université de Savoie,
France, 2004.Disponible sur :
http://www.polytech.univ-
avoie.fr/fileadmin/polytech_autres_sites/sites/listic/Theses/these-Megzari-
15mars2005_Finale-2.pdf
[Mellor, 2004] Stephen j Mellor, Kendall Scott, Axel Uhl, Dirk Weise .MDA Distilled: Principles of
Model Driven Architecture. Addison-Wesley, 2004.
[Mens, 2005]
Tom Mens, Pieter Van Gorp. A Taxonomy of Model Transformations Proc. Int'l
Workshop on Graph and Model Transformation. GraMoT, 2005. Disponible sur :
http://tfs.cs.tu-berlin.de/gramot/Gramot2005/FinalVersions/PDF/MensVanGorp.pdf
Ou : http://drops.dagstuhl.de/opus/volltexte/2005/11/pdf/04101.SWM2.Paper.pdf
[Merseguer, 2002]
J. Merseguer, J. Campos, S. Bernardi, and S. Donatelli. A compositional semantics for
UML state machines aimed at performance evaluation. In Proceedings of the 6th
International Workshop on Discrete Event Systems, pages 295-302. IEEE Computer
Society Press, 2002.Disponible sur:
http://www.di.unito.it/~bernardi/MBCD02.ps.gz
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1714&rep=rep1&type=pdf
[Meseguer, 2006]
José Meseguer, Rewriting Logic and Maude: Concepts and applications, Computer
Science Laboratory, SRI International, Menlo Park, CA 94025, USA ,2006. Disponible à
:
http://www.springerlink.com/content/m13rt7v40j172t4r/
[Meseguer , 2000]
J. Meseguer. ―Rewriting logic and Maude: a Wide-Spectrum Semantic Framework for
- 234 -
Object-based Distributed Systems‖. In S. Smith and C.L. Talcott, editors, Formal
Methods for Open Object-based Distributed Systems, (FMOODS‘2000), p. 89-117.
Kluwer, 2000.
[Meseguer, 1998]
Meseguer, J. Membership algebra as a semantic framework for equational specification,
in F. Parisi-Presicce (ed.), Proceedings of WADT‘97, Lecture Notes in Computer
Science,Springer-Verlag.
[Meseguer, 1992a] J. Meseguer. Conditional rewriting logic as a unified model of concurrency. Theoretical
Computer Science, 96:73–155, 1992.
[Meseguer, 1992b]
José Meseguer and Timothy Winker . Parallel programming in Maude .In J-P
.Banatre and D . Le métayer .Editors , Research directions in High –Level Parallel
Programming Language ,pages 253-293 .Springer LNCS574,1992. Disponible à :
http://www.springerlink.com/content/pv2853p74n112021/
[Meseguer, 1992c]
J. Meseguer, ―A Logical Theory of Concurrent Objects and its Realization in the Maude
Language‖. In G. Agha, P. Wegner, and A. Yonezawa, Editors, Research Directions in
Object-Based Concurrency. MIT Press, 1992.
[Meseguer, 1990]
J. Meseguer. A logical theory of concurrent objects . in ECOOP-OOPSLA‘90
conference on Object -Oriented Programming ,Ottawa ,October 1990, pages 101-115
ACM ,1990. Disponible à : http://ifs.uni-linz.ac.at/~ecoop/cd/papers/ec90/ec900101.pdf
[Merz, 2001] Stephan Merz. Model Checking: A tutorial Overview. Disponible sur:
http://www.loria.fr/~merz/papers/mc-tutorial.pdf
[Meyer, 2005]
Antoine Meyer. Graphes infinis de présentation finie Thèse de doctorat, Université de
Rennes octobre 2005. Disponible sur : http://tel.archives-
ouvertes.fr/docs/00/32/57/07/PDF/these.pdf
[Meyer, 2001] E. Mayer .Développements formels par objets : utilisation conjointe de B et UML
.Thèse de doctorat, université Nancy 2, Loria, mars2001.
[Milicev, 2009] Dragan Milicev, Model-Driven Development with Executable UML. Wiley Publishing,
USA, 2009.
[Miralles ,2006]
A. Miralles, ingénierie des modèles pour les applications environnementales, 2006.
Disponible sur :
http://tel.archives-
ouvertes.fr/index.php?halsid=d4g7lprnv8cin86scg2nnsrvs6&view_this_doc=tel-
00279669&version=1
[Misfu ,2010] BI méthodes agiles. Extreme Programming (Methodes Agiles). Disponible Sur :
http://www.misfu.com/information-sur-le-fichier-349.html
[Mokhati, 2009] Farid Mokhati , Mourad Badri .Generating Maude Specifications From UML Use Case
Diagrams. Disponible sur: http://www.jot.fm/issues/issue_2009_03/article2.pdf
[Mokhati, 2007]
Farid Mokhati, Noura Boudiaf, Mourad Badri ,Linda Badri ―Translating AUML
Diagrams into Maude Specifications: A Formal Verification of Agents Interaction
Protocols‖. Vol. 6, No. 4, , pp 77 – 102,Mai - June 2007.Disponible sur :
http://www.jot.fm/issues/issue_2007_05/article2.pdf
[Morel, 1992] Morel Gérard. Contribution à l'automatisation et à l'ingénierie des Systèmes Intégrés
de Production. Thèse, Université de Nancy I, 1992
[Muller, 2001] P.A Muller, N. Geartner. Modélisation objet avec UML, Eyrolles, 2e édition 2000,
Deuxième tirage 2001.
[Narciso, 2001]
Narciso Martí-Oliet , José Meseguer ,Rewriting Logic: Roadmap and Bibliography
,2001disponble à :
http://maude.csl.sri.com/papers/postscript/MMroadmap_2001.ps.gzOu
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.24.2362&rep=rep1&type=pdf
[Nasrabadi, 1991] N.M. Nasrabadi, W. Li. Object recognition by a Hopfield neural network. IEEE
Transactions on systems, man, and cybernetics, 21(6):1523_1535, 1991.
[O‘Keefe, 2008]
Greg O‘Keefe .The Meaning of UML Models. .Thesis submitted for the degree of Doctor
of Philosophy at The Australian National University, September 2008, revised February
2010. Disponible sur: http://dspace.anu.edu.au/bitstream/1885/49319/2/02whole.pdf
- 235 -
[Oliet ,1996]
N. Martí-Oliet , J. Meseguer. Rewriting logic as a logical and semantic framework. En
first international workshop on rewriting logique and its application, volume4 of
Electronic Notes in Theoritical Computer science, Elsevier, 1996. Disponible à :
http://maude.csl.sri.com/papers/postscript/MMlogframework_1993.ps.gzOu
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.6357&rep=rep1&type=pdf
[OMG, 2010] OMG. UML2.OCL Specification 2.2 February 2010 .Disponible sur:
http://www.omg.org/spec/OCL/2.2/PDF/.
[OMG, 2007a]
Object Management Group, ―Unified Modeling Language: Superstructure
version2.1.1,‖ formal/2007-02-05, February2007. Disponible sur :
http://www.omg.org/spec/UML/2.1.1/Superstructure/PDF/
[OMG, 2007b] OMG, XMI Specification, December 2007. Disponible sur :
http://www.omg.org/spec/XMI/2.1.1/PDF/index.htm
[OMG, 2006a]
Object Management Group, Inc. Meta Object Facility (MOF) 2.0 Core Specification,
janvier 2006. Final adopted specification. Disponible sur:
http://www.omg.org/spec/MOF/2.0/PDF/
[OMG, 2006b] OMG. UML2 .OCL Specification 2.0 May 2006. Disponible sur :
http://www.omg.org/spec/OCL/2.0/PDF/ .
[OMG, 2006c]
Object Management Group,CORBA Component Model Specification OMG, Available
Specification Version 4.0 formal/06-04-01.Disponible sur :
http://www.omg.org/cgi-bin/doc?formal/06-04-01.pdf
[OMG, 2005 a] UML2. Superstructure Specification , July 2006 disponible sur :
http://www.omg.org/spec/UML/2.0/ Superstructure/PDF
[OMG, 2005b] UML2. Infrastructure specification, July 2006 disponible sur :
http://www.omg.org/spec/UML/2.0/Infrastructure/PDF
[OMG, 2003a] Unified Modeling Language - Specification - Version 1.5, March 2003. Disponible sur :
http://www.omg.org/cgi-bin/doc?formal/03-03-01.pdf
[OMG, 2003b]
Object Management OMG. Unified modelling language specification version 2.0
Infrastructure. Technical Report ptc/03-09-15, OMG, 2003.Disponible sur : Disponible
sur :
https://vu.fernuni-
hagen.de/lvuweb/lvu/file/FeU/Informatik/2005WS/01794/oeffentlich/UML/UML2-
Infrastructure.pdf
[OMG, 2002] , Meta Object Facility - Specification - Version 1.4, April 2002. Disponible sur
:http://www.omg.org/cgi-bin/doc?formal/02-04-03.pdf
[OMG, 1999] :Unified Modeling Language - Specification - Version 1.3, 1999. Disponible à :
www.jeckle.de/files/omg-uml-1.3.pdf
[OMG, 1997]
Object Management Group OMG. Meta Object Facility (MOF). Technical Report OMG
Document: ad/97-08-14, Sept 1997.Disponible sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.3487&rep=rep1&type=pdf
Ou :
http://www.dstc.edu.au/Research/Projects/MOF/Publications/OMG/MOF/970814.ps.gz
[Pender, 2003] Tom Pender, UML Bible. John Wiley & Sons, 2003.
[Pender, 2002] Thomas Pender. UML Weekend Crash Course, Wiley publishing, USA, 2002.
[Perdita, 2006] Perdita Stevens, Rob Pooely. Using UML. Addison-Wesley, USA, 2006.
[Pilone, 2005] D. Pilone, N. Pitman, UML 2.0 in a Nutshell, O'Reilly, 2005.
[Prakash, 2006]
Naveen Prakash ,Sangeeta Srivastava , Sangeeta Sabharwal. The Classification
Framework for Model Transformation .Journal of Computer Science 2 (2): 166-170,
2006, ISSN 1549-3636, © 2006 Science Publications. Disponible sur :
http://www.scipub.org/fulltext/jcs/jcs22166-
170.pdfhttp://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.130.9382&rep=rep1&t
ype=pdf
- 236 -
[Posse, 2002]
E posse, .J de Lara, H Vangheluwe. Processing causal block diagrams with graph
grammars in ATOM3. Disponible sur :
http://www.cs.mcgill.ca/~hv/publications/02.ETAPS.AGT.CBD.pdf
[Python, 2010] .Disponible sur : http://www.python.org/
[Quatrani, 2000] T. Quatrani. Modélisation UML avec Rational Rose Editions. Eyrolles 2000.
[Queille, 1982]
J.P. Queille, J. Sifakis: Specification and verification of concurrent systems in Cesar. In
International Symposium on Programming, volume 137 de LNCS. Springer-Verlag,
1982. Disponible sur :
http://www.springerlink.com/content/7x327643572334rw/fulltext.pdf
[Quesada, 1999] José F. Quesada. The Maude parser: Parsing and meta-parsing extended context-free
grammars. Technical Report, SRI International, Computer Science Laboratory, 1999.
[Quesada, 1997] José F. Quesada. The SCP Parsing Algorithm Based on Syntactic Constraint
Propagation.PhD thesis, Universidad de Sevilla, Spain, 1997.
[Raimbault ,2008]
Thomas Raimbault, Transition de modèles de connaissances : un système de
connaissances fondé sur OWL, Graphes Conceptuels ET UML. Thèse de doctorat,
STIM, novembre 2008. Disponible sur : http://tel.archives-
ouvertes.fr/index.php?halsid=o11rmd2u4o837kkg0jio787fg0&view_this_doc=tel-
0482664&version=1
[Reilles ,2006]
Antoine Reilles. Réécriture et compilation de confiance Thèse de doctorat. l‘Institut
National Polytechnique de Lorraine (Spécialité informatique), novembre 2006.
Disponible sur : http://www.loria.fr/~reilles/papers/manuscrit.pdf
[Reilles ,2003]
Antoine Reilles .Réécriture dans un cadre concurrent, thèse DEA ,l‘Institut National
Polytechnique de Lorraine(Spécialité Informatique),juillet 2003.Disponible sur :
http://www.loria.fr/~reilles/papers/rapportDEA.pdf
[René, 2010] René David, Hassane Alla. Discrete, Continuous, and Hybrid Petri Nets, Springer-
Verlag, Berlin, 2005.
[Robotique.wikibis,
2010]
Disponible sur :
http://www.robotique.wikibis.com/reseau_de_petri.php#cite_note-0
[Roques, 2007a] P. Roques, F. Vallée, UML en Action, de l'analyse des besoins à la conception en java,
Eyrolles 4e édition 2007.
[Roques, 2007b] P. Roques, Les cahiers du programmeur UML 2.0 modéliser une application web,
Eyrolles, 3e édition 2007.
[Roques, 2005] P. Roques, UML par la pratique : études de cas et exercices corrigés, Eyrolles, 4e édition
2005.
[Rozenberg, 1997] G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph
Transformation. World Scientific Publishing, 1997.
[Rumbaugh, 2005] Rumbaugh, I. Jacobson, G. Booch, UML 2.0 GUIDE DE REFERENCE, Campus Press,
2005.
[Rumbaugh, 1998] James Rumbaugh, Ivar. Jacobson, Grady. Booch. The Unified Language Reference
Manual UML. Addison-Wesley, USA, 1998.
[Saldhana, 2001]
John Anil Saldhana, Sol M. Shatz, Zhaoxia Hu. .Formalization of Object Behavior and
Interactions From UML Models. Concurrent Software Systems Laboratory.
Department of Computer Science .University of Illinois at Chicago. Disponible sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.3900&rep=rep1&type=pdf
Ou http://www.cs.uic.edu/~shatz/papers/ijseke01.pd
[Samek, 2009] M. SAMEK, Practical UML Statecharts in C/C++, Second Edition: Event-Driven
Programming for Embedded Systems, Elsevier , 2009.
[Schmuller, 2004] Joseph Schmuller, Sams Teach Yourself UML in 24 Hours, Third Edition Publisher:
Sams Publishing, 2004
- 237 -
[Schürr, 1995]
Schürr Andy. Specification of graph translators with triple graph grammars. In WG
‘94: Proceedings of the 20th International Workshop on Graph-Theoretic Concepts in
Computer Science, pages 151–163, London, UK, 1995. Springer-Verlag, ISBN 3-540-
59071-4.Disponible sur: http://sunsite.informatik.rwth-
aachen.de/Publications/AIB/1994/1994-12.ps.gzOù:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.249
[Seidwitz, 2003] E. Seidwitz, What Models Mean, IEEE Software (September 2003).Disponible sur:
http://www.semanticcore.org/Docs/WhatDoModelMean.pdf
[Sen, 2009]
Sagar Sen, Benoit Baudry, Hans Vangheluwe.Towards Domain-specific Model Editors
with Automatic Model Completion. Disponible sur :
http://hal.archives-ouvertes.fr/docs/00/46/85/13/PDF/Sen09c.pdf
[Sendall, 2003]
Sendall S, Kozaczynski W. Model Transformation – the Heart and Soul of Model Driven
Software Development. IEEE Software, Special Issue on Model Driven Software
Development, (Sept /Oct 2003). Disponible sur: http://lgl.epfl.ch/pub/Papers/sendall-
tech-report-EPFL-model-trans.pdf
[Spencer, 2003]
Spencer Borland. .Transforming Statechart Models to DEVS, school of Computer
Science McGill University, Montréal, Canada August, 2003.Disponible sur:
http://digitool.library.mcgill.ca/R/?func=dbin-jump-
full&object_id=80231&local_base=GEN01-MCG02
[Sinan Si Alhir,
2002]
Sinan Si Alhir. Guide to Applying the UML. 2002 Springer-Verlag New York, Inc.
[Sriplakich, 2003]
Sriplakichp Prawee., Techniques des transformations de modèles basées sur la
métamodélisation, Mémoire de DEA Systèmes Informatiques Répartis, Université Pierre
et Marie Curie, septembre 2003, 64 p., Disponible sur :
http://cvs.forge.objectweb.org/cgi-
bin/viewcvs.cgi/*checkout*/modfact/ModFactWeb/qvt/SimpleTRL.pdf?rev=1.1
[Tadao, 1989]
Tadao Murata. Petri Nets: Properties, Analysis and Applications .Proceeding of the
IEEE, vol77, No.4 APRIL 1989. Disponible sur :
http://www.cs.unc.edu/~montek/teaching/spring-04/murata-petrinets.pdf
[Taentzer, 2005]
Gabriele Taentzer, Karsten Ehrig Esther Guerra , Juan de Lara , Laszlo Lengyel ,
Tihamer Levendovszky , Ulrike Prange , Daniel Varro , Szilvia Varro-Gyapay. Model
Transformation by Graph Transformation: A Comparative Study, 2005. Disponible sur
:
http://sosym.dcs.kcl.ac.uk/events/mtip05/submissions/taentzer_ehrig_guerra_de_lara_le
ngyel_levendovszky_prange_varro_varro-
gyapay__model_transformation_by_graph_transformation_a_comparative_study.pdfO
u :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.2827&rep=rep1&type=pdf
[Timothy, 2002] Timothy J. Grose, Gary C. Doney, Stephen A.Brodsky. Mastering XMI: Java
Programming with XMI, XML, and UML. John Wiley & Sons.2002.
[Troung, 2001]
Troung Ninh Thuan .utilisation de B pour la vérification de spécifications UML et le
développement formel orienté objet .Thèse de doctorat, université Nancy 2, Loria,
mai 2006. Disponible sur :
http://tel.archives-
ouvertes.fr/index.php?halsid=1iea8dtcf20u7csbu41aj98l65&view_this_doc=tel-
00080852&version=1
[Turing, 1996]
A. Turing, On Computable Numbers, with an Application to the Entscheidungs
problem, In Proceedings of the London Mathematical Society (Series 2, volume 42, pp.
230-265), 1936.
Disponible sur : http://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf.
[Vangheluwe, 2004]
Hans Vangheluwe, Juan de Lara. Computer Automated Multi-paradigm Modelling for
Analysis and of Traffic Networks, Proceedings of the 2004 Winter Simulation
Conference, School of Computer Science, McGill University Montréal, Québec H3A
- 238 -
2A7, CANADA. Disponible sur
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128.3887&rep=rep1&type=pdf
[Vangheluwe,
2002a]
Vangheluwe, H., Lara, J., Pieter J. Mosterman. An introduction to multi-Paradigm
modelling and simulation. Dans Actes de la conférence AIS 2002 Conference, (2002).
Volume 1, pages 9.20. Lisboa, Portugal. Disponible sur :
http://www.cs.mcgill.ca/~hv/publications/02.AIS.campam.pdf
[Vangheluwe,
2002b]
H Vangheluwe, J de Lara .Meta-model are models too. Proceedings of the 2002 Winter
Simulation Conference E. Yücesan, C.-H. Chen, J. L. Snowdon, and J. M. Charnes, Eds
, pp 597-605. Disponible sur : http://www.informs-sim.org/wsc02papers/076.pdf
[Varro, 2002]
D. Varro. A formal semantics of UML Statecharts by model transition systems. In
Proceeding of the 1st International Conference on Graph Transformation (ICGT 2002),
Volume 2505 of Lecture Notes in Computer Science, pages 378-392. Springer,
2002.Disponible sur :
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.4078
[Vega, 2005]
G. Vega. Développement d'Applications à Grande Echelle par Composition de Méta-
Modèles, PhD. thesis, Université Joseph Fourier, Décembre 2005.Disponible sur :
http://tel.archives-ouvertes.fr/docs/00/05/41/26/PDF/TheseGermanVega.pdf
[Verdejo, 2003]
A. Verdejo, I. Pita, and N. Marti-Oliet. ‗‘Specification and verification of the tree
identify protocol of IEEE 1394 in rewriting logic‘‘. Formal Aspects of Computing, 14(3):
228-246, 2003. 26. Disponible sur :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1.7759&rep=rep1&type=pdf
[Warmer, 99] J.Warmer , A.kleppe. The Object Constraint Language: Precise Modeling with UML.
Addison-Wesley, USA, 1999.
[Wiki, 2010] . Disponible sur : http://fr.wikipedia.org/wiki/Syst%C3%A8me
[Wikipedia,2010]
Disponible0sur :
http://fr.wikipedia.org/wiki/M%C3%A9thode_formelle_%28informatique%29#Sp.C3.
A9cification.
[Wiskott, 1997]
L. Wiskott, J. Fellous, N. Krüger, and C. Von Der Malsburg. Face recognition by elastic
bunch graph matching. IEEE Transactions on Pattern Analysis And Machine
Intelligence, 1997.Disponible sur :
http://www.face-rec.org/algorithms/EBGM/WisFelKrue99-FaceRecognition-
JainBook.pdf
[Wu, 2010] Naiqi Wu, MengChu Zhou. System Modeling and Control with Resource-Oriented Petri
Nets. Taylor and Francis Group, LLC, 2010.
[Ximeng, 2007]
Ximeng Sun. A Model-Driven Approach to Scenario-Based Requirements Engineering,
School of Computer Science McGill University, Montréal, Canada, 2007.Disponible sur:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.3035&rep=rep1&type=pdf
Ou : http://moncs.cs.mcgill.ca/people/simon/publications/thesis_singlesided.pdf
[Zeitoun ,2010]
Marc Zeitoun, Pierre Moro. Vérification automatique de systèmes : Note de cours
maitrise, LIAFA, Université. Paris 7 & CNRS. Disponible sur :
http://www.liafa.jussieu.fr/~moro/Cours/Maitrise/Poly.pdf
[Ziadé, 2006a] T. Ziadé, programmation python, Eyrolles 2006
[Ziadé, 2006b] T. Ziadé, programmation python conception et optimisation, Eyrolles 2006.
- 239 -
RééSUMéé
- 240 -
.
rrééssuumméé
Les diagrammes d‟états-transitions d‟UML décrivent le comportement interne d‟un objet à
l‟aide d‟un automate à états finis. Puisque UML est un lagunage semi formel, les diagrammes d‟états-
transitions se distinguent par une syntaxe bien définie et une sémantique ambigüe et non précise.
Cette approche propose une transformation des diagrammes d'état/Transition vers le langage
de réécriture Maude. Cette approche est basée sur la transformation de modèles qui permet de générer
du code automatiquement à partir d'un graphe, via une grammaire de Transformation proposée par un
outil de multi-modélisation ATOM3. La motivation de cette transformation vers Maude est d‟enrichir
la sémantique des diagrammes d‟états –transition.
Mots Clés : UML, les diagrammes d‟états-transitions, Maude, transformation de modèles, génération
de code, ATOM3.
AABBSSTTRRAACCTT
The diagrams of states-transitions from UML describe the internal behavior of one
object using an automat in finished states. Since UML is a formal semi language, the diagrams
of states-transitions are characterized by a well-defined syntax and an ambiguous and non-
precise semantics.
This approach proposes a transformation of the diagrams of state/Transition towards
the language from Maude rewriting. This approach is based on the transformation of models
which makes it possible automatically to generate code starting from a graph, via a grammar of
Transformation suggested by a tool of multi-modeling ATOM3. The motivation of this
transformation towards Maude is to enrich semantics of the diagrams of states – transition.
Key Words: UML, diagrams of state-transitions, Maude, transformation of models,
generation of code, ATOM3.
صـــملخ
باستعمالسهىك انذاخهً ان تصف(UML)نهفشد انتحىلاث انخاصت بانهغت انمىحذة نهتصمٍماث-مىحىٍاث انحالاث
انتحىلاث تتمٍز -نتصمٍماث شبه صشٌحت، فان مىحىٍاث انحالاثانهغت انمىحذة انخاصت بما أن انمىتهٍت، ماث نهحالاثالأتى
بىحى محذد و بذلانت غامضت وغٍش دقٍقت.
ىٌم وٌستىذ هزا انىهج عهى تح،مىد كتابتانعادة انتحىلاث وحى نغت ا-ٌقتشح تحىٌم مىحىٍاث انحالاث هزا انىهج
قتشحه تتحىٌم انىحىي انزي اننشسم انبٍاوً، عه طشٌق مه ا اوطلاقا اأوتىماتٍكٍ سمز إوشاء انىمارج انتً تجعم مه انممكه
. مىد هى إثشاء دلالاث انمخططاث وحى انذافع نهزا انتحىل ، ATOM 3انىمزجتانمتعذدة أداة
، تحىٌم انىمارج ،إوشاء انشمز انتحىلاث، مىد،-مىحىٍاث انحالاث ، UMLانهغت انمىحذة نهتصمٍماث : الكلمات المفتاحية
ATOM3.