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

1.2 Objectifs La tâche principale de mon stage est de trouver une solution pour faciliter ladéfinition de chaînes de tâches dans le système Gaspard, et ensuite, il faut créer un moteur d

Institut de la Francophonie pour

l’Informatique, Hanoi, Vietnam

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

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 nombreuxcourriels 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 del’équipe - projet de m’avoir accueilli dans son équipe et de m’avoir aidé durant monstage

Je voudrais aussi adresser mes grands remerciements à Alexis Muller et tous lesprofesseurs, chercheurs de l’équipe DART, pour les discussions utiles avec eux pendantmon stage Et je tiens également à remercier mes collègues, les stagiaires à l’INRIALille, 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

L’équipe projet INRIA DaRT propose un environnement de conception GASPARDbasé 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 andEmbedded systems) En se basant sur l’Ingénierie Dirigée par les Modèles (IDM), lesmodè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 lesmodèles générés Il faut avoir donc une solution pour uniformiser toutes les tâchesdifférentes : transformation, test, simulation, refactoring Et il faut avoir une solution pourdéfinir facilement les chaînes de tâches Dans ce stage on do it proposer un métamodèleainsi qu’un profil UML qui permet la modélisation des différentes tâches, leurs donnésd’entrée et de sortie, leurs dépendences, …Ensuite, on construit un moteur d’exécutionqui permet l’exécution des tâches

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

The DaRT project-team main research topic is the co -design of embeddedsystems by a Model Driven Engineering (M DE) approach We propose an integrateddevelopment environment, called Gaspard 2, allowing the design of embedded systemsusing models at a high level of abstraction From these models, it is possible toautomatically generate various codes and models than can be used for example forsimulation Going from the models at a high level of abstraction to the code is donethrough 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 generatedmodels 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 taskapplied on input models and eventually producing output models A task can depend onother tasks, or on the presence of input models to be executed Thus, we have a graph oftask dependencies

We want to be able to define easily such execution grap h with an appropriate model, andthen execute a task Execution of a task can be conditioned by different input and outputmodels, the dependencies…So we propose a Meta model allowing modeling such tasks,their dependencies, their input and outputting mode ls…and then implementing theengine allowing the execution of the tasks

Key Words: MDE (Model Driven Engineering), Metamodel, Models transformation,Execution engine

TABLE DES MATIERES

Remerciements

Résumé

Abstract

TABLE DES MATIERES

LISTE DES FIGURES

1 Introduction

1.1 Contexte

1.2 Objectifs

1.3 Motivation

1.4 Contribution

1.5 Environnement du stage

1.6 Organisation du document

2 Etat de l’art

2.1 SPEM (Software Process Engineering Metamodel)

2.1.1 Modèle conceptuel du SPEM

2.1.2 Paquet Basic Elements

2.1.3 Paquet Process Structure

2.1.4 Paquet Process Lifecycle

2.1.5 Profil UML SPEM

2.2 UML4SPM (UML2.0-Based Language For Software Process Modeling)

2.2.1 Métamodèle UML4SPM

2.2.2 Le Package Process Structure

2.2.3 Le Package UML4SPM Foundation

2.2.4 Exécution des modèles de procédés UML4SPM

2.3 Le diagramme d’activité UML et le profil

2.4 SPEM et UML4SPM pour le système Gaspard

3Le système Gaspard 2

4Modèlisation UML des chaînes de transformation

4.1 Objectifs

4.2 Solution proposée

4.3 Un profil pour la spécification de processus

4.4 Le métamodèle d’execution

4.5 Implémentation

4.5.1 La transformation UML vers modèle

4.5.2 Le moteur d’execution

4.6 Mise en œuvre

5 Conclusion et Perspectives

Références

ANNEXE

Annexe 1 : La Modélisation et l’exécution d’une chaîne

Annexe 2 : Génération des classes Java à partir le Annexe 3 : La transformation QVTo

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

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

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 andEmbedded systems) En se basant sur l’Ingénierie Dirigée par les Modèles (IDM), lesmodè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 codepour la vérification formelle, la simulation et la synthèse de matériel à partir despé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 sontappliqués manuellement sur les modèles générés Il faut avoir donc une solution pouruniformiser toutes les tâches différentes : transformation, test, simulation Et il faut avoirune 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 ladé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èlepermettant la modélisation des tâches, leurs dépendances, leurs modèles d’entrées et desorties Enfin, un moteur exécute automatiquement toutes les tâches dans la chaîne qui est

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 iagrammed’activité UML qui modélise les chaînes de tâches différentes Ce moteur exécute toutesces tâches en respectant le flux de tâches, le flux de donnée et les gardes des branchesconditionnelles.

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écutionautomatique 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 lachaîne de transformations dans le système Gaspard est assez complexe, partant demodè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 interfacegraphique de notre moteur d’exécution, les utilisateurs peuvent modéliser aisément deschaînes de tâches qui sont ensuite réalisés par notre moteur d’exécution

1.5 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 DaRTsous la responsabilité de Jean – Luc DEKEYSER - Responsable de l’équipe – projet etCé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 derecherche concernent principalement les modèles à parallélisme de do nnées et lestechniques de compilation

1.6 Organisation du document

Le reste de ce document est organisé comme suit : Le chapitre 2 a pour but deprésenter les travaux concernés Dans cette partie, on présente les travaux concernés :SPEM (Software Process Engineering Metamodel) et UML4SPM (UML2.0-BasedLanguage For Software Process Modeling) Et puis, on analyse les points forts et lespoints 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

2 Etat de l’art

Cette partie a pour but de présenter les concepts de base de modélisation Dirigéepar les Modèles, ainsi que les travaux existants qui sont relatifs à notre travail Cettepartie aborde les langages de modélisation, SPEM (Software Process Engineering

Metamodel) et UML4SPM (UML2.0-Based Language For Software ProcessModeling) 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 quelquesprincipes 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èle s ne sont pasconvenables avec la chaîne de transformations dans le système Gaspard Nousdiscuterons 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 dansl’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 etcertaines extensions, nommé SPEM_Extensions

Figure 1 SPEM_Foundation et SPEM_Extension [10]

Ces deux paquets principaux SPEM_Foundation et SPEM_Ext ension contiennenttous 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.

2.1.1 Modèle conceptuel du SPEM

Un procédé de développement logiciel est une collaboration entre des entitésactives appelées rôles qui exécutent des activités sur les produits Les activités sontdé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 : Lesrô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.

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 lerô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

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]

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 travailcomposite Une activité peut être décomposée en étapes (Step) Une étape n’est pas unedé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écificationdéfinit aussi le SPEM comme un profil UML Après la description du SPEM comme unmétamodèle, les classes de base UML doivent être identifiées et stéréotypées qui

représentent les classes SPEM

Figure 6 Exemple des classes de base [10]

Modeling)

Le standard SPEM (Software Process Engineering Metamodel) de l'OMG (OpenManagement Group), même dans sa nouvelle version, ne satisfait pas le critèred'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 chaqueactivité, 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 ProcessModeling) vient sous la forme d'un méta -modèle MOF qui étend un sous -ensemble dustandard 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 demodélisation le plus connu dans l’industrie, et tout le monde est familiarisé avec celangage ainsi que plusieurs outils qui supportent ce langage De plus, les diagrammesUML sont intuitifs et facile à comprendre, et les modeleurs de UML et de SPEM peuvent

adopter facilement avec UML4S PM Notamment, UML4SPM satisfait le critèred’exécutabilité, on utilise des modèles de processus exécutables au lieu des modèles deprocessus 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]

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

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 d e 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

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]

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

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

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) Laseconde 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 êtreexécutés directement Dans ce rapport, nous n’abordons que l’approche qui utilise desmodèles d’exécution d’UML4SPM, parce que cette approche est semblable avec notreapproche Comme notre approche, cette approc he construit aussi un moteur d’exécution

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 deprocessus de logiciel Ce modèle d’exécution reprend le métamodèle UML4SPM, il ajoutedes 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 lecomportement de l'élément UML4SPM On a implanté l'ensemble des opérations desprincipales 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écutionque 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é Cesderniers 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

méthode « execute() » de l’activité initiale est appelée Le flux de contrôle ainsi que celuides données sont réalisés en suivant la sém antique des diagrammes d’activités UML2.0.Pour chaque type d’action, une implantation de sa méthode « doAction() » est réalisée etservira à activer le comportement l’action.

Figure 12 The Execution Model approach [1]

2.3 Le diagramme d’activité UML et le profil

Dans cette partie, nous représentons en bref la notion profil et ensuite nous

représentons le diagramme d’activité UML

- Le profil : Un metamodèle est un modèle qui va permettre d'exprimer des

modèles Le métamodèle UML permet d'exprimer un mod èle UML Des modèles existent aux différents niveaux d’abstraction, un modèle représente une vue abstraite de la réalité

et est conforme à un métamodèle qui définit précisément les concepts présents à ce niveau d’abstraction ainsi que les relations entre ce s concepts.

Un profil par contre, est une notion UML Le profil est le mécanisme standard

d'extension à UML Il exprime des notions permettant d'adapter UML à un domaineparticulier En général, un modèle UML possède une sémantique très générale Il faut donc spécialiser UML pour l’adapter à un domaine spécifique Ce besoin d’extension est

possible grâce à la notion de profil coresspond au regroupement d’extensions et de

spécialisations du langage UML du point de vue de la notation et de la sémantique Celaest réalisé à l’aide du concept de stéréotype qui représente la définition d’une propriétésupplémentaire appliquée à un élément standard d’UML

 Stéréotype : Permet d'étendre une métaclasse UML pour en affiner le concept

 Tagged value : Ajoute une info rmation complémentaire à une metaclasse, généralement liée à un stereotype

Un métamodèle peut se mapper sur un profil pour étendre UML Par exemple, onpeut créer un métamodèle EJB, permettant de décrire une application utilisant les EJB,puis les concepts de ce métamodèle seront converti en Stereotypes et Tagged Values

- Diagramme d’activité UML [3]: Maintenant, Avant de représenter notre profil et un

exemple pour voir l’utilisation du profil, on présente la notion de diagramme d’activitéUML C’est le diagramme d’activité UML qui est utilisé pour définir des chaînes de tâchespar les utilisateurs Les diagrammes d’activité UML sont particulièrement adaptés à

la modélisation du cheminement de flots de contrôle et de flots de données Ils permettentdonc de représenter graphiquement le comportement d’une méthode ou le déroulement d’uncas d’utilisation Le diagramme d’activité UML peut contenir différents éléments, nous neprésentons ici que des éléments qu’on utilise pour la modélisation des chaînes de tâches Lafigure 13 montre un exemple de diagramme d’activité UML

L’élément le plus important est le nœud d’action Un nœud d’action est un nœudexécutable qui constitue l’unité fondamentale de la fonctionnalité exécutable dans unactivité Dans notre cont exte, le nœud d’action représente la tâche de transformation ou latâche Java ou un appel à une autre activité Un nœud d’action doit avoir au moins un arcentrant Le passage d’un nœud d’action vers une autre est matérialisé par une transition Unnœud de décision est un nœud de contrôle qui permet de faire un choix entre plusieurs

flots sortants Il possède un arc entrant et plusieurs arcs sortants, seul l’un entre eux est

retenu et ce choix est non déterministe Les nœuds d’objets ( Inputpin et Outputpin) ont

pour but de spécifier les valeurs passées en argument à une action et les valeurs de retour.Une action ne peut débuter que si l’on affecte une valeur à chacun de ses pins d’entrée.Quand l’action se termine, une valeur doit être affectée à chacun de ses pins de sortie

Demanderl’addition

Condition de garde Nœud de décision

note Régler la note Faire la veiselle

Paramètre d’activité Pin d’entrée et de sortie

Figure 13 Un exemple du diagramme d’activité UML

Un flot d’objets permet de passer des données d’une activité à une autre Un arcreliant un pin de sortie à un pin d’entrée est un flot d’objets

2.4 SPEM et UML4SPM pour le système Gaspard

Dans les parties précédentes, nous avons abordé les travaux concernés SPEM etUML4SPM Maintenant, nous allons analyser les points forts et les points faibles des cestravaux pour la chaîne de transformations dans le système Gaspard

Figure 14 Structure d’un procédé SPEM [1]

 Tout d’abord, Si on applique SPEM pour notre problème, il faut ajouter de nombreux stéréotypes pour affiner la sémantique de certains éléments de SPEM, pour le faire correspondance av ec le système Gaspard Ce n’est pas de travail facile

 Le méta-modèle SPEM est assez compliqué pour les chaînes de

transformations dans le système Gaspard Par exemple, dans le SPEM, une

activité peut être décomposée en étapes (Steps) Avec le système Gasp ard actuel,

ce n’est pas nécessaire, une tâche dans Gaspard réalise un seul travail De plus,

l’élément WorkProduct correspond avec l’entrée/sortie des tâches dans le système Gaspard, il faut donc rajouter une propriété de l’élément WorkProduct et un énumé ration pour indiquer leur type ( Input ou Output ou InOut) Un autre aspect important, c’est que l’élément ProcessRole sert à rien pour notre problème.

 De plus, le SPEM est utilisé seulement afin de documenter les procédés et non pas pour coordonner son exécution.

En revanche, UML4SPM satisfait le critère d’exécutabilité Afin d’exécuter lesmodèles de procédés UML4SPM, l’auteur de ce langage a définit un modèle decomportement, nommé modèle d’exécution, qui reprend le méta -modèle UML4SPM enlui rajoutant les opérations nécessaires à l’exécution des éléments du modèle L’auteur de

ce langage fournit aussi une implantation Java du modèle d’exécution, autrement dit,c’est un moteur d’exécution en Java pour réaliser le modèle d’exécution

Ce moteur d’exécution UML4SPM qui prend en entrée des modèles de procédésUML4SPM et qui les exécutent selon le comportement décrit par le modèle d’exécution(comme la présentation en partie de l’état de l’art, le modèle d’exécution contient desclasses d’exécution, chaque élément dans le modèle a une classe d’exécutioncorrespondante Chaque classe d’exécution contient des opérations nécessaires àl’exécution de leur élément) Mais une question est posée : « comment les utilisateurspeuvent construire leurs modèles de pr océdés UML4SPM ?», l’auteur de UML4SPMcrée manuellement ces modèles de procédés UML4SPM avec EMF Cela n’est pas

vraiment pratique De plus, pour créer des modèles complexes, cela va prendre beaucoup

de temps

Cependant, on peut penser à une solution : Au lieu de créer des modèles UML4SPM

de façon manuelle, on utilise le diagramme d’activité UML pour spécifier la chained’execution, puis, on transforme le modèle UML, à l’aide de QVTo, pour obtenir unmodèle conforme à UML4SPM Ce modèle peut alors être ex écuté par le moteurd’exécution UML4SPM La figure 15 montre cet approche

Modèle d’exécution UML4SPM

Diagramme

UML

….

Figure 15 Solution proposée en utilisant UML4SPM

Mais, avec cette approche, il faut modifier quelques classes d’exécution dumoteur d’exécution UML4SPM pour l’adapt er à notre problème Par exemple, on doitajouter et modifier le moteur pour avoir des classes d’exécution permettant d’appeler destransformations QVTo et des classes Java De plus, pour les chaînes de transformationsdans le système Gaspard actuel, le mé ta-modèle UML4SPM est lui aussi compliqué

Dans ce qui suit, nous allons présenter notre solution, en proposant unmétamodèle et un profil ainsi qu’un moteur d’exécution

L’environnement Gaspard (Graphical Array Specification for Par allel and

Distributed Computing) [7] reprend le schéma en « Y » de Gajski et Kuhn [7] afin de générer

différents codes à partir d’un même placement d’une applicaiton sur une architecture.L’ensemble de l’environnement Gaspard est construit dans une démarch e IDM (IngénierieDirigée par des Modèles), de la modélisation en UML jusqu’à la génération de code Lafigure 15 représente l’implémentation de l’environnement Gaspard

en IDM Chaque boîte représente un métamodèle et chaque flèche représente la

transformation entre des modèles Le métamodèle Deployed est le plus haut niveau

d’abstraction à partir duquel différentes transformations permettent de raffiner un modèle

jusqu’à la génération du code A partir d’un modèle conforme au métamodèle Deployed,

Gaspard peut générer plusieurs implémentations de ce modèle pour différents plateforme

d’exécution, ce modèle peut subir diverses transformations selon le code cible recherché :langages synchrones pour la vérification formelle, Fortran OpenMP pour le calculparallèle, SystemC pour la simulation et VHDL pour la synthèse de matériel La chaîneDeployed vers synchrone a pour but de fournir aux utilisateurs la possibilité de lavérification formelle En effet, MARTE ne fournit pas des sémantiques nécessaires àvalider formellement le système désigné Les langages Synchrones (SynchronesLanguages) sont utiles pour la validation et vérification au niveau fonctionnel La chaîne

de transformations composée du métamodèle Synchronous Equational permet la génération de code d e langages synchrones Le métamodèle Synchronous Equational

permet la description des applications au niveau fonctionnel Cette chaîne de

transformation permet la génération de code des langages synchrones Lustre et Signal La

chaîne Deployed vers Fortran OpenMP pour le calcul parallèle, vers SystemC pour lasimulation et vers VHDL pour la synthèse de matériel

Figure 16 L’environnement Gaspard et ses différents métamodèles [6]

Au dessous est un enchaînement de transformations dans Gaspard actuel, il contient différentes tâches, l’une après l’autre Cet enchaînement se compose des transformationsQVTo : UML2Marte, explicitallocaiton, linktopology, Synchronisation,ComputeFunction pour transformer le fichier UML d’entrée jusqu e le code Synchrons.Cet enchaînement contient aussi des tâches Java, qui sont chargé de transformer desmodèles conforment aux métamodèles en version Delta : MartePortInstanceCast,

LLTCast, CastDependencyGraphe, CastAsFunction

Figure 17 L’enchaînement de transformations d ans Gaspard actuel

4 Modèlisation UML des chaînes de transformation

Dans cette partie, nous allons exposer notre solution pour l’automatisation deschaînes de tâches dans l’environnement Gaspard Premièrement, nous présenterons le

profil proposé Ensuit e, nous allons présenter le métamodèle intermédiaire utilisé par le moteur d’execution qui sera lui aussi présenté Enfin, nous expliquerons comment utiliser

notre solution

4.1 Objectifs

Actuellement, la chaîne de transformation dans le système Gaspard est complexe,partant de modèle de haut niveau pour produire des modeles intermédiaire et du code Lachaine peut aller vers différentes cibles selon le code cible recherché : langages

synchrones pour la vérification formelle, Fortran OpenMP pour le calcul pa rallèle,SystemC pour la simulation et VHDL pour la synthèse de matériel Notre objectif estd’automatiser l’exécution des chaînes de transformation et permettre à l’utilsateur demodèliser sa chaîne de transformation à l’aide des diagrammes d’activité UML et d’unprofil associé

Notre chaîne de transformation devrait permettre de :

 Modéliser des tâches , en spécifiant leur s noms, leurs entrées/sorties, leur simplémentations Ensuite, cette tâche peut être utilisée plusieurs fois dans d’autreschaînes de processus

 Spécifier le type de tâche, le nom de la transformation QVT ou de la classe Java devant être exécuté par la tâche

 Spécifier les données produites et consomés par les tâches

 Spécifier le flot d’exécution et le flot de données

 Spécifier des garde s qui permettent de faire un choix entre plusieurs tâches suivantes

 Spécifier les types des objets produits et consommés par les tâches

 Définir une chaîne qui est contenu dans une autre chaîne de processus

 Les données transitant entre les tâches peuvent être des modèles ou des objets

4.2 Solution proposée

Pour la modélisation des chaînes de tâches dans Gaspard, nous avons choisid’utiliser un diagramme d’activité UML qui nous fournit la plupart des concepts Lesconcepts manquants, comme la spécifica tion des tâches sont fournits à l’aide d’un profil

Le diagramme d’activitè et le profil permettent de construire des modèles UML

représentant une chaîne de processus Et puis, un moteur de transformation QVTo vatransformer le modèle UML en un modèle d’ex écution Enfin, un moteur d’execution estchargé de réaliser toutes les tâches dans ce modèle d’exécution

Figure 18 Notre Moteur d’exécution

La figure 18 décrit le mécanisme d’exécution de notre solution Dans la figure 18,

àgauche, c’est l’entrée du moteur, le diagramme d’activité UML qui modélise deschaînes de tâches en utilisant notre profil Ensuite, notre moteur utilise une transformationQVTo (montrée sur la figure 18 par une flèche avec sa note « Transformation QVTo »)pour produire un modèle conforme à notre métamodèle (montrée sur la figure 18 par unrectangle avec son nom dedans) Enfin, le moteur execute le modèle de sortie de cette transformation QVTo ce qui permet l’exécution de la cha îne de transformation (montréesur la figure 18, à droite)

Une chaine de transforamtion est modelisé à l’aide d’activité UML, chaque actionUML representant un processus de la chaine Une act ion peut être stereotypé afin depréciser le type de processus (tr ansformation, classe Java, …).

L’enchainement des activités se fait par les flots de données ou les flots de contrôle

Un arc du flot de contrôle permet de décrire le séquencement de deux tâches, ce type d’arc transmet des jetons de contrôle, les jetons o fferts en entrée par la tâche source sonttransmis à la tâche cible, et un arc du flot d’objets permet de décrire le séquencement de deux paramètres d’entrées des tâches On peut enchaîner une tâche aussitôt qu’elle atoutes ses données en entrée et elle a le jeton de contrôle

Un autre aspect important est la spécification des objets d’entrée et des objets desortie pour une activité On peut spécifier des objets d’entrée et des objets de sortie pour

une activité en utilisant des nœuds paramètres d’activit é (activity parameter node en

anglais) Tout nœud paramètre d’activité est associé avec un paramètre de l’activité,correspondant au paramètre que le nœud objet va représenter au sein de la description del’activité, le type d’un nœud paramètre d’activité doit être le même que celui duparamètre de l’activité La figure 19 montre un exemple d’utilisation le paramètred’activité

Figure 19 Exemple du paramètre d’activité

Les utilisateurs peuvent définir les nouveaux types et ensuite ces types de donnéessont appliqués pour les paramètres de l’activité Les utilisateurs peuvent aussi définir letype des paramètres d’entrée de l’activité par une interface d’utilisation, avec la conditionqu’on ne l’a pas déjà fait dans le diagramme d’activité UML La figure 20 montrel’interface d’utilisation pour recueillir des paramètres d’activité d’entrée

Figure 20 L’interface d’utilisation

Les actions euvent utiliser n’importe quel type d’objet (Resource, objet Java, modèle,

fichier) Les actions utilisent des broches (pin) comme les objets d’entrée et les objets de

sortie Les broches sont connectées en entrée ou en sorties des actions Les utilisateurspeuvent définir les différents types de données en créant les classes qui expriment lestypes de donné es, et ensuite ils sont appliqués sur les broches

On peut définir une transformation, en spécifiant son nom, son type (QVT, …), sesentrées/sorties, son implémentation Cette transformation peut être utilise plusieurs foisdans d’autre chaỵne de processus Pour cela, On peut définir une transformation commeune activité, et on peut l’utiliser plusieurs fois dans d’autres chaỵnes de processus Onspécifie son type, son implémentation sous forme des paramètres de l’activité, sesentrées/sorties sont exprimés par des nœuds paramètres d’activité

Notre moteur permet la définition hiérarchique , on peut définir une chaỵne qui estcontenu dans une autre chaỵne de processus Les appels vers les autres chaỵnes de

processus sont assurés grâce à l’utilisation de CallBehaviorActions La figure 21 montre

un exemple ó la chaỵne nommée Activiti_0 contient une autre activité SaveModel L’activité SaveModel est chargé d’enregistrer le modèle d’entrée à un fichier nommé

Uml2Marte.mmDeployment.

Figure 21 Une modélisation par notre solution

Figure 22 Une sous-chaîne de la chaîne au dessus