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

3.1.2 Cartographie d'application

Dans le cadre de la cartographie applicative, on peut trouver plusieurs objectifs : avoir une vision de haut niveau de ses applications, ou au contraire, avoir une connaissance très fine de celles-ci en descendant jusqu'aux lignes de codes qui les composent. Le groupe de travail modernisation d'architecture dirigée par les modèles (Architecture-Driven Modernization task force, ADM⁶) a défini plusieurs métamodèles pour répondre à ces besoins, les deux principaux sont le métamodèle de découverte de la connaissance (Knowledge Discovery Metamodel, KDM⁷) et le métamodèle d'arbre syntaxique abstrait (Abstract Syntax Tree Metamodel, ASTM⁸).

KDM permet d'obtenir une vision à gros grain des composants des applications, comme les classes, écrans ou les données, mais ne descend pas en-dessous des méthodes. ASTM quant à lui, offre une vision à grain fin de l'application et permet de représenter l'ensemble de l'algorithmie des programmes. ASTM est prévu pour être un complément de KDM afin d'avoir une vision d'ensemble de son parc applicatif.

On retrouve ces deux niveaux de représentation dans les métamodèles de Sodifrance. ASTM correspond à nos métamodèles spécifiques à chaque langage source et au métamodèle ANT. Ils permettent de modéliser cent pour cent de l'application source. A contrario, le métamodèle de cartographie est du niveau de KDM et se borne à modéliser les éléments importants (classes, écrans, fonctions, etc.) ainsi que les relations qui les unissent. D'ailleurs, notre métamodèle de cartographie s'inspire fortement de KDM (nommage, classe de base), mais nous n'avons pas suivi l'ensemble des recommandations de l'ADM. Nous avions des besoins d'extension de la cartographie pour prendre en compte des sujets divers comme les tests ou le suivi d'intégration (cf. Figure 15). Toutefois, cela n'a pas été un critère de choix décisif, car MM. Dehlen et al. (Dehlen et al. 2008) démontrent que l'on peut aussi étendre KDM selon ses besoins.

⁶ ADM : Architecture Driven Modernization (Object Management Group 2011a)

⁷ KDM : Knowledge Discovery Metamodel, (Object Management Group 2010)

⁸ ASTM : Abstract Syntax Tree Metamodel (Object Management Group 2011b)

Figure 10 : Diagramme de classe extrait du métamodèle KDM
(Object Management Group 2010, p.69)

Figure 11 : Diagramme de classe extrait du métamodèle « Migration Platform »
(source Sodifrance, partie du métamodèle « Migration Platform »)

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

En réalité, les critères principaux qui ont orienté le choix de définir un métamodèle propriétaire sont d'ordre un peu plus pratique :

· La simplification du métamodèle. Nous n'avons utilisé que ce qui nous servait réellement. Par exemple, les informations concernant la compilation ne sont pas présentes dans notre métamodèle. On remarque bien les similitudes entre les Figure 10 et Figure 11, mais effectivement, la classe « CompilationUnit » ou sa sous-classe « SharedUnit » ne sont pas présentes dans notre métamodèle.

· Nous n'avons pas réussi à obtenir une manière fiable d'enregistrer nos modèles, parfois très volumineux (maquettes réalisées avec CDO⁹ non concluantes). Donc nous avons opté pour le stockage des informations dans une base de données relationnelle accessible par le biais de l'ORM¹⁰ Hibernate¹¹. Du fait de cette simplification du métamodèle et de la stratégie de persistance appliquée (une table par classe), les jointures sont elles aussi plus simples, et surtout avec un nombre d'auto-jointures limité.

· Le résultat de la cartographie doit être disponible le plus simplement possible pour le reste de la chaîne d'évolution d'architecture. Dans notre cas, une archive Java (Jar) incluant l'ensemble de la couche DAO Hibernate est mise à disposition des outils. Cela répond tout à fait à ce besoin.

· Enfin, nous sommes très libres dans nos choix concernant l'évolution du métamodèle. Un inconvénient est que l'on s'isole des standards et du reste de la communauté. Mais en contrepartie, cela nous permet de protéger un certain savoir-faire.

⁹ CDO : Connected Data Objects (Eclipse project CDO 2011)

¹⁰ ORM : Object-relational mapping (Crucianu s. d., p.173)

¹¹ Hibernate : cadre de développement libre pour la correspondance objet-relationnel (Crucianu s. d., p.173)

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

Figure 12 : Le modèle en V (Mirman 2011)

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