Projet IDM 2016/17 : langage de description d'activités

Le but de ce projet est d'étendre le langage de description d'activités (LDP) du TP1 pour rajouter des signatures de méthodes dans les activités et ensuite exécuter la séquence d'activités avec appel des méthodes. En complément, il vous est demandé de définir une syntaxe concrète en XText pour votre langage étendu ainsi qu'une transformation de modèle vers un langage de description d'activités avec parallélisme.

Rappel du méta-modèle LDP

Un processus est formé d'une séquence ordonnée d'activités, avec un début et une fin. La figure ci-dessous représente le méta-modèle de LDP. Il contient un méta-élément Processus qui permet de définir les éléments du processus, à savoir sa liste d'activités et ses deux pseudo-états de Debut et Fin (la méta-classe PseudoEtat étant abstraite), chaque pseudo état référençant une activité (soit l'activité de début, soit la dernière du processus). Une Activite, à l'exception bien sur de la dernière du processus, possède une activité suivante, ce qui permet de définir la séquence d'activités du processus. De même, une activité, sauf la première, possède une activité précédente. Si l'on est en train d'exécuter ce processus, activiteCourante référence, parmi les activités du processus, l'activité en cours du processus, sinon, elle n'est pas positionnée.





Extension du méta-modèle

Le but de l'extension du méta-modèle est de pouvoir rajouter une signature de méthode à une activité. Ensuite, pendant l'exécution du processus, quand on entrera dans une activité, on exécutera cette méthode sur un objet métier Java via les mécanismes de réflexion Java.

Les méthodes ont bien entendu des paramètres et renvoient des valeurs. Le problème est d'être capable de gérer le flux de données entre les méthodes, par exemple de dire que le résultat renvoyé par une activité doit être un des paramètres de la méthode d'une activité à venir. Pour cela, on pourra appliquer un tag à une valeur de sortie ou un paramètre de méthode. Les tags de même nom correspondront à la même valeur et permettront ainsi de créer un flux de données.

A titre d'exemple, voici une séquence de calculs via une syntaxe textuelle (les noms des paramètres des méthodes ne sont pas précisés car ils ne sont pas utiles ni déterminants) :

process {
   
   fact {
      label "factorielle"
      call {resFact} int factorial({n} int) // la signature taggée de l'opération
   }
   
   sqrt {
      label "racine carrée"
      call {resSqrt} int sqrt({resFact} int)
   } next of fact
   
   pow {
      label "puissance"
      call {resPower} int power({resSqrt} int, {puiss} int)
   } next of sqrt
   
   div {
      label "division"
      call {resDiv} int divide({resPower} int, {x} int)
   } next of pow
   
   start with fact
   end with div
}

Cette séquence fait le calcul suivant : ( n ! ) puiss x

Exécution d'un processus

Comme on peut le voir dans la séquence de calcul présentée ci-dessus, certains tags ne sont pas des résultats de calculs précédents. Il s'agit de paramètres du calcul qui sont précisés au lancement de l'exécution du processus. De manière plus générale, le moteur d'exécution prendra en paramètre trois choses :

  1. Le modèle du processus à exécuter (nom de fichier XMI)
  2. Un objet Java sur lequel les méthodes seront appelées
  3. Une map associant un tag et un objet permettant à la fois de préciser les paramètres du calcul et de récupérer les valeurs calculées

Voici par exemple du code Java qui lance la séquence de calcul précédente en supposant qu'elle stockée dans un modèle nommée "Calcul.xmi" et que les méthodes sont implémentées par un objet de classe Calcul :

...
HashMap<String, Object> tags = new HashMap<String, Object>();
tags.put("n",6);
tags.put("puiss",3);
tags.put("x", 100);
Calcul calc = new Calcul();
engine.execute("models/Calcul.xmi", calc, tags);
System.out.println("Le résultat du calcul est : "+tags.get("resDiv"));
...

Contraintes de fonctionnement du moteur d'exécution :

Parallélisation de processus





La figure ci-dessus représente le méta-modèle définissant le langage de description de processus (LDP) parallèles. Un processus est constitué d'un ensemble d'éléments de processus, agencés de manière linéaire, sans boucles. Un élément de processus est soit un pseudo-état, soit une porte ou soit une séquence. Une séquence est une suite ordonnée d'activités, précisant sa première activité puis chaque activité précisant sa suivante et/ou précédente. Il existe deux types de pseudo-états : un début et une fin, référençant respectivement l'élément débutant et terminant le processus. Une porte permet de relier plusieurs éléments de processus (typiquement des séquences) : une fourche fait passer d'un élément (un prédécesseur) vers plusieurs éléments (successeurs). Symétriquement, une jonction est passée lorsque les successeurs sont terminés et on passe alors au successeur de la jonction. La figure ci-dessous montre un exemple de processus conforme à ce méta-modèle (et utilisant une syntaxe graphique dédiée).





Il est possible de parallèliser un processus purement séquentiel, dit autrement de transformer un modèle conforme au langage LDP en un modèle conforme au langage LDP parallèle. Pour cela, il faut respecter les contraintes d'ordre et de dépendances des tags des méthodes. Si deux méthodes n'ont pas de dépendances d'ordre, on pourra les exécuter en parallèle.

La transformation que vous implémenterez respectera ces dépendances pour paralléliser une séquence. Par soucis de simplification, lors de la transformation, les signatures de méthodes avec tags ne seront pas conservées dans le modèle cible (évitant d'aller modifier le méta-modèle de LDP parallèle).

Travail attendu

Quatre éléments sont attendus dans le projet :

  1. L'extension du méta-modèle LDP pour intégrer la définition des signature de méthodes avec les tags.
  2. La définition d'une syntaxe concrète et d'un plugin XText en respectant l'exemple présenté ci-dessus.
  3. L'implémentation du moteur générique d'exécution en respectant les contraintes présentées ci-dessus.
  4. La transformation de modèles de parallèlisation de séquence que vous implémenterez au choix en ATL ou Kermeta.

Vous enverrez par mail, pour le XXXX, votre projet Eclipse ainsi qu'un rapport de quelques pages décrivant notamment l'extension du méta-modèle et d'autres informations sur vos implémentations.

NOTE SUR XTEXT

Sachez que dans l'instance d'Eclipse faisant tourner votre plugin, tout fichier .ldp peut être pris en entrée d'une transformation au même titre qu'un fichier XMI. Pour preuve, il est possible de demander à le visualiser via l'éditeur arborescent (clic droit sur le fichier > Open With > Other > Sample Ecore Model Editor). Ce point de vue équivalent vous permet :

  1. de vérifier facilement quelles instances ont été créées et les valeurs de leurs propriétés (si besoin Menu Windows > Show View > Other > General > Properties)
  2. de le sérialiser en tant que fichier d'extension XMI (Menu File > Save as). Cette copie peut être modifiée, déplacée où bon vous semble (même en dehors de cette instance d'Eclipse), transformée, etc.

Ressources du projet