Un premier langage exploratoire : le langage GooMod

Sur la base des propriétés que nous avons identifiées, un premier langage de niveau PIM, nommé GooMod, a été proposé. Il sera présenté à la conférence internationale QSIC‟2010.

Ce langage est encore loin de satisfaire tous les besoins évoqués dans la section précédente. En particulier, il n‟intègre pas les concepts nécessaires à la représentation des domaines de définition. Il ne permet pas non plus l‟expression explicite de domaines de variation. Ces deux points sont pour le moment fixés par l‟unique implantation PSM existante qui tient donc lieu de référence. Le langage sera donc amené à évoluer dans les mois qui viennent. Il permet cependant d‟explorer l‟espace des solutions et de tester l‟impact de certains choix sur le plan méthodologique et technologique. La syntaxe abstraite de ce langage à la date de rédaction de ce mémoire (Avril 2010) est présentée dans la Figure 6-3 sous la forme d‟un modèle MOF.

Dans ce langage, le procédé associé à une BPM est décrit syntaxiquement sous la forme d‟un graphe orienté faiblement connexe. Un sommet du graphe (Step) représente une activité de modélisation cohérente que nous appelons une « étape ». Les arcs (Bind) lient des paires de sommets. Les boucles (arcs dont la tête et la queue coïncident) sont autorisées, mais pas les multi-arcs (arcs ayant la même queue et la même tête). Les graphes intègrent la séquence, l‟itération, la notion d‟étape optionnelle et implicitement de point de décision automatique ou non. Le point 4, identifié dans la sous-section précédente, est ainsi satisfait. Sémantiquement, sur l‟aspect procédé, le langage GooMod est assez proche du diagramme d‟activités UML sans les concepts relatifs au parallélisme (nœuds de bifurcation et d‟union).

Figure 6-3 La syntaxe abstraite du langage GooMod

Pour répondre au point 1, nous proposons de définir les procédés associés aux BPM en usant de deux types d‟étape : les étapes libres et les étapes semi-automatiques.

Dans une étape libre, le développeur est seul à modifier le modèle mais son activité est cependant contrainte. Cette étape comporte trois phases :

dans la première phase, une condition d‟entrée sur le modèle détermine si on peut rentrer dans l‟étape (pré-condition) ; le lancement de l‟évaluation de cette condition est automatique dès que l‟étape est atteignable ; Si l‟évaluation est positive et que cette étape est la seule atteignable, on passe dans la seconde phase (point de décision automatique) ; si plusieurs étapes sont atteignables et présentent des pré-conditions positives, le développeur doit indiquer l‟étape qu‟il souhaite emprunter (point de décision non automatique) ;

dans la seconde, le développeur modifie le modèle comme il l‟entend mais en utilisant uniquement les concepts du langage qui ont été autorisés lors du déroulement de cette étape ;

dans la troisième phase, le développeur demande l‟évaluation d‟une condition de sortie sur le modèle (post-condition) ; cette condition détermine si le développeur peut sortir ou non de l‟étape. Si elle n‟est pas vérifiée, on retourne dans la deuxième phase, sinon on lance l‟évaluation des pré-conditions des étapes successeurs.

Dans la version actuelle du langage, les pré et post-conditions prennent la forme de contraintes OCL évaluées sur la syntaxe abstraite du modèle. C‟est une réponse au point 3. Le choix d‟OCL est temporaire. L‟expérience acquise avec la description de motifs architecturaux a clairement montré qu‟un tel langage, efficace pour certaines propriétés, se révélait insupportable pour d‟autres. Cependant, dans une phase exploratoire, il permet la réutilisation d‟outils de compilation et d‟évaluation et limite ainsi les efforts de développement.

En réponse au point 2, il est possible de préciser les concepts utilisables dans une étape. Ces concepts sont un sous-ensemble des métaclasses non abstraites du métamodèle du langage ciblé par la BPM. Leur manipulation peut être réduite au cas par cas à un sous-ensemble de : création, modification, destruction, lecture.

Une étape semi-automatique se compose, elle aussi, de trois phases dont une est optionnelle (la deuxième). La première phase est identique à celle d‟une étape libre. Elle correspond à l‟évaluation d‟une pré-condition. Les deux phases suivantes sont :

deuxième phase (optionnelle) : le développeur doit renseigner de manière ordonnée une liste de variables ;

troisième phase : une séquence d‟actions entièrement prises en charge par l‟outil est réalisée : ajout, retrait, modification d‟éléments du modèle, calcul et affichage d‟une valeur. Une fois ces actions réalisées, les pré-conditions des étapes successeurs sont évaluées.

Nous explorons trois approches complémentaires pour exprimer les deux phases précédentes :

une description sous la forme d‟une transformation de graphes avec une partie gauche incluant éventuellement des éléments indéterminés (ce sont les variables qui devront être renseignées par le développeur lors de la deuxième phase) et une partie droite qui décrit (classiquement) les modifications à réaliser ;

un ensemble ordonné (éventuellement vide) de saisies de valeurs dans des variables, suivi d‟un ensemble ordonné d‟actions élémentaires MOF (ajout d‟un élément, suppression, etc.) ;

un ensemble ordonné (éventuellement vide) de saisies de valeurs dans des variables, suivi de l‟évaluation d‟une fonction OCL sur le modèle usant de ces variables, puis l‟affichage de la valeur de cette fonction.

Ces trois approches correspondent à trois types d‟étapes semi-automatiques. La première correspond à une substitution de motif multi-occurrences (partout ou il apparaît), la deuxième à une substitution de motif mono-occurrence, la troisième au calcul d‟une métrique ou à la vérification du respect d‟un style.

Une étape libre est interruptible sur la demande du développeur pour lancer une autre BPM (libre ou semi-automatique) sous réserve que la pré-condition de la BPM appelée soit satisfaite. A l‟instar d‟un appel de procédure, le contexte de la BPM appelante est sauvegardé. Il sera rétabli une fois terminée la BPM appelée. Les étapes semi-automatiques ne sont pas interruptibles.