Une Approche de transformation des diagrammes D'activité d'UML ...

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.


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


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.


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


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.


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).


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.


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é.


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.


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.


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.


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.


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.


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)


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.


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).


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é.


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


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


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.


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.


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)


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.


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.


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’


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.


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


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).


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].


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.


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.


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


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


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


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


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]


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é.


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


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]


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.


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.


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.


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.


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


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é.


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.


57

InitialNode FinalNode

ActionNode

DecisionNode MergeNode

ForkNode JoinNode

Figure 4.2 : Représentation des correspondances entre diagrammes d’activité et CSP.


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.

.


59

Figure 4.3 : Le méta-modèle des diagrammes d’activité.


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


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 :


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.


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.


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.


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.


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é.


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.


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.


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


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


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


72


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


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.


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.


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

:: = :: =

:: = :: =

:: = :: =


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

:: = :: =

:: = :: =

:: = :: =


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+’:’

:: = :: =

:: = :: =

:: = :: =


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

:: = :: =

:: = :: =

:: = :: =


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+’:’

:: =

:: = :: =

:: = :: =

:: =


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


33- rule_ Join2Join. Priority : 33 36- rule_ Decision_Gen_Code. Priority : 36 LHS RHS LHS RHS output = Node(3).Name


:: = :: =

:: = :: =

:: = :: =


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].

:: = :: =

:: =


81

Figure 4.14 : Exemple de diagramme d’activités crée par notre outil.


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.


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

Une Approche de transformation des diagrammes D'activité d'UML ...

Documents

Transcript of Une Approche de transformation des diagrammes D'activité d'UML ...