2.2 Le processus d'évolution d'architecture
Avant de présenter la problématique proprement
dite de ce mémoire, il convient de définir le contexte dans
lequel il s'est déroulé. Comme indiqué
précédemment, j'appartiens à l'équipe
d'évolution d'architecture de Sodifrance. Je devais donc réussir
à intégrer mes travaux dans le processus de migration
existant.
2.2.1 Présentation générale du
processus de migration
Le processus global de migration est divisé en deux
grandes parties :
La phase de cadrage, qui permet de définir
précisément ce qui va être fait :
· étude de la, ou des applications sources
· étude de l'architecture cible
· définition des lots de migration
· adaptation de l'outillage (MIA
Transformation1, MIA Generation2)
· vérification de la validité de la
solution par la réalisation d'un POC (Proof Of Concept) Une
fois la phase de cadrage terminée, l'ensemble des applications à
migrer passe par la phase industrielle. Au cours de cette phase, nous
trouvons:
· les tests de référence
· l'intégration manuelle du code issu de la
génération (rendre le code compilable, corriger manuellement ce
qui n'a pu être généré directement, tests
unitaires).
· les tests de non régression (validation des
résultats des tests de références de l'application source
sur l'application migrée).
· le déploiement sur le site du client
1 MIA Transformation : outil de transformation de
modèles.
http://www.mia-software.com/.../mia-transformation
2 MIA Generation : outil de génération
de code à partir de modèles.
http://www.mia-software.com/.../mia-generation
Figure 4 : Les transformations des modèles MDA (Villemin
2011, p.12)
Figure 5 : Unification PIM et PDM pour
produire le PSM puis le code (Villemin 2011, p.14)
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
La seule façon de valider une migration est de passer
les scénarios des tests de référence,
réalisés sur l'application source, sur l'application
migrée. De cette manière, on peut garantir que la migration n'a
pas introduit de régression et est conforme à l'application
source, sur le périmètre des tests de référence
bien entendu. C'est là que l'on s'aperçoit de l'importance de la
couverture des tests de référence. En effet, s'ils ne couvrent
qu'un petit pourcentage de l'application source, toutes les parties non
couvertes risquent potentiellement de contenir des erreurs sur l'application
cible.
2.2.2 Présentation du processus de migration
industrielle
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'OMG3 "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.
3 OMG : Object Management Group.
http://www.omg.org/
Figure 6 : Le processus d'évolution d'architecture
(source Sodifrance)
Figure 7 : Extrait du métamodèle architecture
n-tiers (ANT)
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
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 patrimoine4
(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 (ANT5).
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.
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.
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.
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
| 
