Stratégie de test au sein du processus d'évolution d'architecture de Sodifrance

7.6 Du métamodèle au Jar

Dans le cadre de notre partenariat avec la société Kalios, j'ai dû trouver une solution pour produire un ensemble cohérent de fichiers à partir d'un fichier de configuration XML ressemblant à ceci :

<?xml version="1.0" encoding="iso-8859-1"?>

<env_file xmlns=" http://www.kalios.com/synopsis/import"> <objecttypes>

<objecttype ref="#TCVBBTN">

<label>Button</label>

<flag_typeobjet_default>0</flag_typeobjet_default> <type_field>WndClass</type_field>

<types_robots>

<type id="0">ThunderCommandButton</type> <type id="1">VB.VB.CommandButton</type>

</types_robots>

<actions>

<action ref="#TCVBBTNCLK">

<description>Click</description>

<help_param>Click on the button</help_param> <label>Click</label>

<parametrable>0</parametrable>

<script>VBButton_doClick</script>

</action>

...

</actions>

</objecttype>

...

</objecttypes>

</env_file>

Etant donné le nombre conséquent de fichiers à générer, j'ai opté pour l'utilisation de l'approche MDA conjointe avec les outils MIA. Il me fallait donc un métamodèle capable de représenter le contenu de ce fichier de configuration. La création et l'alimentation du modèle correspondant au métamodèle s'est faite par le biais d'une transformation avec MIA Transformation. La génération quant à elle, a été laissée aux bons soins de MIA Generation.

Jusqu'ici, pas de problème de majeur, encore fallait-il réussir à passer du diagramme de classes représentant le métamodèle à quelque chose d'interprétable par les outils MIA. Les outils disponibles avec « Eclipse Modeling Framwork » (EMF³⁴) m'ont permis de résoudre ce problème. En effet, j'ai créé un projet de type « EMF Project » vide. Ensuite j'ai ajouté un diagramme Ecore et grâce au plugin « Eclipse Modeling Tool », j'ai pu me servir du modeleur UML directement dans Eclipse (cf. Figure 53). Ecore, le métamétamodèle proposé par EMF est compatible avec le métamétamodèle de l'OMG, le MOF 2.0 (Object Management Group 2006)(Bézivin et al. 2004). Le modèle Ecore et le diagramme de classe qui le représente (fichier avec extension « ecorediag ») restent synchronisés à chaque sauvegarde de l'un d'entre eux.

³⁴ EMF : http://eclipse.org/modeling/emf/

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

L'étape suivante consiste à utiliser le générateur de modèle d'EMF. On déclare donc un nouvel « EMF Generator Model ». Il aura pour rôle de générer les classes java d'implémentation du modèle à partir du modèle Ecore. Une fois ces classes générées, il reste à exporter le projet en « Deployable plug-ins and fragments » dans le répertoire « plugin » des outils MIA.

A l'issue de cette action, MIA Transformation et MIA Generation sont à même d'ouvrir, de manipuler et de sauvegarder des modèles conformes au métamodèle définit par le diagramme de classes (cf. Figure 54).

Figure 54 : sélection du métamodèle avec les outils MIA

Voici par exemple un modèle chargé dans MIA Generation (cf. Figure 54) correspondant au fichier de configuration XML initial.

Figure 55 : exemple de modèle chargé dans MIA Generation

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

La figure qui suit illustre l'utilisation de MIA Generation qui permet dans le cas présent de générer du texte à chaque occurrence d'objet « Link » du modèle.

Figure 56 : exemple de génération dans MIA Generation

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur
CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

Stratégie de test au sein du processus d'évolution
d'architecture de Sodifrance