Réutilisation

La réutilisation a été depuis le début de nos travaux de recherche, le critère le plus important et le plus recherché. Ce critère nous a motivé à rechercher des méthodes qui permettent une meilleure réutilisation de modèles de spécification. Pour cette raison, nous avons choisi d’introduire une approche de métamodélisation à base de composants pour spécifier les éditeurs graphiques. L’approche basée sur les composants assure une meilleure lisibilité et une meilleure maintenance de modèles. Elle est particulièrement utile pour le travail d’équipe et permet l’industrialisation du développement de ce type d’application. La réutilisation d’un composant permet d’économiser un gain important de productivité, car il permet de réduire le temps de développement, d’autant plus que le composant est réutilisé plus souvent.

Outre la séparation des préoccupations, la réutilisation est effectuée dans notre proposition à travers des concepts inspirés de l’orienté-objet. L’utilisation d’interfaçage (pour le couplage faible entre préoccupations), la composition et l’encapsulation entre les composants et l’utilisation de notre mécanisme d’héritage nous ont permis de composer des éléments graphiques, réutilisables dans plusieurs diagrammes : les composants qui héritent d’autres, réutilisent toutes les propriétés héritées et peuvent redéfinir tout ou une partie de la description.

réutilisation des notations visuelles d’UML avec MID. Le tableau8.1présente les dia- grammes spécifiés avec MID, le nombre de notations visuelles dans chaque diagramme et le taux de réutilisation de ces notations.

TABLE8.1: Taux de réutilisation de la notation UML

Diagramme Nombre de notations Nombre de notations réutilisés Taux de réutilisation Classes 33 18 54,5% Composants 15 8 53,3% Structure Composite 16 14 87,5% Déploiement 11 8 72,7% Package 9 9 100% États-transitions 16 7 43,7% Activités 16 12 75% Cas d’utilisation 17 14 82,3% Séquences 16 5 31,2% Communication 5 4 80% Interaction globale 20 20 100%

Taux global de réutilisation 71 %

A travers les exemples présentés dans ce chapitre, nous avons validé notre approche en termes de réutilisabilité : Cette approche nous a permis de réutiliser plus de 70 % des composants créés dans l’ensemble de la syntaxe concrète du langage UML, ce qui n’est pas négligeable en termes de coût de développement et de temps. Cette approche nous a permis de définir plus facilement les spécificités des éditeurs avec une approche dirigée par les modèles et sans qu’il soit nécessaire d’intervenir manuellement (programmati- quement) pour effectuer des changements, ce qui augmente le niveau de maintenabilité des éditeurs générées avec notre solution.

Par ailleurs, nous avons évalué le taux de réutilisation des autres outils et nous avons constaté que notre proposition offre un taux de réutilisation largement supérieur à celui des autres outils. Le tableau8.2montre les taux de réutilisation des outils existants. Le détail de cette évaluation est dans l’annexe.

TABLE8.2: Comparatif des taux de réutilisation

Outil Taux de

réutilisation

MetaEdit+ 46,9 %

GMF 52,3 %

Spary 64 %

MID 71 %

D’autres critères comme l’expressivité graphique de notre solution et son indépen- dance des technologies d’implémentation font l’objet d’une deuxième validation dans le chapitre9.

C

9

MID au-delà de UML

Sommaire

9.1 Chaîne de transformation MID − > Spray. . . 128 9.2 Diagramme BPMN . . . 128 9.3 Schémas électriques . . . 131 9.4 Synthèse et discussion . . . 134

Dans ce chapitre, nous effectuons une deuxième validation de notre proposition. Cette validation a trois objectifs : le premier est de montrer que notre solution est valable au-delà de la spécification de la syntaxe concrète du langage UML, démontrant ainsi l’ouverture de notre proposition à d’autres domaines d’application. Le deuxième est de montrer notre indépendance à la technologie d’implémentation (technologie cible) et montrer ainsi que notre proposition a un niveau d’abstraction plus élevé que les autres technologies. Le troisième objectif, sert à montrer que les possibilités de spécification offertes par notre proposition, sont largement plus grandes que celles proposées par les autres technologies (GMF, Spray, etc.) puisqu’avec les mêmes concepts au niveau de nos métamodèles, les technologies cibles n’arrivent pas à suivre la description et de la traduire en code opérationnel. Il nous a fallu, pour spécifier les schémas électriques par exemple, de changer la technologie cible (de GMF vers Spray), à cause des limitations rencontrées dans GMF. Le problème est réciproque pour Spray, puisqu’il ne peut pas suivre la description de MID et de générer des éditeurs pour UML (chapitre8). Ceci est expliqué par le fait que lors de la conception de notre proposition, nous avons été plus généralistes en récupérant les avantages des autres solutions et en essayant de résoudre leurs limitations.

Nous validons aussi le critère de l’expressivité graphique de notre proposition en spécifiant des langages visuels complexes comme des éditeurs de schémas électroniques ou d’autres diagrammes comme celui des workflow de BPMN et en ciblant cette fois, le framwork Spray pour la génération des éditeurs graphiques de ces langages.

Dans la première partie, nous allons présenter notre chaine de transformation de MID vers Spray. Par la suite, nous spécifions deux langages visuels : dans un premier temps, nous spécifions le diagramme de workflow de BPMN avec MID et nous montrons les modèles Spray générés ainsi que l’éditeur graphique produit à partir de cette spécification. Finalement, nous spécifions un éditeur de schémas électroniques et nous montrons son éditeur généré avec MID.

9.1 Chaîne de transformation MID − > Spray

Nous avons développé une chaîne de transformation pour générer le code java pour les éditeurs de diagramme, en ciblant le Framework Spray. A partir d’une description MID nous pouvons générer les modèles Spray Core, Shape et Style. Ces modèles permettent de générer 100% du code opérationnel des éditeurs de diagrammes. Le développeur n’a plus qu’à exécuter l’application. L’éditeur généré permet de manipuler des concepts spécifiques au domaine avec des représentations graphiques, spécifiées au niveau du modèle.

FIGURE9.1 – Chaîne de transformation MID − > Spray

Après spécification des modèles MID, une première transformation permet de faire les associations graphiques et sémantiques nécessaires, applique les règles d’héritage et récupère les éléments réutilisés. Le modèle intermédiaire généré permet de cibler la technologie cible (dans ce cas Spray) et par la suite génère à partir d’une transformation de modèle vers texte les trois modèles spray (core, shape et style). Ces derniers modèles permettent une dernière transformation cette fois vers du code java complètement opérationnel.