Aller au contenu. | Aller à la navigation

Outils personnels

Navigation

Vous êtes ici : Accueil / Articles / TranS (Transformations Strategy)

TranS (Transformations Strategy)

Par Amen Souissi publié 08/08/2011 19:50, Dernière modification 23/09/2011 11:04
L'outil TranS permettra la modélisation des stratégies des transformations, sous forme de processus de transformation. On ne parle plus de chaîne de transformations, mais de stratégie de transformations. Cet outil permettra aussi l’exécution de la stratégie en s’appuyant sur un moteur d’exécution écrit en QVT. Il permettra la vérification des entrées sorties pour garder la cohérence entre les transformations.

Les outils actuels proposent un moteur de chaîne de transformations classique permettant l’exécution enchaînée des transformations dans le but de générer le code. On peut classifier cette approche comme "primitive". En effet, cette approche propose un enchaînement bête et simple des transformations et elle ne ce soucie pas de la stratégie de transformations (stratégie de développement) elle même.

J'ai toujours considéré l'IDM comme faisant partie du domaine de l’intelligence artificielle où une transformation présente une action dans le projet de développement. Sauf que dans un projet bien réfléchi les actions suivent une certaine stratégie de développement qui consiste à choisir la bonne action au bon moment selon les paramètres d'entrées et de sorties de l'action (dans notre cas ces paramètres peuvent être des modèles).

Dans un projet une action attend toutes ses entrées avant de s’exécuter, par conséquent une action possède plusieurs flux d'entrées et de sorties .

Un diagramme de stratégie des transformations ne peut être comparable au diagramme d'activité d'UML ou aux autres diagrammes décrivant les processus logiciel ou métier. En effet, les connexions se font entre les paramètres des transformations et les données de la stratégie qui peuvent être des modèles ou des données primitives (de même pour les paramètres des transformations). Dans ce cas seulement les flux de données sont décrits permettant ainsi une description implicite du flux de contrôle. En effet dans une stratégie de transformations, les branches ne peuvent pas être en concurrence. Un "Join", donc, ne recevra qu'une seule donnée, les restes ne sont pas valides. Par conséquent le flux de contrôle n'est pas utile et peut présenter une information de trop. Dans notre diagramme on peut avoir des points de décision qui vont permettre d'orienter le flux de données. On fera aussi la différence entre les données de configuration au niveau du modèle de la stratégie et les données de configuration au niveau de son exécution. Ce qui la rend interactive.

Le Diagramme suivant présente un exemple de stratégie de transformations. Dans cet exemple le modèle d'entrée décrit les processus métier de l'entreprise. D'une manière générale, les actions d'un processus agissent sur un ensemble de documents de l'entreprise. Dans certains cas, les actions d'un processus n'agissent que sur un seul document, dans ce cas leur implémentation doit être différente pour pouvoir l'optimiser.  Pour notre exemple si tous les processus sont du deuxième type alors on applique la transformation P->SimpleProcess sinon on applique la transformation P->ComplexProcess. Ensuite on passe à la génération de code.

 

Strategy process

On aurait pu fusionner les deux transformations dans une seule en faisant le test dans la transformation. Je peux aller même jusqu'à dire qu'on aurait pu fusionner toutes les transformations de la stratégie en une seule, mais cela serait contraire aux bonnes pratiques. La ou les transformations deviennent encombrées, difficiles à maintenir et on élimine la possibilité de réutiliser les transformations puisque l'objectif naturel d'utiliser une chaîne ou une stratégie de transformation est la réutilisation des transformations. Une stratégie permet , en effet, de maximiser cette réutilisation en évitant de faire les testes métier dans les transformations. La stratégie devient dans ce cas plus compréhensible et peut proposer une vision globale du cheminement d'idées du modèle jusqu'à la génération de code. Une bonne pratique, donc, peut être la mise en place de la stratégie des transformations avant d’écrire les transformations.

En substituant les transformations par des composants, on obtient une stratégie d'implémentation d'une fonctionnalité. Dans le cadre de MACoP au lieu d'utiliser un simple diagramme de composants à l'UML on utilisera un diagramme de stratégie pour l'implémentation des actions. Cela va nous permettre de décrire les formulaires à structure dynamique avec des dépendances entre les champs.

 

Le moteur d’exécution sera écrit en QVT. Dans cette transformation, on fera l'ordonnancement des transformations selon le flux des données, on calculera les guards sur les flux et on exécutera les transformations avec les bons paramètres d'entrées. Une description plus détaillée sera dans des articles  à venir. 

 

Bibliographie

Nguyen Viet Hoa, 2009, Automatisation de l’enchaînement des tâches exécutées sur des modèles.

Samba Diaw, Rédouane Lbath, Bernard Coulette, 2010, Etat de l’art sur le développement logiciel basé sur les transformations de modèles

Samba Diaw, Rédouane Lbath, Bernard Coulette, Etat de l’art sur le développement logiciel dirigé par les modèles.

Acceleo Chaine