ADM : Le MDA à l'envers

Architecture Driven Modernization

ADM : LE MDA A L’ENVERS ?

Par Christophe Addinquy Par ADM, comprenez : Architecture Driven Modernization. Il s’agit d’une nouvelle initiative de l’OMG1 destinée à la représentation standard du reverse engineering d’applications. La parenté entre les sigles MDA et ADM n’est bien sur pas un hasard ! L’objectif est bien ici de reprendre les « legacy applications » développées hors modélisation afin de les représentées selon un méta-modèle standard : le KDM, pour Knowledge Discovery Meta-model.

Les objectifs d’ADM sont :  L’évolution du logiciel  L’interopérabilité  Le refactoring et la restructuration  Réutilisation, portage et migration  Traductions dans d’autres langages  EAI et architectures SOA La pierre angulaire de cet édifice est la définition du méta-modèle KDM. Il doit centraliser les métadonnées concernant les applications, leur environnement et leur déploiement selon une vue physique et une vue logique. Bien sûr, afin de s’intégrer à la plateforme MDA, ce métamodèle devra s’appuyer sur le MOF 2.0 et utiliser XMI 2.0 comme format d’échanges.

Le méta-modèle KDM initial permettra de représenter les éléments structurant des applications. Pour descendre au niveau du code, il faudra attendre l’extension ADM-AST (Abstract Syntax Tree) qui représentera celui-ci sous une forme relativement indépendante du langage d’implémentation.

L’étape suivante sera le « package analysis » devant permettre de dériver des métainformations comportementales à partir des métadonnées structurelles de KDM.

1

Voir http://www.omg.org/adm ;

1

Architecture Driven Modernization Viendra ensuite le « metric package » dont le but sera de dériver des attributs du système depuis les informations précédentes. Nous parlons ici de métriques d’architecture, mais également d’impacts, d ‘estimations et de ROI. Le package « visualisation » qui viendra soutenir la sémantique précédemment établie n’est pas aujourd’hui un élément bien défini, mais il devra comprendre les représentations de planning et de gestion nécessaire aux initiatives de modernisation citées précédemment.

Le package « refactoring » permettra les opérations de manipulation et restructuration.

Enfin, le package « Target mapping & Transformation » est l’élément liant entre les briques ADM et MDA. ADM est une entreprise ambitieuse, car elle va bien plus loin que les outils de reverse engineering disponibles en adjonction des AGL classiques. En un sens, elle bénéficie du retour d’expérience de l’an 2000 et des outils d’analyse et de constitution de métadonnées à partir du code ! Lorsque KDM verra le jour, on pourra alors espérer l’arrivée d’outils inter opérant autour de référentiels standardisés. N’oublions pas toutefois, si l’on considère MDA, que c’est bien sur ce point où le bât blesse, aussi bien en terme de maturité que d’interopérabilité de ces outils !

Quoi qu’il en soit, la reprise d’applications existantes sous un référentiel standard est une brique qui est d’autant plus manquante qu’elle adresse un champ d’applications bien plus vaste que celui des nouveaux projets.

2