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(6)) 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(7)) et le métamodèle
d’arbre syntaxique abstrait (Abstract Syntax Tree Metamodel, ASTM(8)).
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.
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 »)
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(9) 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(10) Hibernate(11). 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.
Figure 12 : Le modèle en V (Mirman 2011)
6 ADM : Architecture Driven Modernization (Object Management Group 2011a)
7 KDM : Knowledge Discovery Metamodel, (Object Management Group 2010)
8 ASTM : Abstract Syntax Tree Metamodel (Object Management Group 2011b)
9 CDO : Connected Data Objects (Eclipse project CDO 2011)
10 ORM : Object-relational mapping (Crucianu s. d., p.173)
11 Hibernate : cadre de développement libre pour la correspondance objet-relationnel (Crucianu s. d., p.173)
Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance