Ma thèse

 Titre de la thèse :

SPEM4MDE : Un métamodèle et un environnement pour la modélisation et la mise en œuvre assistée de processus IDM

RESUME :

L’ingénierie dirigée par les modèles (IDM) connue sous le terme MDE (Model-Driven Engineering) en anglais est une discipline récente du génie logiciel qui recommande l’utilisation intensive des modèles et des transformations de modèles au cœur du processus de développement logiciel. Dans cette nouvelle perspective, les modèles occupent une place de premier plan parmi les artéfacts de développement et doivent en contrepartie être suffisamment précis et riches afin de pouvoir être interprétés ou transformés par des outils. L’avènement de l’IDM a suscité beaucoup d’intérêt de la part des organisations qui de fait commencent à transformer leur processus de développement traditionnel en un processus de développement dirigé par les modèles - appelé aussi processus IDM, ce dernier étant vu comme un enchaînement de transformations de modèles, chacune consommant un ou plusieurs modèles sources et produisant un ou plusieurs modèles cibles.

Au moment où les processus IDM commencent à émerger, nous notons l’absence d’un langage dédié pour les modéliser et les mettre en œuvre. L’intérêt de la modélisation des processus en général et des processus IDM en particulier est d’utiliser une terminologie unifiée et cohérente, afin de permettre d’une part une communication plus efficace entre les développeurs et d’autre part un meilleur suivi d’un projet de développement. La modélisation de processus permet aussi de gérer, de faire évoluer et de réutiliser efficacement les modèles de processus. L’intérêt de la mise en œuvre des processus est de permettre un meilleur guidage du développement, une vérification des contraintes des activités/transformations et la gestion de la cohérence des artéfacts/modèles du développement.

Le standard SPEM 2.0 dédié à la modélisation des processus propose des concepts génériques qui sont supposés être capables de décrire tout type de processus logiciel ou système, incluant les processus IDM. Cependant, les concepts de SPEM ne capturent pas la nature exacte des processus IDM. Les concepts de modèles, de métamodèles, de transformation de modèles et de leurs diverses relations ne sont pas explicitement pris en compte. D’autre part, une autre insuffisance majeure de SPEM réside dans le fait qu’il n’intègre pas les concepts relatifs à la mise en œuvre des processus. En effet, la spécification de SPEM affirme clairement que cette préoccupation n’est pas dans le champ d’intérêt de SPEM et propose d’exécuter les modèles de processus dans un formalisme externe basé soit sur les diagrammes d’activités UML 2.0, soit sur les machines à états d’UML, soit sur la notation BPMN (Business Process Modeling Notation).

L’objectif de cette thèse est triple : (1) proposer une extension de SPEM dans laquelle les concepts centraux des processus IDM sont réifiés ; (2) proposer un langage dédié à la modélisation comportementale des processus IDM ; (3) proposer une architecture conceptuelle d’un environnement logiciel d’aide à la modélisation et à la mise en œuvre des processus IDM. L’intérêt de la réification des concepts IDM est de permettre d’une part aux concepteurs de processus d’expliciter les aspects spécifiques au développement IDM, d’autre part de mieux assurer la cohérence des modèles produits par les transformations. Par exemple pour vérifier la relation de conformité entre un modèle et son métamodèle, il est important de spécifier les modèles et les métamodèles qui participent à une transformation.

Pour répondre aux deux premiers objectifs, nous avons défini un langage de modélisation et de mise en œuvre des processus IDM spécifié formellement sous forme d’un métamodèle appelé SPEM4MDE. Le métamodèle SPEM4MDE étend certains concepts de SPEM par des concepts relatifs au développement IDM (transformation, modèle, métamodèle, outil IDM). La réutilisation de SPEM 2.0 a pour principal intérêt de favoriser l’alignement de SPEM4MDE avec ce standard et de permettre ainsi une meilleure diffusion des concepts de SPEM4MDE. Pour réduire la complexité de SPEM4MDE, nous n’avons réutilisé que le paquetage Process Structure de SPEM 2.0 qui fournit les concepts basiques pour décrire la partie structurelle d’un processus. Pour décrire le comportement des processus IDM, SPEM4MDE réutilise le paquetage d’UML 2.2 Superstructure qui décrit les machines à états d’UML. Une machine à états est composée d’états définissant l’ensemble des états d’un élément d’un processus IDM et de transitions définissant les opérateurs de mise en œuvre spécifiques à cet élément. SPEM4MDE réutilise aussi le métamodèle QVT afin de spécifier le comportement d’une transformation, l’intérêt étant de tirer pleinement profit des outils d’implémentation et d’exécution liés à ce standard.

Pour répondre au troisième objectif, nous avons élaboré une architecture conceptuelle d’un environnement fondé sur une démarche en trois étapes.

 La première étape a pour but de décrire le modèle structurel et le modèle comportemental d’un processus IDM, conformément au métamodèle SPEM4MDE. Par la suite, ces deux modèles sont validés sur la base des contraintes OCL spécifiées dans le métamodèle SPEM4MDE.

 La deuxième étape a pour but de réutiliser et/ou d’adapter les modèles définis dans l’étape précédente aux spécificités d’un projet de développement déterminé et d’assigner les ressources nécessaires à la mise en œuvre (développeurs, outils, espaces de travail, …).

La troisième et dernière étape de cette démarche est la mise en œuvre du modèle de processus adapté. Elle est réalisée par les développeurs du projet en utilisant les outils IDM mis à leur disposition. Les développeurs sont assistés dans leurs tâches par un environnement de mise en œuvre qui s’appuie sur les modèles comportementaux du processus. Cette étape produit les livrables du projet (code, modèles, documentation, etc.).

Pour valider notre approche, un prototype a été développé sous l’environnement TOPCASED. Ce prototype fournit d’une part un éditeur graphique pour la modélisation structurelle et comportementale des processus IDM et d’autre part un environnement de mise en œuvre s’appuyant sur les modèles comportementaux des processus. Nous avons également appliqué notre approche à une étude de cas significatif: le processus UWE (UML-based Web Engineering), qui est un processus IDM dédié au développement d’applications web.

Mots clés: Ingénierie Dirigée par les Modèles (IDM), Transformation de Modèles, Langage de Modélisation de Processus (LMP), Développement dirigé par les modèles, Processus IDM, Processus UWE, Atelier de Génie Logiciel centré-Processus (AGLP), TOPCASED

Perspectives de Recherche :

L’approche proposée dans cette thèse comporte actuellement certaines limitations. La première limitation est dûe au fait que le métamodèle SPEM4MDE n’étend que la partie Process Structure de SPEM 2.0, en laissant de côté les paquetages de SPEM relatifs à la réutilisation d’élements de processus (Method Content, Managed Content, Process With Methods, Method Plug-in). L’extension du seul paquetage Process Structure de SPEM 2.0 était motivée par le fait que nous avons cherché à focaliser notre attention d’abord sur les concepts permettant de décrire les aspects structurels et comportementaux d’un processus MDE sans se soucier de la réutilisation. Cependant, l’architecture que nous avons proposée permet d’intégrer facilement les autres paquetages de SPEM dans le métamodèle SPEM4MDE. En effet, il suffit de créer dans SPEM4MDE : un paquetage MDEMethodContent qui étendra le paquetage SPEM::MethodContent en y intégrant les définitions de transformations ; un paquetage MDEProcessWithMDEMethods qui étend les paquetages SPEM:ProcessWithMethods et MDEMethodContent afin de réutiliser les transformations définies dans MDEMethodContent et les lier selon un ordre d’exécution ; et enfin un paquetage MDEMehtodPlugin qui étend SPEM::MethodPlugin et MDEProcessWithMDEMethods afin de réutiliser les concepts des plug-in introduits de SPEM.

Une deuxième limitation de notre approche réside dans le fait qu’elle ne prend pas en compte les aspects collaboratifs des processus de développement logiciel. Ces aspects soulèvent de nombreuses questions, loin d’être triviales, par exemple : comment assurer la coordination des développeurs qui travaillent sur un même artéfact ? Comment modéliser les scénarii de collaboration ? Quel scénario de collaboration faut-il appliquer dans telle ou telle situation ? D’autre part, si la gestion de la cohérence des versions est relativement maîtrisé dans le cadre artéfacts textuels (documents, codes sources), il n’en est pas de même pour les modèles du fait de leur caractère non arborescent qui peut conduire à de multiples dépendances dans le cas de modèles de grande taille notamment. Comment pourrait-on alors adapter les techniques classiques de gestion des versions dans le cadre d’un développement collaboratif IDM ?

Deux autres limitations du travail réalisé dans cette thèse relèvent de l’implémentation. Tout d’abord, dans sa version actuelle, le prototype SPEM4MDE-PSEE que nous avons développé contient à la fois le module d’édition de modèles de processus SPEM4MDE Process Editor et le module de mise en œuvre SPEM4MDE Process Enactment Engine. Par conséquent, c’est dans le même environnement que le concepteur de processus (Process Designer) décrit un modèle processus IDM, le chef de projet adapte ce modèle et le développeur procède à sa mise en œuvre. Cependant, comme présenté dans l’architecture du prototype SPEM4MDE-PSEE, l’idéal serait de décrire un processus IDM avec le module « SPEM4MDE Process Editor », puis de le packager et de le sauvegarder dans le «MDE Process Repository ». Par la suite un chef de projet pourra sélectionner un modèle de processus dans ce « repository », procéder à son adaptation pour un projet spécifique puis lancer sa mise en œuvre. L’autre limitation réside dans le fait que le prototype n’offre actuellement qu’une version mono-développeur. Il nécessite d’être étendu à une version multi-développeur basée sur une architecture client-serveur.

Enfin, une autre perspective d’extension serait d’offrir un environnement de mise œuvre intégrant la traçabilité, aussi bien des transformations de modèles que de la mise en œuvre des processus. La traçabilité des transformations permettrait de garder les traces d’exécution de chaque règle d’une transformation, de vérifier si une règle a été déjà exécutée ou non, de déboguer une transformation et ses modèles associés et enfin de synchroniser les modèles source et cible d’une transformation. La traçabilité de la mise en œuvre des processus permettrait, quant à elle, d’intégrer différentes techniques de l’ingénierie des processus telles que l’évaluation (Process Assesment), l’amélioration (Process Improvement), la gestion des risques (Risk management), le pilotage et l’aide à la décision au cours du développement (Process Descision Support), etc.