REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE 20 AOUT 1955 − SKIKDA
Faculté des Sciences de l’Ingénieur
Département d’Informatique
Ecole Doctorale de l’Est – Pôle ANNABA
MEMOIRE
Présenté en vue de l’obtention du diplôme de MAGISTER en INFORMATIQUE
Ecole Doctorale en Informatique de l’Est – EDI Est
Option : GENIE LOGICIEL
Une Approche de transformation des diagrammes D’activité d’UML vers CSP basée sur la
transformation de graphes
Par
Houda HAMROUCHE
Composition du jury
Kholladi Mohamed Khireddine Maître de Conférences, Université de Constantine Président Chaoui Allaoua Maître de Conférences, Université de Constantine Rapporteur Saidouni Djamel Eddine Maître de Conférences, Université de Constantine Examinateur Maazouzi Smaine Maître de Conférences, Université de Skikda Examinateur
i
Merci mon Dieu de m’avoir donné la force, la patience et la volonté d’arriver au
terme de ce travail.
Je dédie ce modeste travail
à l’âme de ma tante Houria.
ii
Remerciements
Je tiens à remercier vivement Dr Chaoui Allaoua d’avoir accepté de diriger ce travail, je le remercie infiniment pour sa patience et son soutien. Je tiens à remercier Dr Kholladi Mohamed Khireddine de m’avoir fait l’honneur d’accepter de présider l’ensemble des membres de mon jury. Je remercie également Dr Saidouni Djamel Eddine et Dr Maazouzi Smaine d’avoir accepté de juger ce travail. Je remercie également Mlle Hanene Boukerma pour son aide et son soutien.
Je remercie tout particulièrement mon mari, ma famille, mes collègues et mes amies.
En fin, je tiens à remercier tous ceux qui ont contribué d’une façon ou d’une autre à la réalisation de ce mémoire.
iii
Table des matières Introduction 1
1. Les diagrammes d’activités d’UML2.0 4
1.1. Introduction………………………………………………………………………… 4
1.2. Les diagrammes UML……………………………………………………………… 5
1.2.1 Diagrammes structurels……………………………………………………. 5
1.2.2 Diagrammes comportementaux ……………………………........................ 6
1.3. Les diagrammes d’activité…………………………............................................ 8
1.3.1. Définition…………………………………….............................................. 8
1.3.2. Intérêts des diagrammes d’activité………………………………………… 9
1.3.3. Composition d’un diagramme d’activité………………………………….. 10
1.3.3.1. Les nœuds (nodes) ………………………………………………….. 11 1.3.3.1.1 Un noeud d’activité ……………………………………….. 11
A. Noeud d’objet (object node) ………………………………... 13
A.1. Broche (pin)…………………………………………… 13
A.2. Noeud paramètre d’activité (activity parameter node)... 14
A.3. Noeud central de mémoire tampon (central buffer node). 14
A.4. Noeud d’expansion (expansion node)…………………. 15
B. Noeud de contrôle (control node) ………………………….. 15
B.1. Noeud initial (initial node)……………………………. 16
B.2. Noeud final (final node)………………………………. 16
B.3. Noeud de fusion ou interclassement (merge node)…… 16
B.4. Noeud de décision (decision node)…………………… 16
B.5. Noeud de bifurcation (fork node)…………………….. 17
B.6. Noeud d’union (join node)…………………………… 17
C. Noeud exécutable (executable node) …………………….... 18
1.3.3.1.2. Partition d’activité (activity partition). ………………… 19
1.3.3.1.3. Région d’activité interruptible………………………….. 20
1.3.3.1.4. Région d’expansion (expansion region) ………………... 20
1.3.3.1.5. Pré-condition ou post-condition locale. ……………….. 21
1.3.3.1.6. Ensemble de paramètres (parameter set). ……………… 21
1.3.3.2. Les arcs (edges) ………………..………………..………………… 21
1.3.3.2.1. Flux de contrôle………..………………..……………… 22
iv
1.3.3.2.2. Flux d’objet………..………………..………………….. 22
1.3.3.2.3. Handler d’exception………..…………………………... 22
1.4. Conclusion…………………………….…………………………………………. 23
2. Le langage CSP « Communicating Sequential Processes » 24
2.1. Introduction………..……………………….………..…………………………… 24
2.2. Historique………………………………………………………………………… 25
2.3. Communicating Sequential Processes…………………………………………… 25
2.3.1. Définition ………………………………………………………… 25
2.3.2. Non déterminisme………………………………………………… 26
2.3.3. Deadlock………………………………………………………….. 26
2.3.4. Livelock…………………………………………………………… 26
2.3.5. Evènement………………………………………………………… 27
2.3.6. Processus………………………………………………………….. 27
2.4. Communication et Synchronisation…………………………………………….. 27
2.5. Opérateurs fondamentaux………………………………………………………. 28
2.5.1. Alphabet……………………………………………………………. 28
2.5.2. Notation préfixe………………………………………………….. 28
2.5.3. Récursivité……………………………………………………….. 29
2.5.4. Opérateurs de choix……………………………………………… 29
2.5.5. Evènements cachés (hiding)……………………………………… 31
2.5.6. Composition parallèle……………………………………………. 31
2.5.7. Entrelacement…………………………………………………….. 31
2.5.8. Entrées et sorties………………………………………………….. 32
2.6. Syntaxe du CSP…………………………………………………………………. 32
2.7. Trace…………………………………………………………………………….. 33
2.8. Echecs……………………………………………………………………………. 33
2.9. Divergences………………………………………………………………………. 33
2.10. Approches sémantiques…………………………………………………………. 34
2.10.1. La sémantique opérationnelle……………………………………. 34
2.10.2. La sémantique dénotationnelle…………………………………… 34
2.10.3. La sémantique algébrique………………………………………... 34
2.11. Points forts du CSP…………………………………………………………….. 35
2.12. Outils……………………………………………………………………………. 35
v
2.13. Conclusion………………………………………………………………………. 36
3. Transformation de graphes et ATOM3 37
3.1. Introduction………………………………………………………………………. 37
3.2. L’architecture dirigée par les modèles (MDA) ………………………………….. 38
3.2.1. Notion de modèle………………………………………………………. 38
3.2.2. Transformation de modèles……………………………………………... 39
3.2.3. Méta-Modélisation et transformation…………………………………… 40
3.2.4. Classification des approches de transformation………………………… 41
3.2.4.1. Transformations de type Modèle vers code……………………. 42
3.2.4.2 Transformations de type modèle vers modèle………………….. 42
3.3. Transformation de graphes………………………………………………………. 44
3.3.1. Graphes et digraphes…………………………………………………… 44
3.3.2. Grammaires de graphes ……………………………………………….. 46
3. 3.3. Approches de transformation de graphes ……………………………... 49
3.3.4. Outils de transformation de graphes……………………………………. 50
3.3.5. AToM³………………………………………………………………….. 51
3.4. Conclusion……………………………………………………………………….. 53
4. Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée
sur la transformation de graphes 54
4.1 Introduction………………………………………………………………………. 54
4.2. Les diagrammes d’activités……………………………………………………… 55
4.3. Le langage CSP………………………………………………………………….. 56
4.4. Présentation des correspondances entre diagrammes d’activité et CSP………… 56
4.5. Transformation des diagrammes d’activité d’UML vers CSP………………….. 58
4.5.1. Méta-Modélisation des Diagrammes d’activité ………………………... 58
4.5.1.1. Méta-modèle des diagrammes d’activité………………………. 58
4.5.1.1.1. Les associations ……………………………………… 60
4.5.1.1.2. Les classes……………………………………………. 60
1. Classe InitialNode…………………………………... 60
2. Classe ActionNode…………………………………. 60
3. Classe DecisionNode……………………………….. 61
4. Classe ForkNode…………………………………… 62
vi
5. Classe MergeNode…………………………………. 63
6. Classe JoinNode……………………………………. 64
7. Classe FinalNode…………………………………... 65
4.5.1.2. Génération de l’outil de modélisation des diagrammes d’activité. 66
4.5.2. Grammaire de graphe pour la transformation des diagrammes d’activité
d’UML vers CSP……………………………………………………….. 67
4.5.2.1. Description des règles…………………………………………. 67
4.5.2.2. Représentation graphique des règles………………………….. 74
4.5.3. Exemple de transformation d’un diagramme d’activité vers CSP……... 80
4.6. Conclusion……………………………………………………………………… 83
Conclusion générale 84
Bibliographie 86
vii
Liste des figures
Figure 1.1 : Evolution des versions d’UML…………………………………………. 5
Figure 1.2 : La hiérarchie des diagrammes UML 2.0………..………………………. 8
Figure 1.3 : Exemple de diagramme d’activité. 9
Figure 1.4 : Exemple d’activité avec paramètre d’entrée [OMG09]………………… 12
Figure 1.5 : Notation noeuds d’activité. 12
Figure 1.6 : Arbre de spécialisation du nœud d’objet………………………………. 13
Figure 1.7 : Notation nœud d’objet…………………………………………………. 13
Figure 1.8 : Notation pin……………………………………………………………. 14
Figure 1.9 : Deux représentations équivalentes pour représenter un flux d’objet….. 14
Figure 1.10 : Arbre de spécialisation des nœuds de contrôle……………………..... 15
Figure 1.11 : Représentation graphique des noeuds de contrôles………………….. 15
Figure 1.12 : Notation nœud de décision…………………………………………… 17
Figure 1.13 : Exemple illustre l’utilisation des nœuds de contrôle………………… 18
Figure 1.14 : Exemple d’une action avec des pré-conditions et post-conditions….. 19
Figure 1.15 : Exemple illustratif (partitions d’activités)…………………………… 20
Figure 1.16 : Région d’expansion………………………………………………….. 21
Figure 1.17 : Arc d’activité………………………………………………………… 21
Figure 1.18 : Notation flux de contrôle……………………………………………. 22
Figure 1.19 : Notation Flux d’objet………………………………………………… 22
Figure 1.20 : Notation d’un handler d’exception…………………………………... 23
Figure 2.1 : Comportement du processus P1………………………………………. 29
Figure 2.2 : Comportements des deux processus avec le choix……………………. 30
Figure 3.1: Model Driven Architecture (OMG)……………………..……………... 38
Figure 3.2 : Processus de transformations de modèles de l’approche MDA……….. 39
Figure 3.3 : Pyramide de modélisation de l’OMG……………..……………........... 40
Figure 3.4 : Types de transformations et leurs principales utilisations……………... 41
Figure 3.5 : Graphe non orienté. ……………..……………..……………..……….. 45
Figure 3.6 : (a) graphe G (b) sous-graphe de G. ……………..………………………. 45
Figure 3.7 : Graphe orienté. ……………..……………..……………..……………. 45
Figure 3.8 : Graphe étiqueté. ……………..……………..……………..…………… 46
viii
Figure 3.9 : Graphe complet. ……………..……………..……………..………….. 46
Figure 3.10 : Modification de graphes basée règle. ……………..………………… 47
Figure 3.11: (a) LHS de la règle (b) RHS de la règle……………..……………. 48
Figure 3.12 : Exemple d’édition d’une contrainte en AToM³.…………………….. 51
Figure 3.13: Edition d’une grammaire de graphe en AToM³……………..……….. 52 Figure 4.1 : Un exemple de diagramme d’activité………………………………… 55
Figure 4.2 : Représentation des correspondances entre diagrammes d’activités et CSP
……………………………………………………………………………………… 57
Figure 4.3 : Le méta-modèle des diagrammes d’activités……………………….. 59 Figure 4.4 : La classe InitialNode…………………………………………………. 60
Figure 4.5 : La classe ActionNode………………………………………………… 61
Figure 4.6 : La classe DecisionNode………………………………………………. 62
Figure 4.7 : La classe ForkNode…………………………………………………………. 63
Figure 4.8 : La classe MergeNode………………………………………………… 64
Figure 4.9 : La classe JoinNode…………………………………………………… 65
Figure 4.10 : La classe FinalNode………………………………………………… 65
Figure 4.11 : Outil généré pour modéliser les Diagrammes d’activités…………... 66
Figure 4.12 : Représentation graphique des nœuds du diagramme d’activités……. 66
Figure 4.13 : Grammaire de graphe pour la génération du code csp à partir des
diagrammes d’activités………………………………………….. 74 - 80
Figure 4.14 : Exemple de diagramme d’activités crée par notre outil……………. 81
Figure 4.15: Grammaire de graphe en cours d’exécution………………………… 82
Figure 4.16: Code CSP équivalent au diagramme d’activité présenté dans la
figure 4.14………………………………………………………….. 83
ix
Résumé
Actuellement, l’UML est devenu un standard largement accepté dans l'industrie de
développement de logiciels orienté objet. Certains diagrammes d’UML sont utilisés pour
modéliser la structure d'un système, d'autres sont utilisés pour modéliser son comportement.
Les diagrammes d’état transition et les diagrammes d’interaction sont largement utilisés
pour modéliser le comportement dynamique en UML. Les diagrammes d’état transition
modélisent les états du cycle de vie d'un objet en réponse aux événements. Les diagrammes
d’interaction modélisent l'interaction entre un ensemble d'objets à travers les messages (ou
événements) qui peuvent être envoyés entre eux.
Les diagrammes d'activité sont utilisés pour modéliser les systèmes workflow, les
systèmes orientés services et les processus métiers. Le flux de contrôle inclut un support
pour le séquencement, le choix, le parallélisme et les événements. Les activités peuvent être
regroupées en sous activités et peuvent être imbriquées à différents niveaux.
Toutefois, l'UML est un langage semi formel qui n'a pas des constructions définies
rigoureusement.
Communicating Sequential Processes (CSP) [Hoare85] est un langage formel pour
décrire les modèles d’interaction dans les systèmes concurrents. C’est un membre de la
famille des théories mathématiques de concurrence nommé algèbre de processus ou calcul de
processus. CSP a été proposé en 1978 par C. A. R. Hoare, après, il a des applications dans
l’industrie comme outil de spécification et de vérification des aspects concurrents de
différents systèmes.
Donc, UML et CSP ont des caractéristiques complémentaires: UML peut être utilisé pour
la modélisation alors que CSP peut être utilisé pour l’analyse.
L’objectif visé dans ce mémoire et de proposer une approche automatique de
transformation des diagrammes d’activité d’UML vers CSP, basée sur la transformation de
graphes, et réalisée à l’aide de l’outil ATOM³.
Notre approche consiste à proposer un méta-modèle des diagrammes d’activité et une
grammaire de graphes.
Mots clés : Diagrammes d’activité d’UML, CSP, Transformation de graphes, ATOM³
4
Chapitre 1
Les diagrammes d’activité d’UML2.0 1.1. Introduction
Le langage de modélisation objet unifié UML (Unified Modeling Language), est né de la
fusion des trois méthodes objet : OMT (Object Modeling Technique) de James Rumbaugh,
OOSE (Object Oriented Software Engineering) de Ivar Jacobson, et la méthode de Grady
Booch. Puis il est normalisé par l'OMG en 1997 dans sa version 1.1 comme langage de
modélisation des systèmes d’information à objets. UML est rapidement devenu un standard
incontournable. [UML98]
Au niveau de Unified Modeling Language, deux éléments importants sont à noter. Le
terme unified et le terme langage. Le premier terme signifie que les auteurs ont essayé de
regrouper les éléments importants des concepts objets, alors que le deuxième montre qu'il
s'agit d'un langage de modélisation et non d'une méthode.
UML est un langage qui permet de modéliser non seulement des applications
informatiques ou des structures de données, mais également les activités d'un domaine :
mécanique, biologie, processus métier... [Perochon09].
Plus précisément, UML permet d’offrir des outils d’analyse, de conception et
d’implémentation des systèmes logiciels, ainsi que pour la modélisation d'entreprise et des
systèmes non logiciels [OMG09]. Ce langage de modélisation unifié repose sur deux concepts
essentiels :
1- La modélisation du monde réel au moyen de l'approche orientée objet.
2- L’élaboration d'une série de diagrammes facilitant l'analyse et la conception des
systèmes, et permettant de représenter les aspects statiques et dynamiques du
domaine à modéliser ou à informatiser.
Chapitre 1: Les diagrammes d’activité d’UML2.0
5
La figure ci-dessous, présente l’évolution des versions d’UML.
Figure 1.1 : Evolution des versions d’UML.
Le but de ce chapitre est de donner une description détaillée de l’un des diagrammes
fondamentaux d’UML, qui est le diagramme d’activité.
1.2. Les Diagrammes UML
UML 2.0 propose treize types de diagrammes (9 en UML 1.3) pour représenter les
différents points de vue de modélisation. Ils se répartissent en deux grands groupes :
1- Diagrammes structurels (Structure Diagram).
2- Diagrammes comportementaux (Behavior Diagram).
1.2.1. Diagrammes structurels ou diagrammes statiques (Structure Diagram)
Ces diagrammes permettent de visualiser, spécifier, construire et documenter l'aspect
statique ou structurel du système informatisé.
Diagramme de classes (Class diagram): Le but d’un diagramme de
classes est d’exprimer de manière générale la structure statique d'un
système, en terme de classes et de relations entre ces classes. Une classe a
des attributs, des opérations et des relations avec d’autres classes.
Chapitre 1: Les diagrammes d’activité d’UML2.0
6
Diagramme d'objets (Object diagram): Le diagramme d'objet permet
d'éclairer un diagramme de classe en l'illustrant par des exemples. Il
montre des objets et des liens entre ces objets (les objets sont des instances
de classes dans un état particulier).
Diagramme de composants (Component diagram) : il montre les
composants du système d'un point de vue physique, tels qu'ils sont mis en
œuvre (fichiers, bibliothèques, bases de données...). Il montre la mise en
oeuvre physique des modèles de la vue logique avec l'environnement de
développement.
Diagramme de déploiement (Deployment diagram) : Ce type de
diagramme UML montre la disposition physique des matériels qui
composent le système (ordinateurs, périphériques, réseaux...) et la
répartition des composants sur ces matériels. Les ressources matérielles
sont représentées sous forme de noeuds, connectés par un support de
communication.
Diagramme des paquetages (Package Diagram) : un paquetage est un
conteneur logique permettant de regrouper et d'organiser les éléments dans
le modèle UML, il sert à représenter les dépendances entre paquetages.
Diagramme de structure composite (Composite Structure Diagram) : Le
diagramme de structure composite permet de décrire sous forme de boîte
blanche les relations entre les composants d'une seule classe.
1.2.2. Diagrammes comportementaux ou diagrammes dynamiques (Behavior Diagram)
Les diagrammes comportementaux modélisent les aspects dynamiques du système. Ces
aspects incluent les interactions entre le système et ses différents acteurs, ainsi que la façon
dont les différents objets contenus dans le système communiquent entre eux.
Diagramme des cas d'utilisation (Use Case Diagram) : Les cas
d'utilisation sont une technique de description du système étudié selon le
point de vue de l'utilisateur. Ils décrivent sous la forme d'actions et de
réactions le comportement d'un système. Donc, le diagramme des cas
d’utilisation, permet d'identifier les possibilités d'interaction entre le
Chapitre 1: Les diagrammes d’activité d’UML2.0
7
système et les acteurs. Il permet de clarifier, filtrer et organiser les
besoins.
Diagramme d'activité (Activity Diagram) : Un diagramme d’activité est
une variante des diagrammes d'états-transitions. Il permet de représenter
graphiquement le comportement d'une méthode ou le déroulement d'un
cas d'utilisation. dans un diagramme d’activité les états correspondent à
l’exécution d’actions ou d’activités et les transitions sont automatiques.
Diagramme états-transitions (State Machine Diagram) : permet de
décrire sous forme de machine à états finis le comportement du système
ou de ses composants. Il est composé d’un ensemble d’états, reliés par des
arcs orientés qui décrivent les transitions.
Diagramme de séquence (Sequence Diagram) : Il représente
séquentiellement le déroulement des traitements et des interactions entre
les éléments du système et/ou de ses acteurs. Le diagramme de séquence
peut servir à illustrer un cas d'utilisation.
Diagramme de communication (Communication Diagram) : C’est une
représentation simplifiée d'un diagramme de séquence, en se concentrant
sur les échanges de messages entre les objets.
Diagramme global d'interaction (Interaction Overview Diagram) :
permet de décrire les enchaînements possibles entre les scénarios
préalablement identifiés sous forme de diagrammes de séquences
(variante du diagramme d'activité).
Diagramme de temps (Timing Diagram) : Le diagramme de temps
permet de décrire les variations d'une donnée au cours du temps.
La figure 1.2, montre la hiérarchie des diagrammes d’UML 2.0.
Chapitre 1: Les diagrammes d’activité d’UML2.0
8
Figure 1.2 : La hiérarchie des diagrammes UML 2.0.
1.3. Les diagrammes d’activité
1.3.1. Définition
UML permet de représenter graphiquement les aspects dynamiques des systèmes à l’aide
de plusieurs diagrammes comportementaux. Parmi eux, on distingue les diagrammes d'activité
qui permettent de mettre l’accent sur les traitements. Ils sont utilisés pour représenter le
comportement d’une méthode ou le déroulement d’un cas d’utilisation. [UML98]
Un diagramme d’activité est une variante des diagrammes d’états-transitions, dans lequel
les états correspondent à l’exécution d’actions ou d’activités, et les transitions sont
automatiques (les transitions sont déclenchées par la fin d'une activité et provoquent le début
immédiat d'une autre). Un diagramme d’activité peut être attaché à n’importe quel élément de
modélisation afin de visualiser, spécifier, construire ou documenter le comportement de cet
élément. [Audibert08]
Les diagrammes d’activité d’UML constituent un outil de modélisation des systèmes
workflows, des modèles orientés service et des processus métiers (ils montrent l'enchaînement
des activités qui concourent au processus). Un modèle d’activité consiste en activités liées
Chapitre 1: Les diagrammes d’activité d’UML2.0
9
par des flux de données et de contrôle. Une activité peut varier d’une tâche humaine à une
tâche complètement automatisée.
La différence principale entre les diagrammes d’interaction et les diagrammes d’activité,
est que les premiers modélisent le flot de contrôle entre objets, alors que les seconds sont
utilisés pour modéliser le flot de contrôle entre activités.
Figure 1.3 : Exemple de diagramme d’activité.
1.3.2. Intérêts des diagrammes d’activité
Représenter graphiquement le comportement interne d’une opération, d’une classe ou
d’un cas d’utilisation sous forme d’une suite d’actions.
Chapitre 1: Les diagrammes d’activité d’UML2.0
10
Utiliser le mécanisme de synchronisation pour représenter les successions d’états
synchrones, alors que les diagrammes d’états-transitions sont utilisés principalement
pour représenter les suites d’états asynchrones.
Utiliser des transitions automatiques évite la nécessité d’existence d’évènement de
transition pour avoir un changement d’états.
Modéliser un workflow dans un cas d’utilisation, ou entre plusieurs cas d’utilisations.
Définir avec précision les traitements qui ont cours au sein du système, Certains
algorithmes ou calculs nécessitent de la part du modélisateur une description poussée.
Spécifier une opération (décrire la logique d’une opération).
Le diagramme d’activité est le plus approprié pour modéliser la dynamique d’une
tâche ou d’un cas d’utilisation, lorsque le diagramme de classe n’est pas encore
stabilisé. [AD]
1.3.3. Composition d’un diagramme d’activité
Les définitions de cette partie ont été inspirées essentiellement de [OMG09].
Les éléments qui peuvent être contenus dans un diagramme d’activité sont :
1. Les nœuds (nodes) [UML05]
1.1. Noeud d’activité (activity node)
A. Noeud d’objet (object node)
Broche (pin).
Noeud paramètre d’activité (activity parameter node).
Noeud central de mémoire tampon (central buffer node).
Noeud d’expansion (expansion node).
B. Noeud de contrôle (control node)
Noeud initial (initial node).
Noeud final (final node).
Noeud de fusion ou interclassement (merge node).
Noeud de décision (decision node).
Noeud de bifurcation (fork node).
Chapitre 1: Les diagrammes d’activité d’UML2.0
11
Noeud d’union (join node).
C. Noeud exécutable (executable node).
1.2. Une partition d’activité (activity partition).
1.3. Une région d’activité interruptible (interruptible activity region).
1.4. Une région d’expansion (expansion region).
1.5. Une pré-condition ou post-condition locale.
1.6. Un ensemble de paramètres (parameter set).
2. Les arcs (edges)
2.1. Flot de contrôle (control flow).
2.2. Flot d’objet (object flow).
2.3. Un handler d’exception (exception handler).
1.3.3.1. Les noeuds
1.3.3.1.1. Nœud d’activité (Activity Node)
Définition 1. Une activité
Une activité est la spécification du comportement paramétré par un séquencement organisé
d’unités subordonnées, dont les éléments simples sont les actions. Le flux de contrôle reste
dans l’activité jusqu’à ce que les traitements soient terminés, et le flot d’exécution est
modélisé par des noeuds reliés par des arcs.
Une activité est un comportement, et à ce titre peut être associée à des paramètres. Une
activité regroupant des noeuds et des arcs est appelée un groupe d’activités.
Chapitre 1: Les diagrammes d’activité d’UML2.0
12
Figure 1.4 : Exemple d’activité avec paramètre d’entrée [OMG09].
Définition2. Un noeud d’activité
Un noeud d’activité est une classe abstraite permettant de représenter les étapes le long
du flux d’une activité. Un nœud d’activité peut être l’exécution d’un comportement
subordonné, comme un calcul arithmétique, un appel à une opération, ou la manipulation du
contenu d’un objet. Les nœuds d’activité comprennent également le flux de contrôle des
constructions, tel que la synchronisation, la décision et la concurrence.
Il existe trois types de noeuds d’activités :
les noeuds d’exécutions (executable node).
les noeuds objets (object node).
les noeud de contrôle (control nodes).
La figure ci-dessus représente graphiquement les nœuds d’activité.
Figure 1.5 : Notation noeuds d’activité.
Chapitre 1: Les diagrammes d’activité d’UML2.0
13
On trouve de gauche vers la droite : le nœud d’action, un nœud objet, un nœud de
décision ou de fusion, un nœud de bifurcation ou d’union, un nœud initial, un nœud final et un
nœud final de flux.
A. Un noeud d’objet (object node)
Un noeud d’objet est une méta-classe abstraite permettant de définir les flux d’objets
dans les diagrammes d’activité. Il représente l’existence d’un objet généré par une action dans
une activité et utilisé par d’autres actions. La figure 1.6 présente l’arbre de spécialisation du
nœud d’objet.
Figure 1.6 : Arbre de spécialisation du nœud d’objet.
Un nœud d’objet est noté par un rectangle contenant le nom du nœud. Le nœud d’objet
avec un signal comme type, est affiché par le symbole à droite de la figure 1.7.
Figure 1.7 : Notation nœud d’objet.
A.1. Broche (Pin)
Une broche (Pin) est un noeud objet connecté en entrée ou en sortie d’une activité.
L’activité ne peut débuter qu’après l’affectation d’une valeur à chacun de ses pins d’entrée.
Chapitre 1: Les diagrammes d’activité d’UML2.0
14
Quand l’activité se termine (après une modification des valeurs d’entrée), une valeur doit être
affectée à chacun de ses pins de sortie. Les traitements ne sont visibles qu’à l’intérieur de
l’activité. La figure ci-dessous présente graphiquement les deux types de pin : pin d’entrée et
pin de sortie.
Figure 1.8 : Notation pin.
Conceptuellement, la notation de noeud objet ne devrait pas avoir d’instances dans les
modèles (le nœud d’objet est une classe abstraite), La figure 1.9 donne deux représentations
équivalentes de flux d’objets entre deux actions. La première représentation utilise des pins,
alors que la deuxième utilise la notation d’un noeud objet.
Figure 1.9 : Deux représentations équivalentes pour représenter un flux d’objet.
A.2. Noeud paramètre d’activité (Activity Parameter Node) :
C’est l’un des noeuds objet, il décrit les entrées ou les sorties des activités. Il est
toujours associé avec un paramètre de l’activité.
A.3. Noeud central de mémoire tampon (central buffer node) :
Un nœud central de mémoire tampon est un nœud d’objet, destiné pour la gestion des
flux provenant de multiples sources. Il peut avoir plusieurs arcs entrants et plusieurs arcs
sortants. Graphiquement, on utilise le mot clé < centralBuffer > associé à la notation d’un
noeud objet.
Chapitre 1: Les diagrammes d’activité d’UML2.0
15
A.4. Noeud d’expansion (expansion node)
Un noeud d’expansion ou expansion node est un noeud d’objet qui peut être utilisé pour
indiquer un flux à travers les limites d’une région d’expansion. (Paragraphe 1.3.3.1.4)
B. Noeud de contrôle (control node)
Un noeud de contrôle est un noeud d’activités abstrait utilisé pour coordonner les flux
entre les noeuds d’une activité. La figure ci-dessous présente l’arbre de spécialisation des
noeuds de contrôle.
Figure 1.10 : Arbre de spécialisation des nœuds de contrôle.
Graphiquement, les nœuds de contrôle sont présentés comme suit :
Figure 1.11 : Représentation graphique des noeuds de contrôles.
Chapitre 1: Les diagrammes d’activité d’UML2.0
16
B.1. Noeud initial (initial node)
Un noeud initial est un noeud de contrôle à partir duquel le flot débute. Il possède un arc
sortant et pas d’arc entrant. Dans une activité on peut avoir plusieurs noeuds initiaux.
B.2.Un noeud final (final node)
Un noeud final est un noeud de contrôle dans lequel le flux d’activité s’arrête. Un noeud
final peut avoir un ou plusieurs arcs entrants et aucun arc sortant. On peut distinguer deux
types de noeuds finaux :
- 1. Les noeuds finaux d’activité (activity final node) : Dans un nœud final
d’activité, Lorsque l’un de ses arcs entrants est activé, l’exécution de l’activité en
cour s’achève, et tout nœud ou flux actif au sein de cette activité est abandonné.
- 2. Les noeuds finaux de fluxt (flow final node) : L’arrivé du flux d’exécution à
un nœud final de flux, implique la terminaison du flux de ce dernier. Mais cette
fin n’a aucun effet sur les autres flux actifs de l’activité.
B.3. Nœud de fusion (merge node)
Un noeud de fusion est un noeud de contrôle, il rassemble plusieurs flots alternatifs
entrants en un seul flot sortant. L’utilité de ce nœud n’est pas pour synchroniser des flux
concurrents mais pour accepter un flux (en sortie) parmi plusieurs flux entrants.
B.4. Noeud de décision (decision node)
Un noeud de décision est un noeud de contrôle, il permet de faire un choix entre
plusieurs flux sortants. Les flux sortants sont sélectionnés en fonction de la condition de garde
qui est associée à chaque arc sortant. (Possibilité d’existence du problème du choix
indéterministe).
Si aucun arc en sortie n’est franchissable, le modèle est mal formé, et l’utilisation d’une garde
[else] est recommandée.
La notation du nœud de décision est présentée par la figure 1.12.
Chapitre 1: Les diagrammes d’activité d’UML2.0
17
Figure 1.12 : Notation nœud de décision.
B.5. Noeud de bifurcation (fork node)
Un noeud de bifurcation est un noeud de contrôle qui sépare un flux d’entrée en plusieurs
flots concurrents en sortie.
B.6. Noeud d’union (join node)
Un noeud d’union (nœud de jointure) est un noeud de contrôle qui synchronise des flots
multiples. Il possède plusieurs arcs entrants et un seul arc sortant. Ce dernier ne peut être
activé que lorsque tous les arcs entrants sont activés. L’exemple suivant illustre l’utilisation
des nœuds de contrôle.
Chapitre 1: Les diagrammes d’activité d’UML2.0
18
Figure 1.13 : Exemple illustre l’utilisation des nœuds de contrôle.
C. Noeud exécutable (executable node)
Un noeud exécutable est une classe abstraite pour les noeuds d’activité qui peuvent être
exécutés. Il possède un gestionnaire d’exception qui peut capturer les exceptions levées par le
nœud, ou par l’un de ses nœuds imbriqués.
Action :
Une action est un noeud d’activité exécutable, c’est le plus petit traitement qui puisse être
exprimé en UML. L’exécution d’une action peut être une transformation ou un calcul dans le
système modélisé (affectation de valeur à des attributs, création d’un nouvel objet, calcul
arithmétique, émission ou réception d’un signal,…).
Nous citons ci-dessous quelques types d’actions prédéfinis dans la notation UML :
- Action appeler (call operation)
- Action comportement (call behavior)
- Action envoyer (send)
- Action accepter événement (accept event)
- Action accepter appel (accept call)
Chapitre 1: Les diagrammes d’activité d’UML2.0
19
- Action répondre (reply)
- Action créer (create)
- Action détruire (destroy)
- Action lever exception (raise exception)
Une note qui contient des pré ou post-conditions peut être reliée à l’action avec les mots-
clés< localPrecondition > et < localPostcondition >, respectivement.
Figure 1.14 : Exemple d’une action avec des pré-conditions et post-conditions.
1.3.3.1.2. Partitions d’activité (activity partition)
Les partitions d’activité appelées aussi couloirs ou lignes d’eau (swimlane), divisent
l’espace des noeuds et des arcs afin de montrer explicitement l’entité dans quelle les actions
peuvent être effectuées. Cette division permet de faire des regroupements dans les
diagrammes d’activité. Une partition peut être décomposée en sous-partitions et regrouper
d’autres partitions selon une autre dimension.
Les partitions correspondent souvent à des unités organisationnelles dans un modèle de
business, comme le montre l’exemple de la figure suivante.
Chapitre 1: Les diagrammes d’activité d’UML2.0
20
Figure 1.15: Exemple illustratif (partitions d’activités).
1.3.3.1.3. Région interruptible d’activité (interruptible activity region)
Une région interruptible d’activité est un groupe d’activité (regroupement de noeuds et
d’arcs), pouvant contenir un arc jouant le rôle d’interrupteur pour cette région. L’activation de
l’arc interrupteur implique l’arrêt de l’ensemble des flux dans la région.
1.3.3.1.4. Région d’expansion (expansion region)
Une région d’expansion est une région strictement emboitée dans une activité avec des
entrées et des sorties sous forme de noeuds d’expansion. Ces derniers représentent une
collection d’éléments. La région d’expansion est exécutée pour chaque élément de la
collection d’entrée. Dans une région d’expansion, les sorties sont aussi modélisées par des
noeuds d’expansion (Figure 1.16).
Chapitre 1: Les diagrammes d’activité d’UML2.0
21
Figure 1.16 : Région d’expansion.
1.3.3.1.5. Une pré-condition ou post-condition locale (precondition or postcondition)
Une pré-condition est un ensemble facultatif de contraintes, en précisant ce qui doit être
rempli lorsque le comportement est invoqué. Alors qu’une post-condition est un ensemble de
facultatif de contraintes, en précisant ce qui doit être accompli après la fin de l’exécution du
comportement.
1.3.3.1.6. Ensemble de paramètres (parameter set)
Un ensemble de paramètres est définit comme un élément qui fournit des ensembles
alternatifs d’entrées et de sorties nécessaires à un comportement. Chaque ensemble est
exclusif des autres ensembles de paramètres du comportement.
1.3.3.2. Les arcs (edges)
Définition. Arc d’activité (ActivityEdge)
Un arc d’activité est une connexion dirigée entre deux nœuds d’activité. Si l’arc a un
nom, il est noté près de la flèche.
Figure 1.17 : Arc d’activité.
Chapitre 1: Les diagrammes d’activité d’UML2.0
22
1.3.3.2.1. Flux de contrôle (Control Flow)
Un flux de contrôle est un arc qui permet de décrire le séquencement de deux noeuds
d’activité (un flux de contrôle démarre un nœud d’activité, après la terminaison d’une activité
précédente). Il ne transmet pas des données.
Figure 1.18 : Notation flux de contrôle.
1.3.3.2.2. Flux d’objet (Object Flow):
Un arc de flux d’objets est un arc qui permet de transmettre des données entre des nœuds
d’objet.
Figure 1.19 : Notation flux d’objet.
1.3.3.2. 3. Handler d’exception (Exception Handler) :
Un handler d’exception (appelé aussi gestionnaire d’exception) est une activité qui
Chapitre 1: Les diagrammes d’activité d’UML2.0
23
Spécifie un organisme à exécuter. Il possède un pin d’entrée du type de l’exception qu’il gère,
et lié à l’activité protégée par un arc. La figure suivante montre les deux représentations
possibles du gestionnaire d’exception.
Figure 1.20 : Notation d’un handler d’exception.
1.4. Conclusion Dans ce chapitre nous avons présenté brièvement le langage de modélisation unifié
UML, son évolution et ses diagrammes. Ensuite, nous avons donné une description détaillée
des diagrammes d’activité d’UML 2.0 qui constituent un outil de modélisation des systèmes
workflows, des modèles orientés service et des processus métiers. Nous avons insisté sur les
nœuds d’activité et les arcs, qui seront modélisés dans le formalisme source de la
transformation constituant l’objet de notre travail.
Les diagrammes d’activité ont des mécanismes pour éxprimer le séquencement, le choix
et le parallélisme. Mais ils souffrent du manque des outils de vérification de comportement,
qui sont disponible dans un langage comme CSP.
24
Chapitre 2
Le langage CSP « Communicating Sequential Processes »
2.1. Introduction
CSP « Communicating Sequential Processes », est un langage de programmation simple
proposé par Hoare en 1978. Il est conçu pour les machines multiprocesseurs afin de décrire
les calcules parallèles et leurs interactions. Il propose que chaque processus se déroule sur son
propre processeur, et que toutes les communications entre les processus se font par le passage
de message. [Hoare78]
Au début, CSP été une notation formelle utilisée pour discuter les communications des
entités indépendantes, ensuite il a été évolué à un langage formel pour décrire les systèmes
parallèles (simulation des systèmes, raisonnement,…). Il offre un ensemble modeste de
fonctionnalités : variables numériques, symboles et structures de contrôle séquentielles.
Le point fort du CSP est dans son soutien à définir le parallélisme par la définition des
processus et les tampons de communication (buffers).
La notion fondamentale d’une commande gardée a été présentée par CSP, elle serve
comme un modèle puissant pour la régulation et la synchronisation des processus concurrents.
Toutes les installations dans le langage CSP ont été soigneusement choisit afin de permettre
des preuves formelles concernant par exemple, la terminaison des blocages et d’autres
propriétés des modèles CSP. [Haore85]
Dans ce chapitre nous donnons une brève introduction au langage CSP. En s’intéressant
uniquement à certains aspects, comme les opérateurs fondamentaux du langage, qui seront
utilisés dans le cadre de notre étude. Les définitions présentées sont inspirées essentiellement
de [Roscoe97], qui contient une description plus formelle des notions présentées ci-après.
Chapitre 2 : Le langage CSP
25
2.2. Historique
La définition d’un processus comme un modèle décrivant les interactions entre le
système informatique et son environnement, a été introduite en 1978 par C. A. R.
Haore, et le langage proposé, a été un langage de programmation concurrent.
Développement de la théorie présentée precedement, par Haore, Stephen Brookes
et A.W Roscoe.
CSP a été influencé par Robin Milner, qui travail sur CCS « Calculus of
Communicating Systems ».
Présentation de la version théorique du CSP dans un article en 1984, par :
Brookes, Haore et Roscoe.
1985 : Publication de l’article précédent dans le livre de Haore : Communicating
Sequential Processes.
L’introduction d’outils automatisés pour d’analyse et de vérification des
processus CSP.
« The Theory and Practice of Concurrency » de Roscoe en 1997, décrit la
nouvelle version de CSP.
2.3. Communicating Sequential Processes
2.3.1. Définition
CSP est une notation pour décrire les systèmes concurrents (où il existe plus d'un
processus à la fois) dont les processus interagissent les uns avec les autres par la
communication. CSP est une collection de modèles mathématiques et des méthodes de
raisonnement qui nous aident à comprendre et à utiliser cette notation. [Roscoe97]
CSP intègre un mécanisme de synchronisation basé sur le principe du rendez-vous.
Combinant ce mécanisme à une syntaxe simple et concise, CSP permet alors l'implémentation
Chapitre 2 : Le langage CSP
26
rapide des paradigmes classiques de la concurrence, tels que producteurs/consommateurs ou
lecteurs/ rédacteurs.
Les systèmes concurrents sont confrontés à plusieurs difficultés, comme le non
déterminisme, deadlock et livelock. Donc, toute théorie d’analyse des systèmes concurrents
doit être en mesure de les modéliser.
2.3.2. Non déterminisme
Un système présente un non déterminisme si deux copies différentes de celui-ci peuvent
se comporter différemment lorsqu’ils ont exactement les mêmes entrées.
Les systèmes parallèles se comportent souvent de cette manière à cause du conflit de
communication: s'il y a trois sous processus P, Q et R où P et Q sont en concurrence pour être
le premier à communiquer avec R, l'ensemble du système peut tourner dans un sens ou dans
l’autre, d’une manière incontrôlable et non observable de l’extérieur.
2.3.3. Deadlock Un système concurrent est dans deadlock (impasse) si aucun élément ne peut faire aucun
progrès, en général parce que chacun est en attente de communication avec les autres.
L'exemple le plus célèbre est celui des cinq philosophes qui mangent.
2.3.4. Livelock Tous les programmeurs sont familiers avec les programmes qui entrent dans une boucle
infinie, jamais à interagir avec leur environnement de nouveau.
En plus des causes habituelles de ce type de comportement - appelé divergence, où un
programme effectue une séquence infinie et non interrompue d'actions internes- les systèmes
parallèles souffrent de ce problème lorsqu’un réseau communique infiniment à l’intérieur,
sans aucune communication externe. Sur le plan opérationnel un livelock est similaire à une
impasse. En théorie, les deux phénomènes sont très différents.
Chapitre 2 : Le langage CSP
27
2.3.5. Evènement L’événement est l’élément central de l’interaction entre processus, ou entre un processus
et son environnement. Les processus réagissent à des événements et déclenchent d’autres en
réaction. Un évènement peut être appelé « action ».
2.3.6. Processus
Les processus sont des entités indépendantes les unes des autres, qui peuvent
communiquer entre elles et exécutent des évènements. L’ensemble des évènements qu’un
processus peut exécuter est appelé son alphabet.
On peut distinguer deux processus très importants :
STOP : C’est le processus qui ne fait rien, il désigne le comportement le plus simple d’un
processus, et signifie une impasse.
SKIP : Ce processus signifie une terminaison avec succès.
2.4. Communication et Synchronisation
En 1978, il avait de nombreuses méthodes de communication et de synchronisation
proposées dans le cadre de la programmation multiprocesseur. La mémoire partagée été le
mécanisme de communication le plus courant. Les sémaphores, les régions critiques, et les
moniteurs ont été parmi les mécanismes de synchronisation.
C.A.R. Hoare a abordé les deux problèmes de Communication et de Synchronisation
avec une seule primitive du langage: la communication synchrone.
Dans le langage CSP de Hoare, les processus communiquent par l’envoi ou la réception
des valeurs à partir des canaux nommés sans tampon. Comme les canaux sont sans tampon,
l'opération d’envoi est bloquée jusqu'à ce que la valeur a été transférée à un récepteur,
fournissant ainsi un mécanisme de synchronisation.
Donc, le langage CSP s’appuie sur les trois principes suivants :
1. Chaque processus s’exécute sur son propre processeur.
2. toutes les communications entre les processus concurrents sont réalisées par le
passage de message.
Chapitre 2 : Le langage CSP
28
3. CSP s’appuie sur le mécanisme le plus primitif de passage de message :
1. Envoies et réceptions de messages non-tamponnés :
a. Quand un processus émet un send (), l'appel système ne se termine
Jusqu’à ce que le message est reçu par un autre processus, appelé aussi
« blocking send ».
b. Quand un processus émet un reçu (), l’appel système ne se termine
Jusqu’à ce que le message est reçu par le processus, appelé aussi
«blocking receive".
2. Désignation explicite des processus source et destination : a. Un processus qui émet un send (), spécifie le nom du
processus auquel le message est envoyé.
b. Un processus qui émet un reçu (), précise le nom du processus à
partir duquel il s'attend un message.
2.5. Opérateurs fondamentaux 2.5.1. Alphabet
L'ensemble des noms d'événements qui sont considérés comme pertinents pour une description
particulière d'un objet, est appelé son alphabet.
L'alphabet est une propriété permanente prédéfinie d'un objet. Il est logiquement impossible
pour un objet de s'engager dans un événement qui est hors son alphabet. Par exemple, une machine
conçue pour vendre des chocolats ne pouvait pas offrir des jouets.
2.5.2. Notation préfixe
Soit x un événement et soit P un processus. (X → P), (prononcé X ensuite P) décrit un objet qui
exécute en premier cas X, puis se comporte exactement comme P. Le processus (X → P) est défini
pour avoir le même alphabet que P. (X est dans cet alphabet).
Plus formellement, alpha (X → P) = alpha (P), fournit : X appartient à alpha (p).
Associativité à droite
Dans ce cas, les parenthèses sont implicites et portent sur les processus à droite
de la flèche. Si a et b sont deux évènements, et P est un processus :
a → b → P correspond à : a → (b → P)
Chapitre 2 : Le langage CSP
29
2.5.3. Récursivité
La notation du préfixe peut être utilisé pour décrire le comportement d'un processus qui
termine par un arrêt. Mais il serait extrêmement fastidieux d'écrire tout le comportement d'un
distributeur automatique pour sa durée de vie maximale, de sorte que nous avons besoin d'une
méthode de description des comportements répétitifs (une notation beaucoup plus courte). En
CSP La récursivité permet de décrire les processus qui agissent sans fin.
Example:
Soit P1 un processus qui exécute up et down indéfiniment. Nous pouvons utiliser la
récursivité pour définir ce processus.
P1 = up → down → P1
La figure 2.1 représente le comportement du processus P1.
Figure 2.1 : Comportement du processus P1.
2.5.4. Opérateurs de choix
En CSP, on peut distinguer essentiellement les opérateurs de choix suivants :
Soient a, b, z des évènements, P, Q, R des processus.
A. Le choix le plus simple
Ce choix est dénoté par |, il agit sur les processus de la forme a → P.
Chapitre 2 : Le langage CSP
30
Le processus : a → P | b → Q peut soit exécuter l’évènement a et se comporte ensuite
comme le processus P, soit exécuter l’évènement b et se comporte ensuite comme le
processus Q.
L’opérateur | peut être utilisé avec plus de deux choix : a → P | b → Q | ... | z → R
Exemple
La figure 2.2 représente le comportement des processus suivants :
UandD = (up → down → STOP | down → up → STOP)
P = (a → P | b → Q)
Q = (a → P |b → STOP)
Figure 2.2 : Comportements des deux processus avec le choix.
B. Le choix externe ou déterministe ( )
Dans ce type de choix c’est l’environnement qui choisit le comportement du processus.
Si nous avons le processus : a → P b → Q et que l’environnement s’engage dans
l’événement b, alors le processus s’engagera dans cet événement et se comportera comme le
processus Q. Ce choix est utilisé entre des événements observés.
C. Le choix interne ou non déterministe
Ce choix est noté par Π. c’est le processus qui choisit de façon non déterministe le
comportement à choisir parmi plusieurs.
Chapitre 2 : Le langage CSP
31
Le processus : a → P Π b → Q va choisir entre initialiser l’événement a et continuer comme P
ou initialiser l’événement b et continuer comme Q. Ce choix est utilisé entre des événements
initialisés. D. Le choix conditionnel
Le choix conditionnel se base sur la valeur d’une expression booléenne. Il peut être
présenté par : if ... then ... else ...
Ou en utilisant l’opérateur algébrique P</ b /> Q qui donne exactement la même signification
que : si b alors P autre Q
Le comportement conditionnel peut être met en évidence par les deux lois suivants : 1. P</ true /> Q = P.
2. P</ false /> Q = Q.
2.5.5. Evènements cachés (hiding)
Il est possible à partir d’un processus P de cacher certains évènements de son alphabet. Si
A est un ensemble d’évènements, et si P est un processus, alors :
P \ A est le processus dont les évènements appartenant à A deviennent des évènements
internes du processus.
2.5.6. Composition parallèle [GRAIET07]
La composition parallèle permet de décrire plusieurs processus en concurrence, CSP
introduit l’opérateur de composition parallèle entre processus. P || Q est la composition
parallèle de P et de Q. Dans ce cas, tous les événements de P et Q sont exécutés en
synchronisation.
2.5.7. Entrelacement
Cet opérateur dénoté par (|||) est similaire à l’opérateur de composition parallèle, mais
sans synchronisation. On note : P ||| Q l’entrelacement des processus P et Q. Les événements
de P sont alors exécutés indépendamment de l’exécution des événements de Q. Par exemple,
si P et Q sont définis par :
P = a → b → P’ Q = c → Q’
Chapitre 2 : Le langage CSP
32
Les séquences d’événements possibles pour P ||| Q sont : (a, b, c), (a, c, b) et (c, a, b).
Ces séquences sont appelées les traces du processus P ||| Q.
2.5.8. Entrées et sorties
En CSP, Un événement peut être représenté par un message passant par un canal. Les
événements sont de la forme c.m, où c est le nom d’un canal et m est la valeur du message
passant par le canal c.
Les valeurs des messages peuvent être exprimées en CSP en termes d’entrées ou de
sorties des canaux dans les processus avec préfixe.
1. Le processus : c!x → P : est un processus dont la valeur x est une sortie du canal c et
qui se comporte ensuite comme le processus P.
2. Le processus : c?x → P est un processus dont le paramètre x est entrée du canal c et qui
se comporte ensuite comme le processus P.
2.6. Syntaxe du CSP La notation de quelques processus CSP est la suivante:
α P l’alphabet du process P.
αc l’ensemble des messages pouvant être communiqués sur le
canal c.
a → P a ensuite P.
(a → P | b → Q) a ensuite P choix b ensuite Q (il est donné a ǂ b).
P <| b |> Q si b alors P sinon Q.
P || Q P parallele à Q.
P Π Q P ou Q (non-deterministe).
P Q P choix Q.
P \ C P sans C (hiding)
P ||| Q l’entrelacement des processus P et Q.
Chapitre 2 : Le langage CSP
33
P; Q P (succès) suivi par Q.
P Δ Q P est interrompu par Q.
La syntaxe du CSP défini la façon dont les processus et les évènements peuvent être
combinés. Soit P, E, et F des processus, et e un évènement. L’équation suivante définit la
syntaxe de base du CSP :
2.7. Trace
Une trace peut être défini par la séquence des communications entre l'environnement et
le processus.
En général, une trace peut-être fini ou infini: finie, soit parce que l'observation a été
arrêtée, ou parce que le processus et l’environnement atteignent un point où ils ne peuvent
plus être d’accord sur n’importe quel évènement. Infini lorsque l'observation va à l'infini et
plusieurs événements sont traitées infiniment.
2.8. Echecs
Les échecs d’un processus sont une paire de traces et de refus.
L’ensemble des traces possibles d’un processus P est noté traces (P).
Un refus correspond à un ensemble d’événements proposés pour lequel le processus
refuse de s’engager. Cet ensemble d’événements refusés par un processus P est noté refus (P).
2.9. Divergences
Une divergence d’un processus est définie comme une de ses traces quelconque après
laquelle il y a un comportement chaotique. Ce comportement chaotique est représenté par le
processus suivant :
CHAOSA = STOP Π ( x : A • x → CHAOSA)
Ce processus peut se comporter comme n’importe quel autre. C’est le plus non déterministe,
le plus imprévisible, le plus incontrôlable de tous. La divergence est donc utilisée pour
représenter des situations catastrophiques ou des programmes complètement imprédictibles,
comme des boucles infinies.
P := E | e → E | E || F | E|||F | E Π F | E \ F | E F | E <| e |> F | P; Q | P Δ Q |SKIP| STOP
Chapitre 2 : Le langage CSP
34
2.10. Approches sémantiques Trois façons distinctes sont indispensables pour arriver à une compréhension
mathématique de la signification d’un programme CSP. Il s'agit d’une sémantique
opérationnelle, dénotationnelle et algébrique.
2.10.1. La sémantique opérationnelle
Elle interprète les programmes sous forme de diagrammes de transition, avec des
actions visibles et invisibles pour le déplacement entre les différents états du programme.
Elle est souvent utilisée pour décrire le comportement des processus (et les opérateurs) de
manière informelle. La sémantique opérationnelle, comme son nom l'indique, est
relativement proche de l’implémentation, une sémantique opérationnelle peut être défini
comme une formalisation mathématique de certaines stratégies d’implémentation.
2.10.2. La sémantique dénotationnelle
Une sémantique dénotationnelle transforme un langage en un certain modèle abstrait, de
manière que la valeur (dans le modèle) d'un programme composé, est directement déterminée
à partir des valeurs de ses parties. Généralement, la sémantique dénotationnelle tente de
s’éloigner de toute stratégie spécifique d’implémentation. La description du langage dans un
niveau, est destiner à capturer le sens intérieur du programme. Il existe plusieurs sémantiques
dénotationnelles dans CSP, toutes basées sur des concepts comme les traces, les échecs et les
divergences. La valeur de tout programme est une combinaison de ses ensembles de ces
concepts.
2.10.3. La sémantique algébrique Une sémantique algébrique est définie par un ensemble de lois algébriques comme ceux
cités pour les différents opérateurs (paragraphe 2.6). Au lieu d’utiliser des théorèmes dérivés
(comme dans une sémantique dénotationnelle), les lois sont les axiomes de base d'une
sémantique algébrique, et l’équivalence du processus est défini en termes des égalités
pouvant être prouvées par leur utilisation. La sémantique algébrique peut être considérée
comme le type de sémantiques le plus abstrait (abstrait dans le sens informel).
Chapitre 2 : Le langage CSP
35
2.11. Points forts du CSP
CSP constitue un excellent moyen de description et de raisonnement sur les modèles de
communication complexes, pour les raisons suivantes : [Martin97]
Il résume les principes fondamentaux de la communication d'une
manière simple et élégante.
Sémantiquement, il est défini en terme d'un modèle mathématique
structuré, pouvant être utilisé pour déduire les propriétés du système
rigoureusement.
Il est suffisamment expressif pour permettre de raisonner sur les
problèmes pathologiques de deadlock et livelock.
Les principes d’abstraction et de raffinement sont au cœur du CSP.
Des outils robustes de génie logiciel sont disponibles pour la
vérification formelle du CSP.
Certains langages de programmation traditionnels, comme Occam et
Ada, sont directement dérivés du modèle CSP. Des bibliothèques de
communication CSP-style sont disponibles pour d'autres langages,
telles que Java.
2.12. Outils
Au cours des dernières années, il y a un grand intérêt pour le développement des outils
de preuve automatique pour les CSP et les langages similaires.
A l'heure actuelle, l’outil d'analyse et de preuve le plus puissant pour les CSP est appelé
FDR [FDR] (Failures/Divergences/Refinement), qui a conduit à une révolution dans la façon
d’utilisation des CSP. Ainsi que son influence sur la manière de modélisation mathématique
des CSP et la présentation de ses modèles.
Nous citons ProBE [ProBE], qui est un animateur pour les processus CSP permettant à
l’utilisateur d’explorer le comportement des modèles de manière interactive, Deadlock
Checker [Deadlock], et Casper [Casper].
Chapitre 2 : Le langage CSP
36
Plusieurs autres formalismes de spécifications ont été dérivés à partir du CSP, nous citons
par exemple : CSP synchronisé, CSPP, HCSP, TCOZ, CspCASL,…
2.13. Conclusion
Dans ce chapitre nous avons présenté d’une manière simple et informelle, les concepts
de base du langage CSP. Nous avons donné une description pour : le principe de
communication et de synchronisation, les processus, les évènements, les opérateurs (préfixe,
choix, parallélisme, hiding, entrelacement,…), les traces, l’échec, les divergences. Ensuite
nous avons présenté les trois approches sémantiques du CSP, ses points forts, ainsi qu’une
citation de quelques outils automatiques de preuve et formalismes de spécification.
Dans le chapitre suivant, nous allons présenter la transformation des modèles pouvant être
utilisé pour transformer des modèles crées dans des formalismes informels ou semi-formels,
vers des spécifications formelles afin de profiter des avantages de ces derniers.
37
Chapitre 3
Transformation de graphes et ATOM³ 3.1. Introduction
L’Ingénierie Dirigée par les Modèles (IDM), ou Model Driven Engineering (MDE) est
une discipline récente du génie logiciel qui met l’accent sur les modèles au sein du processus
de développement logiciel. L’IDM est donc le domaine de l’informatique mettant à
disposition des outils, concepts et langages pour créer et transformer des modèles. [WIKI]
La transformation des modèles est une tâche complexe qui nécessite la disposition
d’outils flexibles permettant la gestion des modèles et des langages durant la transformation et
la manipulation des modèles. La sémantique de ces derniers doit être spécifiée, et les langages
utilisés doivent être décrit de manière précise. [IDM09]
L’OMG a proposé une variante particulière de l’IDM, c’est l’architecture dirigée par les
modèles (MDA : Model Driven Architecture) qui est une approche complète de
développement du logiciel basée sur le développement des modèles. MDA a pour objectif de
résoudre les problèmes d’interopérabilité et de portabilité dès le niveau modélisation, elle essaye
d’offrir une solution au problème de l’émergence continu des technologies logiciel par la
séparation entre les spécifications fonctionnelles et les spécifications d’implémentation sur
une plate-forme donnée. Pour cela, MDA propose trois classes de modèles : Computational
Independent Models (CIM), Platform Independent Models (PIM) et Platform Specific Models
(PSM).
Dans ce chapitre, nous donnons un rappel sur la transformation de modèle et la méta-
modélisation. La transformation de graphe est présentée comme outil de transformation de
modèles, et ATOM³ comme outil de transformation de graphe.
Chapitre 3 : Transformation de graphes et ATOM3
38
3.2. L’architecture dirigée par les modèles (MDA) L’architecture dirigée par les modèles ou Model Driven Architecture est une démarche
de réalisation de logiciel, proposée et soutenue par l'OMG. [WIKI]
L’idée de base de cette approche est de définir des modèles métiers indépendants de
l'informatisation (Computation Independent Model, CIM), on transforme ces CIM pour
obtenir des modèles totalement indépendants des plates-formes techniques (Platform
Independent Model, PIM), par la suite, on raffine ces PIM pour prendre en considération les
problèmes liés à la technologie retenue et on obtient des modèles spécifique à la plate-forme
cible (Platform Specific Model, PSM).
La figure suivante représente les différentes couches de spécification de la démarche
MDA.
Figure 3.1: Model Driven Architecture (OMG).
Le noyau de l’architecture est basé sur les techniques (UML, MOF, CWM), autour
quelques-unes des plates-formes supportées (JAVA, WEB, CORBA, …), en surface on
trouve les services systèmes et enfin les domaines pour lesquels des composants métiers
doivent être définis (Domain Facilities), parmi ces domaines on peut citer : E-Commerce,
Finance, Télécommunication,… [MDA02]
3.2.1. Notion de modèle
La modélisation est le processus de spécification du modèle, elle consiste à représenter
le système sous forme de modèles en utilisant des concepts prédéfinis dans un langage de
modélisation.
Chapitre 3 : Transformation de graphes et ATOM3
39
Un modèle est une abstraction de la réalité, il met l’accent sur certains aspects du
système et ignore d’autres (c’est une représentation simplifiée). Son but est de permettre une
étude plus simple dans un contexte maîtrisé autre que le contexte réel. [WIKI]
Au niveau du MDA les modèles manipulés sont de natures diverses : modèles d’objets
métiers, de processus, de service, de plate-forme, de transformation et de tests. On peut
distinguer trois classes de modèles :
a- d’exigence (Computation Independent Model : CIM) dans lesquels aucune
considération informatique n’apparaît.
b- d’analyse et de conception (Platform Independent Model : PIM),
c- de code (Platform Specific Model : PSM).
3.2.2. Transformation de modèles
Les transformations de modèles sont appliquées séquentiellement sur les modèles jusqu’à la
génération du code. La figure suivante donne un aperçu global sur le processus de
transformation de modèles de l’approche MDA.
Figure 3.2 : Processus de transformations de modèles de l’approche MDA.
Chapitre 3 : Transformation de graphes et ATOM3
40
3.2.3. Méta-Modélisation et transformation
Le MDA se résume à la pyramide suivante avec 4 niveaux d’abstraction.
Figure 3.3 : Pyramide de modélisation de l’OMG.
M0 : niveau de modélisation des données réelles, il est composé des informations que l’on
souhaite modéliser. Il est représenté à la base de la pyramide.
M1 : Ce niveau est composé de modèles d’informations (PIM, PSM). La définition de ces
modèles est fournie explicitement au niveau M2.
M2 : Il est composé de langages de définition des modèles d’informations (les méta-
modèles).
M3 : Composé d’un langage unique de définition des méta-modèles (Méta-metamodèle ou
MOF), il est représenté au sommet de la pyramide.
Remarque : Entant que modèle, le MOF (Meta Object Facility) doit être défini à partir d’un
langage de modélisation. Afin de limiter le nombre de niveaux d’abstraction, il doit avoir
la capacité de se décrire lui-même (propriété de métacircularité).
Dans une approche IDM, la transformation a pour objectif de rendre les modèles
opérationnels, c’est une opération très importante dans toute approche orientée modèle. En
effet, l’intérêt des transformations est d’assurer les opérations de passage d’un ou plusieurs
modèles (dans un niveau d’abstraction donné) vers un ou plusieurs autres modèles du même
Chapitre 3 : Transformation de graphes et ATOM3
41
niveau (transformation horizontale) ou d’un niveau différent (transformation verticale). Le
modèle transformé est appelé modèle source et le modèle résultant de la transformation est
appelé modèle cible. Si les deux méta-modèles (source et cible) correspondant respectivement
aux modèles (source et cible) sont identiques, on parle d’une transformation endogène, dans
le cas contraire (méta-modèles différents) la transformation est exogène. [IDM09] Le tableau
suivant résume les types de transformation et leurs principales utilisations. [Combemale08]
Figure 3.4 : Types de transformation et leurs principales utilisations.
Les principales propriétés qui caractérisent les transformations de modèles sont : la
réversibilité, la traçabilité, la réutilisabilité, l’ordonnancement et la modularité.
3.2.4 Classification des approches de transformation Les approches de transformation de modèle ont été classées selon plusieurs axes. Chaque
axe mène à une classification particulière. La classification des approches de transformation
proposée par Czarnecki et Helsen [Czarnecki03] se base sur les techniques de transformation
utilisées dans les approches et les facettes qui les caractérisent. Selon cette classification on
peut distinguer deux types de transformation de modèles: les transformations de type modèle
vers code et les transformations de type modèle vers modèles. Généralement, le premier type
de transformation peut être vu comme un cas particulier du deuxième type, nous avons
seulement besoin de fournir un méta-modèle pour le langage de programmation cible.
Cependant, pour des raisons pratiques de réutilisation de la technologie des compilateurs
existants, souvent, le code est simplement généré en tant que texte, qui est ensuite introduit
Chapitre 3 : Transformation de graphes et ATOM3
42
dans un compilateur. Pour cette raison, nous distinguons entre la transformation de type
modèle vers code et la transformation de type modèle vers modèle.
3.2.4.1. Transformations de type Modèle vers code
Dans cette catégorie, on distingue entre les approches basées sur le principe du visiteur
(Visitor-based approach) et celles basées sur le principe des patrons (Template-based
approach).
a- Approche basée sur le visiteur (Visitor-based): approche de base pour la génération
de code, elle consiste à fournir un mécanisme de visiteur pour traverser la
représentation interne d’un modèle et créer le code. On peut citer comme exemple
le framework Jamda qui fournit un ensemble de classes pour représenter les
modèles UML, une API pour manipuler les modèles, et un mécanisme de visiteur
pour générer le code.
b- Approche basée sur les templates (Template-based) : Actuellement, la majorité des
outils MDA disponibles supportent cette approche. La structure d’un template
ressemble au code à générer, dans un template il n’y a pas de séparation
syntaxique entre le LHS et le RHS. le LHS utilise une logique exécutable pour
accéder au modèle source, le RHS combine des patrons non typés et une logique
exécutable (la logique : code ou requêtes déclaratives). Parmi les outils basés sur ce
principe, on peut citer : JET, Codagen Architect , ArcStyler, AndroMDA, OptimalJ et
XDE (les deux derniers outils fournissent aussi la transformation modèle vers
modèle).
3.2.4.2 Transformations de type modèle vers modèle
Les transformations de type modèle vers modèle consistent à transformer un modèle
source en un modèle cible, ces modèles peuvent être des instances de différents méta-
modèles. Elles offrent des transformations plus modulaires et faciles à maintenir. Dans les
cas où on trouve un grand espace d’abstraction entre PIMs et PSMs, il est plus facile de
générer des modèles intermédiaires qu’aller directement vers le PSM cible. Les modèles
intermédiaires peuvent être utiles pour l’optimisation ou bien pour des fins de déboguage. De
Chapitre 3 : Transformation de graphes et ATOM3
43
plus, les transformations de type modèle vers modèle sont utiles pour le calcul des différentes
vues du système et leurs synchronisation.
a. Approches de manipulation directe
Ces approches offrent une représentation interne des modèles source et cible, et un
ensemble d’APIs pour les manipuler. Elles sont généralement implémentées comme un cadre
structurant orienté objet qui peut également fournir un ensemble minimal de concepts pour
organiser les transformations (exemple : classe abstraite). Cependant, l’utilisateur doit
implémenter et ordonnancer les règles de transformation. JMI (Java Metadata Interface) peut
être cité comme exemple de ces approches.
b. Approches relationnelles
Cette catégorie regroupe les approches déclaratives et utilise les relations
mathématiques. L’idée de base est de spécifier les relations entre les éléments des modèles
source et cible par des contraintes, ces derniers peuvent avoir une sémantique exécutable
comme dans la programmation logique. Cependant, les relations ne sont pas exécutables mais
peuvent être lues dans les deux sens (exemple : QVTP).
c. Approches basées sur les transformations de graphes
Ces approches sont déclaratives, elles se basent sur la théorie des transformations de
graphe. Les règles de transformation sont définies pour des fragments de modèles, ces
fragments peuvent être exprimés dans les syntaxes concrètes des modèles sources et cibles
respectivement, comme dans VIATRA, ou bien dans leur syntaxe abstraite comme dans
BOTL. Chaque règle est composée d’un graphe source (LHS : Left Hand Side) et d’un
graphe cible (RHS : Right Hand Side). La transformation consiste à conserver les entités
filtrées (LHS) et ajouter des nouvelles entités conformément à la règle (RHS). Parmi les
approches basées sur les transformations de graphes on peut citer : AGG, MTrans, Great et
ATOM³.
d. Approches dirigées par la structure
Les approches de cette catégorie distinguent deux phases : la première consiste à créer
la structure hiérarchique du modèle cible, la seconde définit les attributs et les références dans
Chapitre 3 : Transformation de graphes et ATOM3
44
la cible. L’environnement définit l’enchaînement des règles, et l’utilisateur ne fourni que les
règles de transformation. OptimalJ est un exemple de ces approches.
e. Approches hybrides
Les approches hybrides combinent les différentes techniques des catégories
précédentes. On peut citer comme exemple :
- TRL : composition d’approche déclarative et impérative.
- Atlas : une règle peut être entièrement déclarative, impérative ou hybride
f. Autres approches
Pour accomplir, deux approches doivent être mentionnées : CWM et XSLT.
- CWM : fournit un mécanisme permettant de relier les éléments source et cible, mais la
dérivation des éléments cibles doit être implémentée dans un langage concret qui n’est
pas prescrit par CWM.
- XSLT : technologie standard pour transformer XML.
3.3. Transformation de graphes
Dans cette partie, nous allons présenter quelques notions sur les graphes, ensuite nous
allons décrire avec détaille les transformations et les grammaires de graphes.
3.3.1. Graphes et digraphes
Définition1. (Graphes)
Un graphe est un ensemble de sommets ou nœuds (vertices) connectés par des liens
appelés arêtes (edges). Plus formellement, un graphe G est le couple G = (V, E) où V est un
ensemble de sommets et E est un sous-ensemble de V × V représentant les arêtes.
Si le couple (v1, v2) appartient à E, on dit que les deux sommets v1 et v2 sont adjacents.
Si v1 et v2 sont identiques, le sommet est dit réflexif et l’arête est appelée boucle.
L’ordre d’un graphe est le nombre de ses sommets et le degré d’un sommet est le nombre de
ses voisins.
Un graphe sans boucle et ne possédant pas d'arêtes parallèles (deux arêtes distinctes joignant
la même paire de sommets) est dit simple, sinon on parle de multigraphe.
Les graphes ainsi définis sont dits "graphes non orientés". [Joyner10]
Chapitre 3 : Transformation de graphes et ATOM3
45
Figure 3.5 : Graphe non orienté.
Le graphe de la figure3.5 est d’ordre 5, et le degré du sommet e est 2.
Un sous-graphe est un graphe contenu dans un autre graphe. Si H = (VH, EH) est un sous-
graphe de G = (VG, EG), alors : et .
Figure 3.6 : (a) graphe G (b) sous-graphe de G.
Définition2. (Digraphes)
On appelle graphe orienté ou digraphe un graphe pour lequel les arêtes sont orientées
(arcs).
Un arc a = (x, y) peut être noté simplement xy, on dit que x est l'origine ou l’extrémité
initiale et y est l'extrémité terminale de a.
Figure 3.7 : Graphe orienté.
Chapitre 3 : Transformation de graphes et ATOM3
46
Un graphe étiqueté est un graphe orienté auquel on a associé à chacun des arcs un ensemble
non vide d’étiquettes.
Figure 3.8 : Graphe étiqueté. [Sorlin03]
Lorsque toutes les étiquettes sont des nombres positifs, le graphe est dit pondéré.
Un graphe attribué est un graphe qui peut contenir un ensemble prédéfini d’attributs.
Un graphe complet est un graphe simple dont tous les sommets sont adjacents les uns avec
les autres.
Figure 3.9 : Graphe complet.
3.3.2. Grammaires de graphes L’idée derrière ce domaine est de combiner deux concepts importants: les graphes et les
règles. Bien que les graphes sont adéquats pour la représentation statique des structures
d’information complexes (comme les diagrammes et les réseaux), l’application des règles
décrit le comportement dynamique de ces structures par le biais d’éventuelles modifications
Chapitre 3 : Transformation de graphes et ATOM3
47
locales. De cette façon, les grammaires de graphe et les systèmes de transformation de
graphes fournissent des méthodes formelles pour modéliser la syntaxe et la sémantique des
systèmes de traitement d’information et d’analyser leur comportement. [Ehrig99a] En outre,
les règles de transformation de graphes sont spécifiées de manière facile et intuitive, et la
complexité des formalismes d’application peut être cachée de l’utilisateur.
Plusieurs approches et outils ont été développés dans ce domaine, on peut citer par
exemple les travaux de [M-Schettini96] [Karsai03] [Radermacher00] [Agrawal03].
La transformation de graphe [Rozenberg97] est le mécanisme de spécifier et appliquer
les transformations entre les graphes. L’idée principales derrière cette transformation est la
modification des graphes basée règle comme le montre la figure 3.10.
Figure 3.10 : Modification de graphes basée règle.
Les grammaires de graphes sont une généralisation, pour les graphes, des grammaires de
chomsky. Elles sont composées de règles ou productions : P = (L, R) dont chacune est une
paire de graphes (L, R). L est un graphe de coté gauche (LHS : Left Hand Side) et R est un
graphe de coté droit (RHS : Right Hand Side). Chaque application de la règle consiste à
transformer un graphe initial par le remplacement d’une de ses parties par un autre graphe. Le
problème principal de ce remplacement est de savoir comment relier R avec le contexte du
graphe cible. Pour pallier à ce problème, plusieurs approches de transformation de graphes
ont été proposées.
Exemple d’une règle R= (LHS, RHS)
Cette règle permet de séparer la Place attachée au lien AND lors de la transformation
des processus métiers vers les réseaux de Petri. [Elmansouri08a]
Chapitre 3 : Transformation de graphes et ATOM3
48
Figure 3.11: (a) LHS de la règle (b) RHS de la règle.
Définition 1 (Système de transformation de graphe)
Un système de transformation de graphe est une structure GTS, composée d’un graphe
initial S, et d’un ensemble de règles de transformation de graphe R= {r1, r2,…, rn}.
Définition 2. (Grammaire de Graphe)
Une grammaire de graphe est une structure GG, composée d’un graphe initial S, d’un
ensemble de règles de transformation de graphe R= {r1, r2,…, rn}, et d’un ensemble de
symboles terminaux T. [Andries99]
Définition 3. (Transformations de modèle basées sur la transformation de graphe)
Soit R un ensemble de règles. Une séquence de transformation de modèle
(GS, GS GT ,GT ) est composée d’un graphe source GS, d’un graphe cible GT, et d’une
dérivation de GS vert GT en appliquant l’ensemble des règles R.
Définition 4. (Langage engendré)
Soit S un graphe initial, le langage engendré L(P,S,T) est l’ensemble des graphes dérivés
à partir de S en appliquant les règles de P qui sont étiquetées par les symboles de T .
Définition 5. (Application des règles)
Soit r une règle de transformation de graphe définie par : r = (L, R, K, glue, emb, cond)
- L : graphe de côté gauche.
- R : graphe de côté droit.
- K : un sous graphe de L.
- glue : une occurrence de K dans R qui relie le sous graphe avec le graphe de coté droit.
Chapitre 3 : Transformation de graphes et ATOM3
49
- emb : une relation d’enfoncement qui relie les sommets du graphe de coté gauche et
ceux du graphe du coté droit.
- cond : un ensemble qui spécifie les conditions d’application de la règle.
L’application d’une règle r= (L, R, K, glue, emb, cond) à un graphe G produit un graphe
résultant H. Ce dernier peut être obtenu depuis le graphe d’origine G en passant par les
étapes suivantes :
1. Choisir une occurrence du graphe de coté gauche L dans G.
2. Vérifier les conditions d’application d’après cond.
3. Retirer l’occurrence de L (jusqu’à K) de G ainsi que les arcs pendillé, c-à-d tout les arcs qui
ont perdu leurs sources et/ou leurs destinations. Ce qui fourni le graphe de contexte D de L
qui a laissé une occurrence de K.
4. Coller le graphe de contexte D et le graphe de coté droit R suivant l’occurrence de K dans
D et dans R. c’est la construction de l’union de disjonction de D et R et, pour chaque point
dans K, identifier le point correspondant dans D avec le point correspondant dans R.
5. Enfoncer le graphe du côté droit dans le graphe de contexte de L suivant la relation
d’enfoncement emb.
L’application de r sur un graphe G pour fournir un graphe H est appelée une dérivation
directe depuis G vers H à travers r, elle est dénotée par G � H. [Elmansouri09]
3. 3.3. Approches de transformation de graphes
Une description plus détaillée sur les approches de transformation de graphes et des
grammaires de graphes est présentée dans [Rozenberg97].
a. L’approche « node label replacement »
Approche principalement développée par Rozenberg, Engelfriet et Janssens. L : est un seul
nœud, l’approche « node label replacement »permet de remplacer L par un graphe R arbitraire.
b. L’approche « hyperedge replacement »
Approche développée par Habel, Kreowski and Drewes. L : est un hyperarc étiqueté, cette
approche consiste à remplacer L par un hypergraphe arbitraire R avec les nœuds d’attachement
désignés correspondant aux nœuds de L.
Chapitre 3 : Transformation de graphes et ATOM3
50
d. L’approche algébrique
L’idée d’utiliser les catégories pour enrichir les grammaires de graphes a été introduite
par H. Ehrig, M. Pfender et H.J. Schneider. L’approche algébrique est basée sur des
constructions catégoriques appelés « pushout ». Ces derniers ont pour objectif de pouvoir
décrire de manière algébrique des règles de transformation complexes ainsi que le processus
de transformation. On distingue deux variantes principales de l’approche algébrique : «Single
Pushout» et «Double Pushout» qui est développée par Ehrig, Schneider et Berlin- and Pisa-
groups. [Boisvert10] contient une étude comparative des deux variantes.
e. L’approche logique
Approche développée par Courcelle et Bouderon. Elle permet d’exprimer la
transformation de graphe et les propriétés de graphe dans la logique monadique du second
ordre.
f. La théorie de 2-structures
Cette approche a été initiée par Rozenberg et Ehrenfeucht comme un cadrepour la
décomposition et la transformation de graphes.
g. L’approche «programmed graph replacement»
Approche développée par Schürr, elle consiste à utiliser des programmes afin de contrôler
le choix non déterministe des applications des règles. [Ehrig06]
3.3.4. Outils de transformation de graphes
Plusieurs outils ont été développés pour faire de manière efficace des transformations de
modèles à l’aide des transformations de graphes, parmi ces outils on peut par exemple citer :
- AGG [AGG]: The Attributed Graph Grammar System.
- FUJABA [Fujaba] : From UML to Java and back again.
- ATOM3 [Atom3]: A Tool for Multi-formalism and Meta-Modelling.
- VIATRA [Viatra]: VIsual Automated model TRAnsformations.
- GreAT [Great]: The Graph Rewrite And Transformation tool suite.
- booggie [booggie] : brings object-oriented graph grammars into engineering.
- Et d’autre outils comme: DiaGen, GenGED, PROGRES, GrGen.NET [Blomer10],
MoTMoT, GROOVE, etc.
Chapitre 3 : Transformation de graphes et ATOM3
51
Dans le cadre de ce mémoire, nous avons choisi l’outil ATOM3 pour développer notre
grammaire de graphe. Ce choix est justifié par les nombreux avantages présentés par cet outil.
Parmi lesquels on peut citer : la disponibilité, la simplicité et la possibilité de méta-modéliser
et de transformer les modèles.
3.3.5. AToM³
AToM³ est un outil visuel de modélisation et de méta-modélisation multi-formalismes
[DeLara02a]. Il est développé au laboratoire MSDL (Modeling, Simulation and Design Lab) à
l’école d’informatique de l’université de McGill.
AToM³ repose sur la réécriture de graphes qui utilise les règles de grammaire de graphes
pour la définition des transformations entre les formalismes, ainsi que la génération du code
et la spécification des simulateurs. L’utilisateur doit défini les règles (elles sont modélisées
comme des entités composées de : LHS et RHS), les priorités et les conditions qui doivent
être vérifiées pour que la règle soit applicable (pré-condition, post-condition, sur quel
évènement).
Figure 3.12 : Exemple d’édition d’une contrainte en AToM³.
L’utilisateur peut également créer une nouvelle grammaire, charger une grammaire
prédéfinie (pour modification, consultation ou exécution) ou enregistrer une autre après une
modification. La figure 3.13 présente l’interface d’édition d’une grammaire de graphe.
Chapitre 3 : Transformation de graphes et ATOM3
52
Figure 3.13: Edition d’une grammaire de graphe en AToM³
AToM³ supporte la modélisation des systèmes complexes, qui sont caractérisés par la
multiplicité et la diversité de ses composants. L’analyse et la conception d’un tel système
nécessitent l’évaluation de ses propriétés dans l’ensemble du système multi-formalisme.
AToM³ permet de modéliser les différentes parties du système en utilisant les différents
formalismes, et les modèles peuvent être automatiquement convertis entre ces formalismes.
AToM³ est implémenté en python [Python]. Sa composante principale est le « Kernel»,
c’est le module responsable du chargement, enregistrement, création et manipulation des
modules.
Les deux tâches principales d’ AToM³ sont la méta-modelisation et la transformation de
modèles. La première tâche assure la modélisation des différents formalismes, alors que la
deuxième est chargée par le processus de modification ou de conversion d’un modèle donné
dans un formalisme à un autre modèle (le formalisme du modèle source et celui du modèle
cible peuvent être identiques ou différents). Les formalismes et les modèles sont présentés
sous forme de graphes. AToM³ utilise le formalisme Entité-Relation (ER) ou le formalisme de
diagrammes de classes d'UML pour modéliser les formalismes, ce qui mène à générer un outil
visuel permettant la manipulation des modèles créés dans le formalisme modélisé. Les méta-
formalismes peuvent être étendus par l'ajout des contraintes afin de pouvoir spécifier avec
précision, les formalismes de modélisation. Les contraintes peuvent être spécifiées en utilisant
Chapitre 3 : Transformation de graphes et ATOM3
53
le langage OCL d'UML (Object Constraint Language), ou le code python (AToM³ est
implémenté en Python).
Dans le cadre de ce mémoire, nous avons choisi d’utiliser le méta-formalisme
(diagramme de classe d’UML) pour modéliser le formalisme, et le code python pour spécifier
les contraintes.
3.4. Conclusion
Dans ce chapitre, nous avons présenté l’approche MDA et son processus de
transformation de modèles, une classification des approches de transformation de modèles,
ainsi q’une introduction au transformation de graphes et une brève présentation de ses
approches. Nous avons également citer quelques outils de transformation de graphes et
présenter AToM³, l’outil visuel de modélisation et de méta-modélisation multi-formalismes,
utilisé dans l’implémentation de notre travail. Ce dernier sera présenté au chapitre suivant.
54
Chapitre 4
Une Approche de transformation des diagrammes
d’activité d’UML vers CSP basée sur la
transformation de graphes 4.1. Introduction Les diagrammes d’activité permettent la modélisation des systèmes workflows, des
modèles orientés service et des processus métiers. Ils sont adaptés à la modélisation du
cheminement de flux de données et de flux de contrôle. Ils incluent des mécanismes pour
exprimer le parallélisme, le séquencement, le choix et les événements. Cependant, ils
souffrent de l’inconvénient du manque des outils de vérification du comportement. Les
diagrammes d’activité doivent être fournies avec une sémantique formelle, afin de pouvoir
vérifier n’importe quel aspect du comportement. Pour pallier à ce problème le langage CSP
« Communicating Sequential Processes » (composé d’une collection des modèles
mathématiques et des méthodes de raisonnement) peut être utilisé, en définissant une
transformation des diagrammes d’activité vers CSP.
Le but de ce chapitre est de présenter une approche automatique de transformation des
diagrammes d’activité d’UML vers CSP, basée sur la transformation de graphes et réalisée à
l’aide de l’outil ATOM³.
ATOM³ est un outil visuel très puissant de méta-modélisation et de transformation des
modèles multi-formalismes. La transformation de modèles se base sur les grammaires de
graphes, qui sont une manière naturelle pour exprimer les transformations.
Plusieurs travaux ont utilisé ATOM³ comme outil de réalisation. Dans [Li] l’auteur a
l’utilisé cet outil pour définir les sémantiques opérationnelles des méta-modèles Kermeta
[Kermeta]. Puis les transforme en programmes Kermeta, ayants les mêmes fonctionnalités
que les programmes écrits manuellement.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
55
Dans [Elmansouri08b] les auteurs ont proposé une approche basée sur l’utilisation
combinée de méta-modélisation et des grammaires de graphes pour générer automatiquement
la description INA à partir des modèles INA graphiques.
ATOM³ est utilisé dans [Kerkouche05] pour méta-modéliser et transformer les
spécifications G-Nets vers les modèles PrT-Nets équivalents, et pour transformer les modèles
obtenus vers leur description équivalentes dans PROD [PROD]. Ce travail présente aussi une
description des principaux travaux réalisés par le biai de cet outil, nous citons : [DeLara02a]
pour transformer les automates d’état fini non déterministes vers les automates d’état fini
déterministes, [DeLara02b] pour transformer les statechart (sans hiérarchie) vers les réseaux
de Petri, [DeLara02c] ou les auteurs ont utilisés la méta-modélisation et les grammaires de
graphes pour traiter les modèles GPSS. Plusieurs autres travaux peuvent être trouvés dans
[DeLara05] ET [ATOM³] comme la transformation des diagrammes d’activité d’UML vers
les réseaux de Petri.
Pour atteindre notre objectif, nous nous somme inspirés de [Bisztray07]. Nous proposons
un méta-modèle des diagrammes d’activité, et une grammaire de graphe.
4.2. Les diagrammes d’activité
La figure 4.1 montre un diagramme d'activité modélisant une opération. Les nœuds de
ce diagramme sont : un nœud initial, deux nœuds finaux, un nœud de décision et quatre
nœuds d’action.
Figure 4.1 : Un exemple de diagramme d’activité.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
56
4.3. Le langage CSP
L’équation récursive utilisée pour définir la syntaxe des processus CSP est la suivante :
P ::= F │event → E │ E ‖ F │ E \ F │ E ˂⁄ b ⁄ ˃ F │ SKIP │ STOP
4.4. Présentation des correspondances entre diagrammes d’activité et CSP
Dans [Bisztray07], les auteurs ont proposés une méthode de transformation des
diagrammes d’activité vers CSP par le biais de la transformation de graphes.
La méthode de transformation proposée consiste à présenter les correspondances entre
les deux modèles. L’idée du mapping est de relier un arc dans le diagramme d’activité à un
processus CSP. Les correspondances sont présentées Figure 4.2.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
57
InitialNode FinalNode
ActionNode
DecisionNode MergeNode
ForkNode JoinNode
Figure 4.2 : Représentation des correspondances entre diagrammes d’activité et CSP.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
58
4.5. Transformation des diagrammes d’activité d’UML vers CSP
Pour transformer les diagrammes d’activité en CSP, nous allons proposer un méta-
modèle (pour générer un outil visuel de modélisation des diagrammes d’activité) et une
grammaire de graphe.
4.5.1. Méta-Modélisation des Diagrammes d’activité
Le concept de méta-modèle constitue la propriété essentielle qui différencie la notation
UML des autres notations. C’est une base formelle, qui permet de décrire plus précisément la
syntaxe de la notation UML en utilisant UML elle-même [UML01].
4.5.1.1. Méta-modèle des diagrammes d’activité
Afin de définir le méta-modèle des diagrammes d’activité, nous avons utilisé l’outil de
méta-modélisation ATOM³. Ce méta-modèle permet de spécifier les attributs, les contraintes,
les relations, ainsi que l’apparence graphique des nœuds et des arcs. Le méta_formalisme
utilisé dans ce travail est le diagramme de classe d’UML, et les contraintes sont exprimées en
code python. Le métamodèle proposé est composé de sept classes reliées par trente trois
associations.
.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
59
Figure 4.3 : Le méta-modèle des diagrammes d’activité.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
60
4.5.1.1.1. Les associations
Chaque association du méta-modèle possède un attribut Name de type String. Elle relie
chaque instance de la Classe Source avec une seule instance de la Classe Destination. Les
cardinalités pour chaque association sont :
- To target: 1 to 1.
- From source: 1 to 1.
4.5.1.1.2. Les classes
Les classes sont décrites comme suit :
1. Classe InitialNode : représente le début d’un diagramme d’activité. Graphiquement,
elle est représentée par un petit cercle plein. Elle possède une contrainte qui interdit
l’existence de plus d’un arc sortant. Elle peut être reliée par l’une des associations
suivantes :
Initial2Action : avec la classe ActionNode.
Initial2Decision : avec la classe DecisionNode.
Initial2Fork : avec la classe ForkNode.
Initial2Merge : avec la classe MergeNode.
Figure 4.4 : La classe InitialNode.
2. Classe ActionNode : cette classe représente une opération atomique non
décomposable et non interruptible. Elle est représentée visuellement par un ovale qui
contient sa description textuelle. Elle possède trois attributs de type String
(ActionName : nom de l’action, input : nom de l’arc entrant, output : nom de l’arc
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
61
sortant) et deux contraintes qui limitent le nombre des arcs entrants à 1, et de même
pour les arcs sortants. La classe ActionNode peut être reliée par l’association :
Action2Action : avec la classe ActionNode.
Action2Fork : avec la classe ForkNode.
Action2Join : avec la classe JoinNode.
Action2Decision : avec la classe DecisionNode.
Action2Merge : avec la classe MergeNode.
Action2Final : avec la classe FinalNode.
Figure 4.5 : La classe ActionNode.
3. Classe DecisionNode : cette classe spécifie les différentes alternatives possibles. Elle
a un seul arc entrant et deux ou plusieurs arcs sortants, ces derniers peuvent être
gardés par des conditions mutuellement exclusives. Graphiquement, elle est
représentée par un losange. Elle possède trois attributs de type String (Name : nom du
noeud, input : nom de l’arc entrant, output : concaténation des noms et des gardes de
tous les arcs sortants) et une contrainte qui limite le nombre des arc entrants à 1. La
classe DecisionNode peut être reliée par l’association :
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
62
Decision2Action : avec la classe ActionNode.
Decision2Fork : avec la classe ForkNode.
Decision2Join : avec la classe JoinNode.
Decision2Decision : avec la classe DecisionNode.
Decision2Merge : avec la classe MergeNode.
Decision2Final : avec la classe FinalNode.
Figure 4.6 : La classe DecisionNode.
4. Classe ForkNode : elle représente un nœud de synchronisation qui possède un seul
arc entrant et plusieurs arcs sortants qui doivent être déclenchés simultanément. Elle
possède trois attributs de type String (Name : nom du noeud, input : nom de l’arc
entrant, output : concaténation des noms des arcs sortants) et une contrainte qui
interdit l’existence de plus d’un arc entrants. La classe ForkNode peut être reliée par
l’association :
Fork2Action : avec la classe ActionNode.
Fork2Fork : avec la classe ForkNode.
Fork2Join : avec la classe JoinNode.
Fork2Decision : avec la classe DecisionNode.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
63
Fork2Merge : avec la classe MergeNode.
Le nœud ForkNode est représenté par un trait plein.
Figure 4.7 : La classe ForkNode.
5. Classe MergeNode : cette classe rassemble plusieurs flots entrants en un seul flot
sortant. Elle possède trois attributs de type String (Name : nom du noeud, input :
concaténation des noms des arcs entrants, output : nom de l’arc sortant). Elle possède
une contrainte qui interdit l’existence de plus d’un arc sortant. Visuellement, elle est
représentée par un losange. La classe MergeNode peut être reliée par l’association :
Merge2Action : avec la classe ActionNode.
Merge2Fork : avec la classe ForkNode.
Merge2Join : avec la classe JoinNode.
Merge2Decision : avec la classe DecisionNode.
Merge2Merge : avec la classe MergeNode.
Merge2Final : avec la classe FinalNode.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
64
Figure 4.8 : La classe MergeNode.
6. Classe JoinNode : elle représente un nœud de synchronisation qui ne peut être
franchit que lorsque toute les transitions en entrée ont été déclenchées. Elle est reliée
par plusieurs transitions en entrée et une seule transition en sortie. Elle possède trois
attributs de type String (Name : nom du noeud, input : concaténation des noms des
arcs entrants, output : nom de l’arc sortant) et une contrainte qui interdit l’existence de
plus d’un arc sortant. La classe JoinNode peut être reliée par l’association :
Join2Action : avec la classe ActionNode.
Join2Fork : avec la classe ForkNode.
Join2Join : avec la classe JoinNode.
Join2Decision : avec la classe DecisionNode.
Join2Merge : avec la classe MergeNode.
Join2Final : avec la classe FinalNode.
Graphiquement, elle est représentée par un trait plein.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
65
Figure 4.9 : La classe JoinNode.
7. Classe FinalNode : indique une terminaison avec succès. Elle possède un ou plusieurs
arcs entrants et aucun arc sortant, elle est représentée visuellement par un cercle vide
contenant un petit cercle plein. Cette classe possède deux attributs de type String
(Name : nom du noeud, input : concaténation des noms des arcs entrants).
Figure 4.10 : La classe FinalNode.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
66
4.5.1.2. Génération de l’outil de modélisation des Diagrammes d’activité :
Le méta-modèle des diagrammes d’activité créé précédemment, permet de générer l’outil
de modélisation présenté ci-dessous.
Figure 4.11 : Outil généré pour modéliser les Diagrammes d’activité.
En utilisant cet outil, nous pouvons modéliser les diagrammes d’activité contenants les
nœuds suivants :
Figure 4.12 : Représentation graphique des nœuds du diagramme d’activité.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
67
Cette figure représente graphiquement les nœuds du diagramme d’activité. De gauche vers
la droite on trouve : un nœud initial, un nœud d’action, un nœud de décision, un nœud de fusion,
un nœud de bifurcation, un nœud d’union et finalement on trouve un nœud final.
4.5.2. Grammaire de graphe pour la transformation des diagrammes d’activité d’UML vers
CSP
Nous avons proposé une grammaire de graphe composée de trente neuf règles qui seront
exécutées dans un ordre ascendant. Selon leur rôle dans la grammaire de graphe, les règles peuvent
être divisées en deux parties :
{règle 1,.., règle 33} : ces règles sont chargées de Capter les données nécessaires
pour générer le code Csp (Une garde, le nom d’une action,…).
{règle 34,.., règle 39} : le rôle de ces règles est de générer le code Csp qui
correspond au nœud spécifié.
La grammaire de graphe est nommée UML2CSP. Elle a une action initiale permettant de
créer un fichier texte pour écrire le code Csp généré, et une variable globale « Visited » pour
éviter l’exécution d’une règle sur le même nœud plusieurs fois.
Finalement, nous avons ajouté un bouton « Generate Csp Code » dans l’interface
utilisateur, afin d’exécuter la grammaire de graphe.
L’exécution de cette grammaire sur un diagramme d’activité, permet d’obtenir
automatiquement le code Csp équivalent à ce diagramme (Spécification textuelle en Csp).
4.5.2.1. Description des règles Les règles sont décrites comme suit :
Règle 1 : rule_Initial2Action (Priority 1) : Cette règle est appliquée pour
localiser un nœud d’action non encore traité, qui soit relié au nœud initial par un arc
entrant étiqueté. Le nom de ce dernier est affecté à l’attribut ‘input’ du nœud d’action
qui sera ensuite marqué comme "Visited" pour la première fois.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
68
Règle 2 : rule_ Action2Action (Priority 2) : Appliquée pour localiser deux nœuds
d’action reliés par un arc, dont la destination est non encore traité. Le nom de l’arc est
gardé comme "output" au niveau du nœud source, et comme "input" au niveau du nœud
destination. Ce dernier est marqué comme "Visited" pour la première fois.
Règle 3 : rule_ Action2Final (Priority 3) : Appliquée pour localiser un arc non
encore traité, reliant un nœud d’action (source) à un nœud final (destination). Le nom
de cet arc est affecté à "output" du nœud source, et il est concaténé à "input" du nœud
destination.
Règle 4 : rule_ Merge2Final (Priority 4) : Appliquée pour localiser un arc non
encore traité, reliant un nœud de fusion (source) à un nœud final (destination). Le
nom de cet arc est affecté à "output" du nœud source, et concaténé à "input" du nœud
destination.
Règle 5 : rule_ Merge2Action (Priority 5) : Cette règle est appliquée pour
localiser un nœud d’action non encore traité, qui soit relié à un nœud de fusion par un
arc entrant. Le nom de ce dernier est affecté à l’attribut "output" du nœud source, et à
l’attribut "input" du nœud destination qui sera ensuite marqué comme "Visited" pour la
première fois.
Règle 6 : rule_ Join2Action (Priority 6) : Appliquée pour localiser un noeud
d’action non encore traité, qui soit relié à un noeud d’union par un arc entrant. Le
nom de cet arc est associé à "output" du nœud d’union, et "input" du nœud d’action. Ce
dernier est marqué comme "Visited" pour la première fois.
Règle 7 : rule_ Action2Decision (Priority 7) : Appliquée pour localiser un noeud
de décision non encore traité (destination), relié à un noeud d’action (source). Le nom
de l’arc reliant les deux nœuds est affecté à "output" du nœud source, et "input" du
nœud destination. Ce dernier est marqué comme "Visited" pour la première fois.
Règle 8 : rule_ Merge2Decision (Priority 8) : Appliquée pour localiser un noeud
de décision non encore traité (destination), relié à un noeud de fusion (source). Le
nom de l’arc reliant les deux nœuds est affecté à "output" du nœud source, et "input"
du nœud destination. Ce dernier est marqué comme "Visited" pour la première fois.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
69
Règle 9 : rule_ Join2Decision (Priority 9) : Cette règle est appliquée pour
localiser un noeud de décision non encore traité (destination), qui soit relié à un
noeud d’union (source). Le nom de l’arc reliant les deux nœuds est affecté à "output"
du nœud d’union, et "input" du nœud de décision. Ce dernier est marqué comme
"Visited" pour la première fois.
Règle 10 : rule_ Action2Fork (Priority 10) : Appliquée pour localiser un noeud
de bifurcation non encore traité (destination), relié à un noeud d’action (source). Le
nom de l’arc reliant les deux nœuds est affecté à "output" du nœud source, et "input"
du nœud destination. Ce dernier est marqué comme "Visited" pour la première fois.
Règle 11 : rule_ Merge2Fork (Priority 11) : Appliquée pour localiser un noeud
de bifurcation non encore traité (destination), relié à un noeud de fusion (source). Le
nom de l’arc reliant les deux nœuds est affecté à "output" du nœud de fusion, et
"input" du nœud de bifurcation. Ce dernier est marqué comme "Visited" pour la
première fois.
Règle 12 : rule_ Join2Fork (Priority 12) : Appliquée pour localiser un noeud de
bifurcation non encore traité (destination), relié à un noeud d’union (source). Le nom
de l’arc reliant les deux nœuds est affecté à "output" du nœud source, et "input" du
nœud destination. Ce dernier est marqué comme "Visited" pour la première fois.
Règle 13 : rule_ Initial2Fork (Priority 13) : Cette règle est appliquée pour
localiser un noeud de bifurcation non encore traité, qui soit relié au nœud initial par
un arc entrant. Le nom de ce dernier est affecté à "input" du nœud de bifurcation
marqué ensuite comme "Visited" pour la première fois.
Règle 14 : rule_ Initial2Decision (Priority 14) : Cette règle est appliquée pour
localiser un noeud de décision non encore traité, qui soit relié au nœud initial par un
arc entrant. Le nom de ce dernier est affecté à "input" du nœud de décision marqué
comme "Visited" pour la première fois.
Règle 15 : rule_ Join2Final (Priority 15) : Appliquée pour sélectionner un arc
non encore traité, reliant un nœud d‘union (source) à un nœud final (destination). Le
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
70
nom de cet arc est affecté à "output" du nœud d’union, et concaténé à "input" du nœud
final.
Règle 16 : rule_ Decision2Join (Priority 16) : Appliquée pour localiser un arc
non encore traité, reliant un nœud de décision (source) à un nœud d’union
(destination). Le nom de cet arc et la condition de garde sont concaténés à "output" du
nœud de décision, mais le nom seulement (sans condition de garde) est concaténé à
"input "du nœud d’union.
Règle 17 : rule_ Decision2Merge (Priority 17) : Cette règle est appliquée pour
localiser un arc non encore traité (n’appartient pas à" input" du nœud destination),
reliant un nœud de décision (source) à un nœud de fusion (destination). Le nom de cet
arc et la condition de garde sont concaténés à "output" du nœud de décision, mais le
nom seulement (sans condition de garde) est concaténé à "input" du nœud de fusion.
Règle 18 : rule_ Fork2Join (Priority 18) : Appliquée pour localiser un arc non
encore traité, reliant un nœud de bifurcation (source) à un nœud d’union(destination).
Le nom de cet arc est concaténé à "output" du nœud source, et à "input" du nœud
destination.
Règle 19 : rule_ Fork2Merge (Priority 19) : Appliquée pour localiser un arc non
encore traité, reliant un nœud de bifurcation (source) à un nœud de fusion
(destination). Le nom de cet arc est concaténé à "output" du nœud source, et à "input"
du nœud destination.
Règle 20 : rule_ Decision2Action (Priority 20) : Cette règle est appliquée pour
localiser un nœud d’action non encore traité, qui soit relié à un nœud de décision par
un arc entrant étiqueté par un nom et une condition de garde. Ces deux derniers
attributs sont concaténés à l’attribut "output" du nœud de décision, mais le nom
seulement est affecté à "input" du nœud d’action, qui sera ensuite marqué comme
"Visited " pour la première fois.
Règle 21 : rule_ Fork2Action (Priority 21) : Appliquée pour localiser un nœud
d’action non encore traité, qui soit relié à un nœud de bifurcation par un arc entrant.
Le nom de ce dernier est concaténé à l’attribut "output" du nœud de bifurcation, et
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
71
affecté à l attribut "input" du nœud d’action qui sera ensuite marqué comme "Visited "
pour la première fois.
Règle 22 : rule_ Decision2Decision (Priority 22) : Appliquée pour localiser deux
nœuds de décision reliés par un arc, dont la destination est non encore traitée, le nom
de l’arc et la condition de garde sont concaténés à l’attribut "output" du nœud source,
mais le nom seulement est affecté à l’attribut "input" du nœud destination, ce dernier
est marqué comme "Visited " pour la première fois.
Règle 23 : rule_ Fork2Decision (Priority 23) : Appliquée pour localiser un nœud
de décision non encore traité, qui soit relié à un nœud de bifurcation par un arc
entrant. Le nom de ce dernier est concaténé à l’attribut "output" du nœud source, et
affecté à l’attribut "input" du nœud destination marqué comme "Visited " pour la
première fois.
Règle 24 : rule_ Decision2Fork (Priority 24) : Cette règle est appliquée pour
localiser un nœud de bifurcation non encore traité, qui soit relié à un nœud de
décision par un arc entrant étiqueté par un nom et une condition de garde. Ces deux
derniers attributs sont concaténés à l’attribut "output" du nœud de décision, mais le
nom seulement est affecté à "input" du nœud de bifurcation marqué comme "Visited "
pour la première fois.
Règle 25 : rule_ Decision2Final (Priority 25) : Cette règle est appliquée pour
localiser un arc non encore traité (n’appartient pas à" input" du nœud destination),
reliant un nœud de décision (source) à un nœud final (destination). Le nom de cet arc
et la condition de garde sont concaténés à "output" du nœud de décision, mais le nom
seulement (sans condition de garde) est concaténé à "input" du nœud final.
Règle 26 : rule_ Fork2Fork (Priority 26) : Appliquée pour localiser deux nœuds
de bifurcation reliés par un arc, dont la destination est non encore traité, Le nom de
l’arc est concaténé à l’attribut "output" du nœud source, et affecté à l’attribut "input"
du nœud destination marqué comme "Visited " pour la première fois.
Règle 27 : rule_ Action2Join (Priority 27) : Appliquée pour localiser un arc non
encore traité, reliant un nœud d’action (source) à un nœud d’union(destination). Le
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
72
nom de cet arc est affecté à "output" du nœud source, et concaténé à "input" du nœud
destination.
Règle 28 : rule_ Action2Merge (Priority 28) : Appliquée pour localiser un arc
non encore traité, reliant un nœud d’action (source) à un nœud de fusion
(destination). Le nom de cet arc est affecté à "output" du nœud source, et concaténé à
"input" du nœud destination.
Règle 29 : rule_ Merge2Join (Priority 29) : Appliquée pour localiser un arc non
encore traité, reliant un nœud de fusion (source) à un nœud d’union (destination). Le
nom de cet arc est affecté à "output" du nœud source, et concaténé à "input" du nœud
destination.
Règle 30 : rule_ Join2Merge (Priority 30) : Appliquée pour sélectionner un arc
non encore traité, reliant un nœud d‘union (source) à un nœud de fusion (destination).
Le nom de cet arc est affecté à "output" du nœud d’union, et concaténé à "input" du
nœud de fusion.
Règle 31 : rule_ Initial2Merge (Priority 31) : Appliquée pour localiser un arc
non encore traité, reliant le nœud initial (source) à un nœud de fusion (destination).
Le nom de cet arc est concaténé à "input" du nœud de fusion.
Règle 32 : rule_ Merge2Merge (Priority 32) : Appliquée pour localiser un arc
non encore traité, reliant deux nœuds de fusion. Le nom de cet arc est affecté à
"output" du nœud source, et concaténé à "input" du nœud destination.
Règle 33 : rule_ Join2Join (Priority 33) : Appliquée pour localiser un arc non
encore traité, reliant deux nœuds d’union. Le nom de cet arc est affecté à "output" du
nœud source, et concaténé à "input" du nœud destination.
Règle 34 : rule_ Action_Gen_Code (Priority 34) : Cette règle est appliquée pour
sélectionner un nœud d’action traité (Visited = 1) afin de générer dans un fichier Csp
le code correspondant. Le nœud est marqué comme "Visited" pour la deuxième fois.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
73
Règle 35 : rule_ Merge_Gen_Code (Priority 35) : Appliquée afin de générer le
code Csp correspondant pour chaque nœud de fusion (Visited = 0). Le nœud est
marqué comme "Visited".
Règle 36 : rule_ Decision_Gen_Code (Priority 36) : Appliquée pour sélectionner
un nœud de décision traité (Visited = 1) afin de générer le code Csp correspondant.
Le nœud est marqué comme "Visited" pour la deuxième fois.
Règle 37 : rule_ Fork_Gen_Code (Priority 37): Appliquée pour sélectionner un
nœud de bifurcation traité (Visited = 1) afin de générer le code Csp correspondant.
Le nœud est marqué comme "Visited" pour la deuxième fois.
Règle 38 : rule_ Join_Gen_Code (Priority 38) : Appliquée pour générer dans un
fichier Csp le code correspondant. Le nœud est marqué comme "Visited".
Règle 39 : rule_ Final_Gen_Code (Priority 39) : Appliquée afin de générer le
code Csp correspondant pour chaque nœud final. Ce dernier est marqué comme
"Visited".
La grammaire de graphe contient aussi une action finale permettant de fermer le fichier
texte ouvert, et détruire la variable « Visited » créée dans l’action initiale. Par la suite, nous
donnons une représentation graphique des règles.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
74
4.5.2.2. Représentation graphique des règles
1- rule_Initial2Action.Priority: 1 4- rule_ Merge2Final. Priority : 4
LHS RHS LHS RHS output = Node (3).Name
visited = = 0 visited = 1 Node(3).Name Not input = input + input = Node (3).Name In input Node (3).Name +’:’
2- rule_ Action2Action. Priority : 2 5- rule_ Merge2Action. Priority : 5 LHS RHS LHS RHS output = Node (3).Name output = Node (3).Name
visited = = 0 visited = 1 visited = = 0 visited = 1 input = Node (3). Name input = Node (3). Name
3- rule_Action2Final. Priority : 3 6- rule_ Join2Action. Priority : 6 LHS RHS LHS RHS output = Node (3).Name output = Node (3).Name
Node(3).Name Not input =input + visited = = 0 visited = 1 in input Node (3).Name + ‘:’ input = Node (3). Name
:: = :: =
:: = :: =
:: = :: =
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
75
7- rule_ Action2Decision. Priority : 7 10- rule_ Action2Fork. Priority : 10 LHS RHS LHS RHS output = Node(3).Name output = Node(3).Name
visited = = 0 visited = 1 visited = = 0 visited = 1 input = Node (3).Name input = Node (3).Name
8- rule_ Merge2Decision. Priority : 8 11- rule_ Merge2Fork. Priority : 11 LHS RHS LHS RHS output = Node (3).Name output = Node (3).Name
visited = = 0 visited = 1 visited = = 0 visited = 1 input = Node (3).Name input = Node (3).Name
9- rule_ Join2Decision. Priority : 9 12- rule_ Join2Fork. Priority : 12 LHS RHS LHS RHS output = Node(3).Name output = Node(3).Name
visited = = 0 visited = 1 visited = = 0 visited = 1 input = Node (3).Name input = Node (3). Name
:: = :: =
:: = :: =
:: = :: =
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
76
13- rule_ Initial2Fork. Priority: 13 16- rule_ Decision2Join. Priority : 16 LHS RHS LHS RHS output =output+ Node(3).Name+’:’
visited = = 0 visited = 1 edge=Node(3).Name edge= Node(3).Name input = Node (3).Name without guard condition without guard condition edge Not in input input=input+edge+’:’
14- rule_ Initial2Decision. Priority : 14 17- rule_ Decision2Merge. Priority : 17 LHS RHS LHS RHS output =output+ Node(3).Name+’:’
visited = = 0 visited = 1 edge=Node(3).Name edge= Node(3).Name input = Node (3).Name without guard condition without guard condition edge Not in input input=input+edge+’:’
15- rule_ Join2Final. Priority: 15 18- rule_ Fork2Join. Priority : 18 LHS RHS LHS RHS output = Node (3).Name output =output+ Node(3).Name+’:’
Node (3).Name input =input + Node(3).Name Not in input Node (3).Name + ‘:’ Not in input input =input+ Node (3). Name+’:’
:: = :: =
:: = :: =
:: = :: =
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
77
19- rule_Fork2Merge. Priority : 19 22- rule_Decision2Decision. Priority : 22
LHS RHS LHS RHS output =output + Node(3).Name+’:’ output =output+ Node(3).Name+’:’
Node(3).Name input =input visited = = 0 visited = 1 Not in input +Node (3). Name+’:’ edge= Node(3).Name without guard condition input=edge
20- rule_Decision2Action. Priority : 20 23- rule_ Fork2Decision. Priority : 23 LHS RHS LHS RHS output = output output =output + Node(3).Name+’:’ + Node(3).Name+’:’
visited = = 0 visited = 1 visited = = 0 visited = 1 edge = Node (3).Name input = Node(3).Name without guard condition input=edge
21- rule_Fork2Action. Priority : 21 24- rule_ Decision2Fork. Priority : 24 LHS RHS LHS RHS output =output output =output + Node(3).Name+’:’ +Node(3).Name+’:’
visited = = 0 visited = 1 visited = = 0 visited = 1 input = Node (3).Name edge= Node (3).Name without guard condition input=edge
:: = :: =
:: = :: =
:: = :: =
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
78
25- rule_ Decision2Final. Priority : 25 28- rule_ Action2Merge. Priority : 28 LHS RHS LHS RHS output =output + Node (3).Name+’:’ output = Node(3).Name
edge =Node (3).Name Node (3).Name input=input without guard condition edge=Node (3).Name Not in input + Node (3).Name + ’:’ edge Not in input without guard condition input=input +edge+’:’
26- rule_ Fork2Fork. Priority : 26 29- rule_ Merge2Join. Priority : 29 LHS RHS LHS RHS output =output output = Node(3).Name + Node(3).Name+’:’
visited = = 0 visited = 1 Node(3).Name input=input input = Node (3).Name Not in input + Node(3).Name+’:’
27- rule_ Action2Join. Priority : 27 30- rule_ Join2Merge. Priority : 30 LHS RHS LHS RHS output = Node(3).Name output=Node(3).Name
Node(3).Name input=input Node(3).Name input=input Not in input +Node (3).Name+’:’ Not in input +Node (3).Name+’:’
:: =
:: = :: =
:: = :: =
:: =
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
79
31- rule_ Initial2Merge. Priority : 31 34- rule_ Action_Gen_Code. Priority : 34
LHS RHS LHS RHS
Node(3).Name input=input visited = = 1 visited = 2 Not in input +Node (3).Name+’:’ generate the corresponding Csp Code
32- rule_ Merge2Merge. Priority : 32 35- rule_ Merge_Gen_Code. Priority : 35 LHS RHS LHS RHS output = Node(3).Name
Node(3).Name input=input visited = = 0 visited = 1 Not in input +Node (3).Name+’:’ generate the corresponding Csp Code
33- rule_ Join2Join. Priority : 33 36- rule_ Decision_Gen_Code. Priority : 36 LHS RHS LHS RHS output = Node(3).Name
Node(3).Name input=input visited = = 1 visited = 2 Not in input +Node (3).Name+’:’ generate the corresponding Csp Code
:: = :: =
:: = :: =
:: = :: =
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
80
37- rule_ Fork_Gen_Code. Priority: 37 39- rule_ Final_Gen_Code. Priority : 39 LHS RHS LHS RHS
visited = = 1 visited = 2 visited = = 0 visited = 1 Generate the corresponding Generate the corresponding Csp Code Csp Code
38- rule_ Join_Gen_Code. Priority: 38 LHS RHS
visited = = 0 visited = 1 Generate the corresponding Csp Code
Figure 4.13 : Grammaire de graphe pour la génération du code csp à partir des diagrammes d’activités.
L’objectif de la grammaire UML2CSP est la génération automatique du code à partir
d’un graphe, cela conduit à des règles ayants la partie gauche identique à la partie droite.
4.5.3. Exemple de transformation d’un diagramme d’activité vers CSP
La figure 4.14 présente un exemple de diagramme d’activité édité par l’outil
AD_META, qui est généré à partir du méta-modèle présenté dans la figure 4.3. Pour illustrer
notre approche, nous utilisons le même exemple proposé par les auteurs dans [Bisztray07].
:: = :: =
:: =
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
81
Figure 4.14 : Exemple de diagramme d’activités crée par notre outil.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
82
L’exécution de la grammaire de graphe sur cet exemple est présenté par la figure 4.15.
Figure 4.15 : Grammaire de graphe en cours d’exécution.
Finalement, on obtient le code CSP (Figure 4.16) équivalent au diagramme d’activité
présenté dans la figure 4.14.
Une Approche de transformation des diagrammes d’activité d’UML vers CSP basée sur la transformation de graphes
83
Figure 4.16 : Code CSP équivalent au diagramme d’activité présenté dans la figure 4.14. 4.6. Conclusion
Dans ce chapitre nous avons proposé une approche automatique pour transformer les
diagrammes d’activités d’UML vers CSP. La méthode proposée se base sur la transformation de
graphes, et utilise l’outil de modélisation et de méta-modélisation multi-formasimes ATOM³.
Afin de réaliser cette méthode, nous avons proposé un méta-modèle des diagrammes
d’activités et une grammaire de graphe. Le méta-modèle permet de générer un outil visuel de
modélisation des diagrammes d’activités, et la grammaire de graphe transforme ces derniers en
code CSP équivalent.
Enfin, nous avons donné un exemple pour illustrer cette transformation.
Conclusion générale
84
Conclusion générale Le travail présenté dans ce mémoire s’inscrit dans le domaine de l’ingénierie dirigée par
les modèles. Il se base essentiellement sur l’utilisation combinée de méta-modélisation et de
transformation de modèle. Plus précisément, la transformation de graphe est utilisée comme
outil de transformation de modèles.
Le résultat de notre travail est une approche automatique pour transformer les
diagrammes d’activité d’UML2.0 vers CSP « Communicating Sequential Processes ».
L’approche proposée est basée sur la transformation de graphes, et est réalisée à l’aide de
l’outil ATOM³.
Le travail est réalisé dans deux étapes :
La première étape consiste à proposer un méta-modèle des diagrammes d’activité, afin
de générer un outil visuel permettant la modélisation de ces diagrammes.
La deuxième étape propose une grammaire de graphe permettant de générer
automatiquement le code CSP sous forme textuelle, à partir des diagrammes d’activités
graphiques.
Comme perspectives, nous comptons dans un premier lieu, de continuer la
transformation des arcs et des nœuds non encor transformés dans le travail présenté (pin,
nœud d’expansion, nœud paramètre d’activité,…), afin d’arriver à une transformation
complète des diagrammes d’activité.
Ensuite, et dans le but de valider notre approche, nous devrons vérifier les diagrammes
obtenus en CSP.
Finalement, et afin d’arriver à développer une approche totalement automatique, incluant
tous les diagrammes UML, nous proposerons de continuer la transformation des autres
diagrammes UML (diagramme de séquence, diagramme de cas d’utilisation, diagramme
d’état/transition, etc …) vers le langage CSP en utilisant toujours la transformation de
graphes et l’outil ATOM³.
Bibliographie
85
Bibliographie
[AD]: “Diagramme d’activité”, adresse du document :
http://saoudyihab.voila.net/cours_uml/Diagramme_d_activite.pdf
[AGG]: AGG Home page: http://user.cs.tu-berlin.de/~gragra/agg/
[Agrawal03]: A.Agrawal, G.Karsai and F.Shi, “A UML-based Graph Transformation
Approach for Implementing Domain-Specific Model Transformations”, Institute for Software
Integrated Systems Vanderbilt University Nashville, TN 37235, USA, 2003.
[Andries99] M. Andries, G. Engels, A. Habel, B. Hoffmann, h.-J. Kreowski, s.Kuske, D.
Pump, A. Schürr et G. Taentzer, “Graph transformation for specification and programming”,
Science of Computer programming, vol 34, Avril 1999, Pages 1-54.
[ATOM³]: ATOM³ Home page: http://atom3.cs.mcgill.ca/
[Audibert08] : L. Audibert, “UML 2”, edition 2007-2008, adresse du document :
http://www-lipn.univ- paris13.fr/audibert/pages/enseignement/cours.htm
[Bisztray07]: D.Bisztray, K.Ehrig, et R.Heckel, “Case Study: UML to CSP Transformation“,
(2007) Case Study of the AGTIVE 2007 Tool Contest,
http://www.informatik.uni-marburg.de/~swt/agtive-contest/UML-to-CSP.pdf
[Blomer10]: J.Blomer R;Gei and E.Jakumeit, “The GrGen.NET User Manual”,
www.grgen.net, November 28, 2010.
[Boisvert10] : B.BOISVERT, L.FERAUD, S.SOLOVIEV, “ Calculs sur les attributs dans la
réécriture de graphes fondés sur les approches catégoriques et les types inductifs”, IRIT,
Université Paul Sabatier, 2010.
[booggie] : booggie Home page http://www.booggie.org/
[Casper]:Casper Home page http://proteina.di.fct.unl.pt/casper/downloads/casper-csp-xml-solver
Bibliographie
86
[Combemale08] : B. Combemale, “Ingénierie Dirigée par les Modèles (IDM), état de l’art”,
Institut de Recherche en Informatique de Toulouse, 12 août 2008.
[Czarnecki03]: K. Czarnecki and S. Helsen, “Classification of Model transformation
Approaches”, OOPSLA’03 Workshop on Generative Techniques in the Context of Model-
Driven Architecture, 2003.
[Deadlock]: Disponible à : http://wotug.org/parallel/theory/formal/csp/Deadlock/
[DeLara02a]: J. De Lara, H. Vangheluwe, "AToM3: A Tool for Multi-Formalism Modelling
and Meta-Modelling", LNCS 2306, pp.174-188. Présenté dans Fundamental Approaches to
Software Engineering - FASE'02 , dans European Joint Conferences on Theory And Practice
of Software - ETAPS'02, Grenoble, France, 2002.
[DeLara02b]: J. De Lara, H. Vangheluwe, “Computer aided multi-paradigm modelling to
process petri-nets and statecharts”, International Conference on Graph Transformations
(ICGT), Lecture Notes in Computer Science, vol. 2505, pp. 239-253, Springer-Verlag,
Barcelona, Spain, 2002.
[DeLara02c]: J. De Lara, H. Vangheluwe, “Using meta-modelling and graph grammars to
process GPSS models”, 16th European Simulation Multi-conference (ESM), pp. 100-107,
Society for Computer Simulation International (SCS), Darmstadt, Germany , 2002.
[DeLara05]: J. De Lara, H. Vangheluwe, “Model-Based Development: Meta-Modelling,
Transformation and Verification”, The Idea Group Inc, pp. 17, 2005.
[Ehrig06]: H.Ehrig, U.Prange, “Modeling with Graph Transformations”,
Technical University of Berlin, Germany, 2006.
[Ehrig99a]: H.Ehrig, H-J.Kreowski, U.Montanari and G.Rozenberg, “Handbook of graph
grammars and computing by graph transformation”, Volume 3: Concurrency, Parallelism,
and Distribution, 1999.
[Elmansouri08a]: R. El Mansouri.R, “Towards a Modeling Method for Business Processes
in Virtual Enterprises based on UML and ECATNets”, Information Management in Modern
Organizations: Trends & Challenges, Proceedings of The 9th International Business
Information Management Association Conference, January 4 - 6, 2008, Marrakech, Morocco.
Bibliographie
87
[ElMansouri08b]: R.ElMansouri, E.Kerkouche, and A.Chaoui, "A Graphical Environment
for Petri Nets INA, Tool Based on Meta-Modelling and Graph Grammars", PROCEEDINGS
OF WORLD ACADEMY OF SCIENCE, ENGINEERING AND TECHNOLOGY VOLUME
34 OCTOBER 2008 ISSN 2070-3740, Venice, Italy.
[Elmansouri09] : R. El Mansouri.R, “Modélisation et Vérification des processus métiers
dans les entreprises virtuelles : Une approche basée sur la transformation de graphes”, Thèse
de doctorat en sciences en informatique, soutenue à l’université Mentouri Constantine, 2009.
[FDR] : Documentation disponible à : http://web.comlab.ox.ac.uk/projects/concurrency-tools/
[Fujaba]: FUJABA Home page: http://www.fujaba.de/
[GRAIET07] : M.GRAIET, “Contribution à une démarche de vérification formelle
d’architectures logicielles”, Thèse de doctotat, Équipe SIGMA –LIG:Université Joseph
Fourier - Grenoble 1, Laboratoire MIRACL : Université de Sfax, Soutenue le 25 Octobre
2007.
[Great]: GReAT Website: http://repo.isis.vanderbilt.edu/tools/get_tool?GReAT
[Hoare78]: C. A. R. Hoare, “COMMUNICATING SEQUENTIAL PROCESSES”,
Comm. of the ACM, 21, 8 (1978), pp. 666-678.
[Haore85]: C. A. R. Hoare, “COMMUNICATING SEQUENTIAL PROCESSES”,
1985–2004.
[IDM09]: S. Diaw, R. Lbath, B. Coulette, “ Etat de l’art sur le développement logiciel basé
sur les transformations de modèles”. Laboratoire IRIT-UTM, Université de Toulouse 2-Le
Mirai, 2009.
[Karsai03]: G.Karsai, A.Agrawal, F.Shi, J.Sprinkle, “On the Use of Graph
Transformation in the Formal Specification of Model Interpreters”, Journal of Universal
Computer Science, vol. 9, no. 11 (2003), 1296-1321.
[Kerkouche05]: E.Kerkouche, A.Chaoui, "A Formal Verification Framework For G-Nets
Models Based On Graph Transformation", Journal of object technology, published by ETH
Zurich, Chair of software Engineering, Vol.4, No.3, May-June 2005. On line at
http://www.jot.fm
Bibliographie
88
[Kermeta]: Z.Drey, C.Faucher, F.Fleurey, V.Mahé, D.Vojtisek "Kermeta language,
Reference manual", Published Build date: 3-November-2010.
[Joyner10]: D. Joyner, M. Van Nguyen and N. Cohen, “Algorithmic Graph Theory”, Version
0.3, Edition 19 March 2010.
[Li]: J.Li, "Transforming Graph Grammar Specification of FSM to Kermeta",
School of Computer Science, McGill University.
[Martin97]: J.M.R.Martin, S.A.Jassim,”How to design Deadlock-free networks using CSP
and verification tools- A tutorial introduction”, Parallel programming an Java, A.Bakkers
(Ed.) ISO press, 1997.
[MDA02] : Projet ACCORD (Assemblage de composants par contrats en environnement
ouvert et réparti), Mai 2002.
[M-Schettini96]: A.M-Schettini and A.Peron, “A graph rewriting framework for statecharts
semantics”, 1996, Springer.
[OMG09]: “OMG Unified Modeling Language TM (OMG UML), Superstructure”,
Février 2009, URL Standard du document:
http://www.omg.org/spec/UML/2.2/Superstructure
[OMG99]: “OMG Unified Modeling Language Specification (draft)”, UML V1.3 alpha R2
January 1999.
[Perochon09] : L.Perochon, “UML : langage graphique de modélisation”, Juin 2009,
http://www.projet-plume.org/ressource/uml(INRA)
[ProBE]: “Process Behaviour Explorer ProBE User Manual”, 14 Jan 2003.
disponible à : http://www.fsel.com/software.html
[PROD]: PROD Home page, version 3.4.01, http://www.tcs.hut.fi/Software/prod/
[Python]: Python home page: htpp://www.python.org
[Radermacher00]: A.Radermacher, “Support for Design Patterns through Graph
Transformation Tools”, Lecture Notes in Computer Science, 2000.
Bibliographie
89
[Roscoe97]: A.W. Roscoe, “The Theory and Practice of Concurrency”,
Published 1997, revised to 2000 and lightly revised to 2005.
[Rozenberg97]: G.Rozenberg, “Handbook of graph grammars and computing by graph
transformation”, Volume 1: Foundations, 1997.
[Sorlin03] : S.Sorlin, P-A.Champin, C.Solnon, “Mesurer la similarité de graphes étiquetés”,
LIRIS CNRS FRE 2672.
[UML05] : H.Malgouyres, J-P.Seuma-Vidal, G.Motet, “REGLES DE COHERENCE
UML2.0”, Version 1.1, 2005.
[UML98]: G. Booch, J. Rumbaugh and I. Jacobson, “The Unified Modeling Language User
Guide”, Publisher: Addison Wesley, First Edition October 20, 1998.
[UML01] : UML : de l'action à la réflexion, Thèse de doctorat 2001.
[VIATRA]: VIATRA Home page: http://www.eclipse.org/gmt/VIATRA2/
[WIKI]: WIKIPEDIA, l’encyclopédie libre, Home page: http://wikipedia.fr