Afin de définir la phase de migration industrielle, il convient d’approfondir quelques notions.
Commençons par l’architecture dirigée par les modèles (Model Driven Architecture, MDA). Selon
M. Villemin (Villemin 2011) « L’initiative d’architecture dirigée par les modèles de l’OMG(3) “Model
Driven Architecture” (MDA) est motivée par le besoin de réduire les tâches de reconception des
applications (nécessitées, entre autre, par l’évolution constante des technologies informatiques) ».
Le MDA, qui est une démarche de développement, répond tout à fait à ce besoin, car il permet « la
séparation des spécifications fonctionnelles des spécifications d’implantations sur une plate-forme
donnée » (Villemin 2011). Cette séparation s’effectue avec l’utilisation de modèles différents
décrivant :
· un modèle des exigences (CIM : Computational Independent Model)
· un modèle de traitements orientés métier (PIM : Platform Independent Model)
· un modèle d’architecture technique (PDM : Platform Dependent Model)
· un modèle d’implantation pour une plate-forme spécifique (PSM : Platform Specific Model).
Le passage d’un modèle à l’autre s’effectue par transformations successives, soit du modèle le plus
abstrait jusqu’au code, soit du code en « remontant » jusqu’à un modèle abstrait (retro-ingénierie).
La Figure 4 illustre ces différentes transformations. La Figure 5 quant à elle, illustre l’unification
d’un modèle indépendant de la plate-forme (Platform Independent Model, PIM), par exemple une
gestion de stock, avec un modèle dépendant de la plate-forme (Platform Dependent Model, PDM),
par exemple un site web. Leur union produit un modèle spécifique à la plate-forme (Platform
Specific Model, PSM), donc dans ce cas un site web de gestion de stock, qui lui-même permet de
produire du code.
Figure 6 : Le processus d’évolution d’architecture (source Sodifrance)
Figure 7 : Extrait du métamodèle architecture n-tiers (ANT)
Ce sont ces différents modèles que l’on retrouve dans le processus d’évolution d’architecture lors
des phases de transformation (cf. Figure 6 étape 3).
Les sources sont analysées par des outils de d’analyse syntaxique développés par l’équipe R&D
Sodifrance (cf. Figure 6 étape 1) et alimentent :
· un modèle basé sur un métamodèle spécifique au langage.
· un outil permettant une analyse du patrimoine(4) (cf. Figure 6 étape 2).
On trouve ici une première correspondance avec la retro-ingénierie du MDA.
Lors de l’étape 3, il y a une série de transformations qui sont effectuées avec l’outil MIA
Transformation, à partir du modèle de l’application source, pour obtenir un modèle générique
Architecture N Tiers (ANT(5)).
Le métamodèle ANT est un métamodèle propre à Sodifrance, se rapprochant d’UML pour la
définition des classes ou paquetages, mais permettant en plus de représenter l’ensemble des
informations d’un programme, dont notamment l’algorithmie ou les interfaces graphiques. La
Figure 7 nous détaille un extrait de ce métamodèle.
Toujours durant l’étape 3, de nouvelles transformations ANT vers ANT sont appliquées pour
façonner les modèles en fonction de l’architecture cible définie par le client. Il est assez rare que les
clients ne sachent pas vers quoi ils veulent migrer leurs applications. Dans ce cas, nous leur
proposons un langage et une architecture cible. Mais le plus souvent, ils savent exactement vers
quoi ils veulent aller. Certains ont même déjà développé des applications vers cette cible, d’autres
ont poussé l’exercice jusqu’à produire leurs propres briques logicielles de base (Framework). A
nous d’adapter notre outillage pour atteindre la cible fixée.
Par exemple, nous pouvons mettre en place des règles pour créer des nouveaux composants comme
des paquetages, des classes, des variables ou des fonctions, mais aussi créer des instructions à
l’intérieur de ces fonctions. En réalité, on trouvera au sein de cette troisième étape trois phases
elles-mêmes assez distinctes, et qui là encore rejoignent les principaux modèles du MDA.
Dans un premier temps, on va chercher à effacer au maximum les références au langage et à
l’architecture source pour obtenir un modèle « harmonisé ». On tente autant que possible de passer
du PSM au PIM.
Ensuite, on va ajouter des informations indépendantes de l’architecture ou du langage cible sur les
éléments déjà présents dans le modèle. Ceci afin de faciliter soit les transformations suivantes, soit
la génération (PIM vers PIM, ou PIM vers PSM vers code).
Et pour terminer, on va ajouter toutes les informations nécessaires à la génération vers la solution
cible (PIM vers PSM), avec cette fois-ci des données liées au langage, au choix d’architecture et
bien entendu aux exigences spécifiques du client.
C’est aussi pendant l’étape 3 que l’on peut extraire des informations nécessaires pour alimenter des
modèles UML génériques ou spécifiques au client. Cela trouve tout son sens si le client est déjà
dans une démarche de développement dirigé par les modèles et maintient ses applications de cette
façon (cf. Figure 6 étape 5).
Durant la phase de génération (cf. Figure 6 étape 4), l’outil MIA Generation parcourt le modèle cible
obtenu par les transformations, et produit du code en fonction de scripts positionnés au niveau des
objets du métamodèle. On est clairement dans la phase PSM vers code de la démarche MDA.
3 OMG : Object Management Group. http://www.omg.org/
4 MIA-Insight : http://www.mia-software.com/produits/mia-insight/
5 Le métamodèle ANT a été conçu par les équipes R&D de Sodifrance. Comme UML, il permet de définir les
applications en termes de classes, écrans ou package. Mais il permet aussi de stocker les informations d’algorithmie.
Etant insensible au langage source, c’est devenu le métamodèle de générique de Sodifrance. La plupart des
transformations et des générations s’effectuent vers ou à partir de ce dernier.
Page suivante : 2.2.3 Les tests dans le processus de migration
Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance