Automatisation de l’enchaînement des tâches exécutées sur des modèles

Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Institut de la Francophonie pour
l’Informatique, Hanoi, Vietnam

Nguyen Viet Hoa
Promotion 13, IFI

Institut National de Recherche en Informatique
et en Automatique - INRIA Lille-Nord Europe

Mémoire de fin d’études
Master en informatique
Option Systèmes et Réseaux

Automatisation de l’enchaînement des
tâches exécutées sur des modèles
Réalisé par :
Nguyen Viet Hoa
Promotion 13, IFI

Sous la direction de :
Cédric Dumoulin

Lille-France, le 01 Juillet 2009
1


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Remerciements
Tout d’abord, je voudrais remercier mon encadrement direct, Cédric Dumoulin,
pour sa responsabilité de mon stage et son aide de tout cœur dans ce stage. De nombreux
courriels et les discussions régulières avec lui m’ont aidés à comprendre au fur et à
mesure le problème. L’intelligence dans la façon de sa direction m’a également aidé à
mieux contrôler mes travaux et à surmonter les difficultés.

Je tiens à remercier particulièrement M. Jean -Luc DEKEYSER, responsable de
l’équipe - projet de m’avoir accueilli dans son équipe et de m’avoir aidé durant mon
stage.

Je voudrais aussi adresser mes grands remerciements à Alexis Muller et tous les
professeurs, chercheurs de l’équipe DART, pour les discussions utiles avec eux pendant
mon stage. Et je tiens également à remercier mes collègues, les stagiaires à l’INRIA Lille,
d’avoir partagé les difficultés de la vie au cours de mon stage.

Enfin, je remercie tous mes collègues, les professeurs et les personnels de l’IFI de
m’avoir aidé au cours de mes études .

2


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa

Promotion 13, IFI

Résumé
L’équipe projet INRIA DaRT propose un environnement de conception GASPARD
basé sur l’ingénierie dirigée par les modèles pour la conception de systèmes embarqués à
hautes performances. Les systèmes embarqués sont conçus à un niveau d ’abstraction
élevé à l’aide du profil standard MARTE (Modeling and Analysis of Real -time and
Embedded systems). En se basant sur l’Ingénierie Dirigée par les Modèles (IDM), les
modèles MARTE sont raffinés vers des niveaux d’abstraction plus bas. Cependant, dans
le système Gaspard actuel, la définition de la chaîne de transformation est complexe,
partant de modèles de hauts niveaux jusqu’à la production de code simulable, testable,
vérifiable. De plus, de la simulation et du refactoring sont appliqués manuel lement sur les
modèles générés. Il faut avoir donc une solution pour uniformiser toutes les tâches
différentes : transformation, test, simulation, refactoring. Et il faut avoir une solution pour
définir facilement les chaînes de tâches. Dans ce stage on do it proposer un métamodèle
ainsi qu’un profil UML qui permet la modélisation des différentes tâches, leurs donnés
d’entrée et de sortie, leurs dépendences, …Ensuite, on construit un moteur d’exécution
qui permet l’exécution des tâches.

Mots-clés : IDM (Ingénierie Dirigée par les Modèles), Gaspard 2, Transformation entres
des modèles, moteur d’exécution, Méta -modèle, EMF.

3


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Abstract
The DaRT project-team main research topic is the co -design of embedded
systems by a Model Driven Engineering (M DE) approach. We propose an integrated
development environment, called Gaspard 2, allowing the design of embedded systems
using models at a high level of abstraction. From these models, it is possible to
automatically generate various codes and models than can be used for example for
simulation. Going from the models at a high level of abstraction to the code is done
through a chain of model transformations using intermediate models.
In the actual Gaspard tool, the “transformation chain” definition is compl ex.
Furthermore, tools like simulators or refactoring are applied manually on generated
models. We would like to make uniform the different processes (transformation, test,
simulation, refactoring) applied on models. For that, we say that each process is a task
applied on input models and eventually producing output models. A task can depend on
other tasks, or on the presence of input models to be executed. Thus, we have a graph of
task dependencies.
We want to be able to define easily such execution grap h with an appropriate model, and
then execute a task. Execution of a task can be conditioned by different input and output
models, the dependencies…So we propose a Meta model allowing modeling such tasks,
their dependencies, their input and outputting mode ls…and then implementing the engine
allowing the execution of the tasks.

Key Words:

MDE (Model Driven Engineering), Metamodel, Models transformation,

Execution engine.

4

Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

TABLE DES MATIERES
Remerciements.................................................................................................................... 2
Résumé................................................................................................................................ 3
Abstract ............................................................................................................................... 4
TABLE DES MATIERES .................................................................................................. 5
LISTE DES FIGURES ....................................................................................................... 7
1
Introduction ................................................................................................................. 8
1.1
Contexte ........................................................................................................... 8
1.2
Objectifs ........................................................................................................... 8
1.3
Motivation ........................................................................................................ 9
1.4
Contribution ..................................................................................................... 9
1.5
Environnement du stage ................................................................................. 10
1.6
Organisation du document ............................................................................. 10
2
Etat de l’art................................................................................................................ 11
2.1

SPEM (Software Process Engineering Metamodel) ...................................... 11
2.1.1
Modèle conceptuel du SPEM .................................................................... 13
2.1.2
Paquet Basic Elements .............................................................................. 13
2.1.3
Paquet Process Structure ........................................................................... 14
2.1.4
Paquet Process Lifecycle ........................................................................... 16
2.1.5
Profil UML SPEM .................................................................................... 16
2.2
UML4SPM (UML2.0-Based Language For Software Process Modeling) .... 17
2.2.1
Métamodèle UML4SPM ........................................................................... 18
2.2.2
Le Package Process Structure ................................................................... 19
2.2.3
Le Package UML4SPM Foundation ......................................................... 20
2.2.4
Exécution des modèles de procédés UML4SPM ...................................... 24
2.3
Le diagramme d’activité UML et le profil ..................................................... 26
2.4
SPEM et UML4SPM pour le système Gaspard ............................................. 28
3
Le système Gaspard 2 ............................................................................................... 31
4
Modèlisation UML des chaînes d e transformation ................................................... 34
4.1

Objectifs ......................................................................................................... 34
4.2
Solution proposée........................................................................................... 35
4.3
Un profil pour la spécification de processus .................................................. 41
4.4
Le métamodèle d’execution ........................................................................... 44
4.5
Implémentation .............................................................................................. 49
4.5.1
La transformation UML vers modèle ........................................................ 49
4.5.2
Le moteur d’execution .............................................................................. 51
4.6
Mise en œuvre ................................................................................................ 52
5
Conclusion et Perspectives ....................................................................................... 54
Références ......................................................................................................................... 55
ANNEXE .......................................................................................................................... 57
Annexe 1 : La Modélisation et l’exécution d’une chaîne ................................................. 57
Annexe 2 : Génération des classes Java à partir le
métamodèle ................................. 61
Annexe 3 : La transformation QVTo ................................................................................ 63

5


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Annexe 4 : L’interface d’utilisation et Initialisation de la première tâche ....................... 66
Annexe 5 : Implantation de l’activité ................................................................................ 72
Annexe 6 : Implantation de l’action de transformation QVTo ......................................... 80
Annexe 7 : Implantation d’une tâche ................................................................................ 85
Annexe 8 : Implantation de la tâche de Java ..................................................................... 90

6


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

LISTE DES FIGURES
Figure 1. SPEM_Foundation et SPEM_Extension ........................................................... 12
Figure 2. Modèle conceptual du SPEM ............................................................................ 13
Figure 3. Paquet Basic Elements ...................................................................................... 14
Figure 4. Structure d’un procédé du SPEM ...................................................................... 15
Figure 5. Paquet Process Lifec ycle ................................................................................... 16
Figure 6. Exemple des classes de base .............................................................................. 17
Figure 7. Hiérarchie de packages du métamodèle UML4SPM ........................................ 18
Figure 8. UML4SPM Process Structure Package ............................................................. 19
Figure 9. UML4SPM Foundation Package ....................................................................... 21
Figure 10. UML4SPM Software Activity extending UML 2.0 Activity .......................... 23
Figure 11. UML4SPM WorkProduct extending UML 2.0 Artifact .................................. 24

Figure 12. The Execution Model approach ....................................................................... 26
Figure 13. Un exemple du diagramme d’activité UML .................................................... 28
Figure 15. Solution proposée e n utilisant UML4SPM...................................................... 31
Figure 17. L’enchaînement de transformations dans Gaspard actuel ............................... 33
Figure 18. Notre Moteur d’exécution ............................................................................... 35
Figure 20. L’interface d’utilisation ................................................................................... 38
Figure 21. Une modélisation par notre solution ................................................................ 39
Figure 22. Une sous-chaîne de la chaîne au dessus .......................................................... 39
Figure 23. Une chaîne qui utilise le garde de branches conditionnelles. .......................... 40
Figure 24. Le profil proposé ............................................................................................. 42
Figure 25. Un exemple de la modélisation de la chaîne de tâches ................................... 43
Figure 26. Métamodèle proposé pour les chaînes de trans formations GASPARD ......... 44
Figure 27. Création d’un nouveau diagramme d’activité ................................................. 58
Figure 28. Modélisation d’une tâche de transformation QVTo ........................................ 58
Figure 29. Modélisation d’une tâche Java ........................................................................ 59
Figure 30. Un exemple de lancement d’un diagramme d’activité UML .......................... 60
Figure 31. Le résultat de l’exécution de la chaîne dans la figure 22 ................................ 61
Figure 32. Créer un projet EMF ........................................................................................ 62
Figure 33. Importer le métamodèle ................................................................................... 62
Figure 34. Générer les classes Java pour le métamodèle .................................................. 63

7


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

1 Introduction
1.1

Contexte
L’équipe projet DaRT propose un environnement de conception GASPARD basé

sur l’ingénierie dirigée par les modèles pour la conception de systèmes embarqués à
hautes performances. Les systèmes embarqués sont conçus à un niveau d’abstraction
élevé à l’aide du profil standard MARTE ( Modeling and Analysis of Real -time and
Embedded systems). En se basant sur l’Ingénierie Dirigée par les Modèles (IDM), les
modèles MARTE sont raffinés vers des niveaux d’abstraction plus bas. En exploitant tout
ce potentiel, GASPARD permet aux concepteurs de générer automatiquement du code
pour la vérification formelle, la simulation et la synthèse de matériel à partir de
spécification haut niveau de systèmes embarqués à hautes performances.

Cependant, dans le système Gaspard actuel, la définition de la chaîne de
transformation est complexe, partant de modèles de hauts niveaux jusqu’à la production
de code simulable, testable, vérifiable. De plus, de la simulation et d u refactoring sont
appliqués manuellement sur les modèles générés. Il faut avoir donc une solution pour
uniformiser toutes les tâches différentes : transformation, test, simulation. Et il faut avoir
une solution pour définir facilement les chaînes de tâche s.

1.2

Objectifs
La tâche principale de mon stage est de trouver une solution pour faciliter la

définition de chaînes de tâches dans le système Gaspard, et ensuite, il faut créer un
moteur d’exécution automatique toutes les tâches dans la chaîne définit. On propose
l’utilisation du diagramme d’activité UML associé à un profil pour faciliter la

modélisation de la chaîne de transformation. On propose aussi un méta -modèle
permettant la modélisation des tâches, leurs dépendances, leurs modèles d’entrées et de
sorties. Enfin, un moteur exécute automatiquement toutes les tâches dans la chaîne qui est

8


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

définit dans le diagramme d’activité. Pour cela, il faut construire un programme (moteur)
qui permet d’implémenter la solution proposée. L’entrée de ce moteur est le d iagramme
d’activité UML qui modélise les chaînes de tâches différentes. Ce moteur exécute toutes
ces tâches en respectant le flux de tâches, le flux de donnée et les gardes des branches
conditionnelles.

1.3

Motivation
Ce stage m’offre l’occasion d’enrichir m es connaissances dans le domaine de

l’Ingénierie Dirigée par les Modèles (IDM) et de me familiariser avec les outils d’IDM
comme EMF, Eclipse, Papyrus UML et QVT. La proposition du métamodèle, et du profil
UML ainsi que l’implémentation du moteur d’exécuti on m’ont permit d’acquérir des
connaissances en IDM, modélisation, méta modélisation, transformation QVTo. De plus,
je pourrais acquérir des connaissances dans le domaine des systèmes embarqués et
participer aux activités de recherche de l’équipe – projet DaRT.

1.4

Contribution
Au cours de ce stage, nous avons proposé une solution pour modéliser les chaînes

de transformation par l’utilisation de diagramme d’activité UML, et l’exécution
automatique de ces chaînes par un moteur d’exécution en Java. Actuelleme nt, les
transformations dans le système Gaspard sont exécutées de façon manuelle, mais la
chaîne de transformations dans le système Gaspard est assez complexe, partant de
modèles de hauts niveaux jusqu’à la production de code simulable, testable, vérifiabl e.
Avec la solution proposée, on peut définir facilement les chaînes de transformations dans
le système Gaspard en utilisant le diagramme d’activité UML ainsi que notre métamodèle
et notre profil. Grâce à l’utilisation de diagramme d’activité UML et une interface
graphique de notre moteur d’exécution, les utilisateurs peuvent modéliser aisément des
chaînes de tâches qui sont ensuite réalisés par notre moteur d’exécution.

9


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

1.5

Nguyen Viet Hoa
Promotion 13, IFI

Environnement du stage
Le centre de recherche INRIA Lille - Nord Europe est un des huit centres de

recherche de l'Institut National de Recherche en Informatique et en Automatique. Le lieu
de travail de ce stage se situe à l’INRIA Lille – Nord Europe, au sein de l’équipe DaRT
sous la responsabilité de Jean – Luc DEKEYSER - Responsable de l’équipe – projet et
Cédric DUMOULIN - maître de conférences. DaRT est un Equipe -projet commune avec
le LIFL (CNRS et Université des Sciences et Technologies de Lille). Ses activités de
recherche concernent principalement les modèles à parallélisme de do nnées et les
techniques de compilation.

1.6

Organisation du document
Le reste de ce document est organisé comme suit : Le chapitre 2 a pour but de

présenter les travaux concernés. Dans cette partie, on présente les travaux concernés :
SPEM (Software Process Engineering Metamodel) et UML4SPM (UML2.0-Based
Language For Software Process Modeling) . Et puis, on analyse les points forts et les
points faibles des deux travaux SPEM et UML4SPM avec notre problème.
Dans le chapitre 3, on présente notre solution, le mét amodèle, le profil et le moteur
d’exécution.
Dans le chapitre 4, on présente la conclusion et perspectives
Enfin, on donne en annexes quelques fichiers de code importants pour mieux comprendre
notre solution.

10


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

2 Etat de l’art
Cette partie a pour but de présenter les concepts de base de modélisation Dirigée
par les Modèles, ainsi que les travaux existants qui sont relatifs à notre travail. Cette
partie aborde les langages de modélisation, SPEM (Software Process Engineering
Metamodel) et UML4SPM

(UML2.0-Based Language For Software Process

Modeling) . Ce sont des langages de Modélisation de Procédés de Développement
Logiciel, ces travaux existants ont pour but d’augmenter la productivité des logiciels à
travers la manipulation de modèles dès les premières phases de développement. SPEM et
UML4SPM sont des documents utiles pour notre travail, on peut utiliser quelques
principes de ces deux langages pour notre métamodèle pour la modélisation des chaînes
de transformations dans le système Gaspard, mais ces deu x métamodèles ne sont pas
convenables avec la chaîne de transformations dans le système Gaspard. Nous
discuterons de leurs points faibles et points forts pour l’environnement Gaspard.

2.1

SPEM (Software Process Engineering Metamodel)
Le méta-modèle SPEM spécifié par l’OMG, permet la spécification de procédés de

développement en utilisant la notation UML. SPEM s’inscrit doublement dans
l’organisation de la pile de modélisation du MDA : en tant que méta -modèle conforme au
MOF et en tant qu’extension d’UML sou s la forme d’un profil.
SPEM est définit avec un sous ensemble d’UML, il contient SPEM_Foundation et
certaines extensions, nommé SPEM_Extensions.

11


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Figure 1. SPEM_Foundation et SPEM_Extension [10]

Ces deux paquets principaux SPEM_Foundation et SPEM_Ext ension contiennent
tous les paquets du SPEM. Les packages sont inclut dans tous les deux, UML et
SPEM_Foundation,

sont

Data_Types,

Core,

State_Machine,

Activity _Graphe,

Model_Management et un sous ensemble du paquet Common_Behavior nommé Actions.
Le paquet SPEM_Extension contient cinqs sous -paquets : Basic Elements,
Dependencies, Process Structure, Process Components, Process Lifecycle . Le paquet
Basic Elements décrit la relation entre les ModelElements et les guidances. Le paquet

Dependencies permet la définition des dépendances entre des WorkProducts. Le paquet
Process Structure permet aux modeleurs de définir les relations entre WorkProducts,
ProcessPerformers, ProcessRoles, WorkDefinitions . Le paquet Process Components
permet la description des processu s et leurs relations avec un autre, et le paquet Process
Lifecycle permet la définition des goals, constraints, preconditions sur WorkDefinitions.

12


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

2.1.1 Modèle conceptuel du SPEM
Un procédé de développement logiciel est une collaboration entre des entités
actives appelées rôles qui exécutent des activités sur les produits. Les activités sont
décrites comme une unité de travail, qui doit être engagé pour produire des produits.
Chaque WorkProduct est sous la responsabilité d’un unique rôle. Les rôles sont
nécessaires à réaliser des activités et produire des produits. Les Products décrisent des
artefacts qui sont consommés et produits par les rôles quand ils exécutent des tâches. En
conclusion, Le modèle conceptuel du SPEM peut être décrit par une seule phrase : Les
rôles exécutent des activités sur des produits.

Figure 2. Modèle conceptual du SPEM [9]

2.1.2 Paquet Basic Elements
Le paquet Basic Elements décrit la relation entre les ModelElements (dans le
paquet SPEM_Foundation) et un guidance pour exprimer comment un certain

ModelElement sont gérés.

13


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Figure 3. Paquet Basic Elements [10]

ExternalDescription est un document avec une spécification medium, name,
content, language. Un ModelElement peut avoir quelques descriptions extérieures. Chaque
ModelElement peut aussi associer à un certain nombre de guidances. Chaque Guidance
est un des certains GuidanceKind (Technique, UMLProfile, Checklist, ToolMentor,
Guideline, Template, Estimate).

2.1.3 Paquet Process Structure
Un WorkProduct est consommé, modifié, produi t par un processus. Les
WorkProducts sont des informations, documents, modèles, source code. Tous les
WorkProduct doivent être associés à un ou plusieurs WorkProductKinds qui décrit la
catégorie (UML model, executable et Code Library) d’un certain WorkProduct. Les
WorkProducts peuvent être associés aux ProcessRoles représentant le Role qui est
responsable d’un WorkProduct. L’état intérieur d’un WorkProduct peut être décrit par un
State Maschine (SPEM_Foundation ::State_Maschine).
Chaque

WorkDefinition

est

s ous

la

responsabilité

d’un

unique

rôle

(ProcessPerformer). Un ensemble d’autres rôles (ProcessRole) peuvent également assister
le rôle principal dans la réalisation d’activités. Dans la spécification de SPEM, un rôle est
une entité abstraite qui correspond à un ensemble de compétences.

14


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Une activité peut être décomposée en étapes (Step). Une étape n’est pas une
définition de travail et n’est donc pas liée à des produits.

Figure 4. Structure d’un procédé du SPEM [5]

15


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

2.1.4 Paquet Process Lifecycle

Figure 5. Paquet Process Lifecycle [10]
LifeCycle est une séquence de Phases et Iteration pour définir un travail
composite. Une activité peut être décomposée en étapes (Step). Une étape n’est pas une
définition de travail et n’est donc pas liée à des produits. Une Itération contient des
Workdefinitions complexes et une post-condition spécifiée. Chaque WorkDefinition peut
être associé à deux contraintes booléens Goal et Pre-Condition.

2.1.5 Profil UML SPEM
Le SPEM a été décrit comme un métamodèle. Mais en addition , la spécification
définit aussi le SPEM comme un profil UML. Après la description du SPEM comme un
métamodèle, les classes de base UML doivent être identifiées et stéréotypées qui
représentent les classes SPEM.

16

Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Figure 6. Exemple des classes de base [10]

2.2

UML4SPM (UML2.0-Based Language For Software Process
Modeling)
Le standard SPEM (Software Process Engineering Metamodel) de l'OMG (Open

Management Group), même dans sa nouvelle version, ne satisfait pas le critère
d'exécutabilité. Pour l'automatisation des tâches répétitives et non interactives du procédé
telles que la vérification de pré et de post conditions propres à l'exécution de chaque
activité, la régulation ainsi que le contrôle automatique des flux de données et d'artefacts,
l'affectation des agents aux rôles, la connexion avec des applications métier, etc.
Bendraou[1] a

proposé UML4SPM, un Langage de Modélisation de Procédés de

Développement Logiciel conçu selon une approche normative et visant à répondre aux
nouvelles attentes de la communau té logicielle.
Le langage UML4SPM (UML2.0 -Based Language For Software Process
Modeling) vient sous la forme d'un méta -modèle MOF qui étend un sous -ensemble du
standard UML2.0. UML4SPM profite l’expressivité de UML 2.0 en étendant un sous
ensemble de leurs éléments convenables à la modélisation du processus (comme Activités
et Actions). En adoptant UML 2.0 comme le base de l’UML4SPM, le langage UML4SPM

a profité des avantages de UML 2.0. UML 2.0 est actuellement un langage de
modélisation le plus connu dans l’industrie, et tout le monde est familiarisé avec ce
langage ainsi que plusieurs outils qui supportent ce langage. De plus, les diagrammes
UML sont intuitifs et facile à comprendre, et les modeleurs de UML et de SPEM peuvent

17


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

adopter facilement avec UML4S PM. Notamment, UML4SPM satisfait le critère
d’exécutabilité, on utilise des modèles de processus exécutables au lieu des modèles de
processus contemplatifs.

2.2.1 Métamodèle UML4SPM
Le métamodèle UML4SPM est sous forme des hiérarchies de packages. Les
packages UML4SPM_ Foundation et UML4SPM_Extensions sont deux packages au
niveau le plus hauts. Le package UML4SPM_Foundation contient un sous-ensemble de
concepts du standard UML2.0 utiles pour les mécanismes liés à la coordination des
activités, à la gestion des exceptions et à l'expression de concepts avancés (i.e., itérations,
conditions, etc.). Le package UML4SPM_Extensions contient des concepts sous forme des
méta classes MOF 2.0 et des sémantiques utiles pour la modélisation de processus de
logiciel (Software process modeling).

Figure 7. Hiérarchie de packages du métamodèle UML4SPM [11]

18


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

2.2.2 Le Package Process Structure
Le package Process Structure esl le principal de UML4SPM. Il représente les
concepts principaux propos à la modélisation de processus de logiciel (Software process
modeling) comme Software Activity, Role, WorkProduct, Guidance , ect. Ces concepts
sont présenté dans le figure 8, qui représentent le métamodèle MOF -Compliant. Les méta
classes hériteront ensuite des concepts du standard UML 2.0.

Figure 8. UML4SPM Process Structure Package [1]

Le méta classe abstraite Process Element représente une abstraction des processus
principaux (ex., Software Activities, Responsible Roles, WorkProducts ). Pour ces trois
éléments essentiels du procéd é (Software Activities, Responsible Roles, WorkProducts ), il
est possible d’en définir différents types selon le projet ou la méthodologie utilisée

19


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa

Promotion 13, IFI

pendant le développement. Ceci est assuré grâce à l'association entre la méta -classe
abstraite Process Element et Process Element Kind. Le méta classe abstraite Process
Element Kind a pour but de définir un processus spécifique ou des types définit par les
utilisateurs des éléments de processus (ex., les types spécifiques de WorkProducts, les
types spécifiques de Responsible Role, etc.). Tous les modèles de processus UML4SPM
contiennent l’élément Software Activity. Il décrit des efforts et des parties de travail à
réaliser durant le processus de développement de logiciel, il a des propriétés nommées
name et description pour décrire ce que doivent être fait par Responsible Roles de
l’activité, et une propriété priotity rangé de low à high pour souligner son importance avec
le processus et encore une propriété nommée complexity pour exprimer son niveau de
difficulté. Une Software Activity est sous la responsabilité d'un ou plusieurs Responsible
Role qui assure toutes les étapes de l'activité. Le méta classe Responsible Role définit ses
responsabilités, ses qualifications pour la réalisation de Software Activity. Un Responsible
Role est aussi responsable des WorkProducts réalisés dans le processus. Il est possible de
définir des kinds de Responsible Roles, par exemple « Analyst », « UML Modeller »,
« Java Tester », « Designer », « Project Manager », etc. Un Responsible Role peut être
affecté à un ou plusieurs Role Performer. Un Role Performer peut être un Agent, un outil
(Tool) ou bien une équipe (Team) qui à son tour peut être composée d'autres agents ou
bien d'autres équipes.

2.2.3 Le Package UML4SPM Foundation
Dans la partie précédente, le package Process Structure contient seulement
l’ensemble des concepts propos à la modélisation de processus de logiciel (Software
process modeling). Le package UML4SPM_Foundation contient un sous-ensemble de
concepts du standard UML2.0 utiles pour les mécanismes liés à la coordination des
activités, à la synchronisation, à la gestion des exceptions et à l'expression de concepts
avancés (i.e., itérations, conditions, etc.). UML4SPM regroupe principalement des
éléments des packages Activity et Actions qui montrent un haut potentiel pour des

processus de modélisation.

20


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Le package UML4SPM Foundation contient non seulement des méta classes et des
packages nécessaires à définir des diagrammes d’activité, mais aussi leurs supers classes
directes ou indirectes. Figure 9 donne une présentation des packages standards UML 2.0
nécessaires à définir des diagrammes d’activité.

Figure 9. UML4SPM Foundation Package [1]

21


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Dans ce qui suit, nous présentons le méta classe Activity et Artifact. Dans UML2
.0, une Activity est définie comme étant un comportement paramétré, spécifié en terme de
coordination d'actions. Cette coordination est assurée grâce à deux notions: le contrôle de

flux et le contrôle de données. Il est aussi possible d'exprimer des nœuds d e contrôle à
l'intérieur d'une activité. Ces derniers sont utilisés pour décrire des choix ( Decision Node),
du parallélisme (Fork Node), de la synchronisation (JoinNode), etc. Object Nodes dans des
activités ont pour but de représenter des objets et donnée s des comportements invoqués.
faisant hériter Software Activity de la méta-classe UML2.0 Activity. On peut profiter tous
les propriétés, associations, capabilités. Il est donc possible de composer une Software
Activity avec d'autres Software Activity, d'y inclure des Actions, des Object Nodes (ex.,
Pin, Activity Parameter Nodes, etc.) , et Control Nodes (ex., Fork, Join, Merge, Decision
Nodes, etc.). Et Actions peuvent être considérées les composantes atomiques ( Step) d’une
Software Activity. Software Activity hérite indirectement de UML2.0 Classifier, elle pourra
donc être enrichie avec de nouvel les propriétés ou bien de nouvelles opérations.

22


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Figure 10. UML4SPM Software Activity extending UML 2.0 Activity [1]

Le standard UML2.0 redéfinit un artifact comm e étant un Classifier représentant
une entité physique, par exemple, un modèle, un fichier de code source, des règles de
transformation, un exécutable, etc. La méta -classe UML4SPM WorkProduct hérite
d'Artifact. Les WorkProducts, Classifiers peuvent être utilisés comme paramètres d'entrée
et de sortie des actions en terme de InputPins et OutputPins, mais aussi des Software
Activities en tant que ActivityParameterNode. Enfin, un WorkProduct peut être associé à
un état de machine (state machine) qui définit leurs états, leurs opérations pour basculer

entre ces états.

23


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

Figure 11. UML4SPM WorkProduct extending UML 2.0 Artifact [1]

2.2.4 Exécution des modèles de procédés UML4SPM
Pour l'exécution des modèles de procédés UML4SPM, Bendraou [1] propose deux
approches. La première, Bendraou [1] a défini des règles de correspondances
d’UML4SPM vers WS-BPEL (Web Services Business Process Execution Language). La
seconde consiste à définir un modèle de comportement décrivant la sémantique
d'exécution des concepts UML4SPM, et l es modèles de procédés UML4SPM pourront
être exécutés directement. Dans ce rapport, nous n’abordons que l’approche qui utilise des
modèles d’exécution d’UML4SPM, parce que cette approche est semblable avec notre
approche. Comme notre approche, cette approc he construit aussi un moteur d’exécution
24


Mémoire de fin d’études
Automatisation des tâches exécutées par des modèles

Nguyen Viet Hoa
Promotion 13, IFI

afin d’exécuter directement des modèles UML4SPM. UML4SPM étant basé sur UML2.0.
Le but de cette approche est de permettre une exécution directe des modèles UML4SPM
dès que ceux-ci seront édités. Dans cette approche, la sémantique d’exécution des
concepts de UML4SPM décrit par un modèle de comportement, nommé modèle
d’exécution. Il prend la spécification de Executable UML Foundation en ajoutant certaines
fonctions (propriétés, opérations, classes) et des sémantiques p ropos à la modélisation de
processus de logiciel. Ce modèle d’exécution reprend le métamodèle UML4SPM, il ajoute
des opérations nécessaires à l’exécution des éléments du modèle. Ainsi, le comportement
de chaque concept est décrit par un ensemble d’opératio ns. Pour chaque concept du méta modèle UML4SPM ayant une sémantique opérationnelle, on définit une

Classe

d'Exécution dans le modèle d'exécution. Par conséquence, on a créé la classe
ActivityExecution pour l’élément Software Activity, la classe ActivityNodeExecution
pour l’élément ActivityNode, la classe ForkNodeExecution pour l’élément ForkNode, etc.
Chaque classe d'exécution contient l'ensemble des opérations qui reproduit le
comportement de l'élément UML4SPM. On a implanté l'ensemble des opérations des
principales classes d'exécutions en Java. Celles -ci regroupent les classes relatives aux
éléments UML4SPM mais aussi celles des Activités et Actions UML2.0. Le résultat est un
interpréteur (moteur d'exécution) UML4SPM qui prend en entrée des modèles de pro cédés
UML4SPM et qui les exécutent selon le comportement décrit par le modèle d'exécution
que nous avons défini. Tous les aspects liés aux actions, flux de contrôle, flux d'objets,
concurrence, choix, ont été implantés selon la sémantique décrite par UML2 .0. Un autre
aspect important est l’utilisation des nœuds de contrôle tels que les Decision Node
(branchement conditionnel) ou les Merge Node (acceptation d’un flux parmi plusieurs)
afin de réguler le flux de données à travers les différentes actions de l’ activité. Ces
derniers peuvent être renforcés par l’utilisation de gardes sur les flux d’objets reliant deux
actions (flèches entre différentes actions). Finalement, l’ OpaqueActions a pour but de
modéliser des interactions humaines ou bien une connexion à une application métier (ex.

Code Java, Service Web, Interface applicative, etc.). Une fois ce modèle de procédé
chargé par l’interpréteur d’UML4SPM, une première étape consiste à le parcourir et à
instancier pour chaque concept (ex. Initial Node, Object Flow, CallBehaviorAction, etc), la
classe exécutable lui correspondant dans le modèle d’exécution UML4SPM. Ensuite, la

25