Soutien à l'automatisation de la migration des interfaces d'applications Web : le cas de GWT vers Angular
Au cours de l'évolution d'une application, il est parfois nécessaire de migrer sa mise en œuvre vers un langage de programmation et/ou un cadre d'interface utilisateur graphique (GUI) différent. Les frameworks d'interface graphique web, en particulier, évoluent à un rythme rapide. Par exemple, en 2018, il y avait deux versions majeures d'Angular, trois versions majeures de React.js et quatre versions de Vue.js. Cela oblige les entreprises à mettre à jour régulièrement leurs systèmes logiciels pour éviter d'être bloquées dans de vieilles technologies.Chez Berger-Levrault, nous devons migrer nos applications du framework GWT vers Angular. Nous avons 8 applications qui utilisent GWT. Chaque application a plus de 1,5 MLOC (Million Lines of Code) et représente plus de 400 pages web. Dans ce travail, nous proposons une approche en quatre étapes qui utilise un méta-modèle pour représenter l'interface graphique à un haut niveau d'abstraction.
Méta-modèles
Nos contraintes
Nous identifions les contraintes suivantes pour notre étude de cas :
- De GWT à Angular. Dans le cadre de la collaboration avec Berger-Levrault, notre approche de migration doit fonctionner avec Java GWT comme langage source et TypeScript Angular comme langage cible.
- Adaptabilité de l'approche. Notre approche doit être aussi adaptable que possible à différents contextes. Par exemple, elle peut être utilisée avec différents langages source et cible et être adaptée par un développeur pour répondre à ses besoins.
- Conserver l'aspect visuel. La migration doit permettre de conserver l'aspect visuel de l'application cible aussi proche que possible de l'original.
- Conservation de la qualité du code. Notre approche doit produire un code qui semble familier aux développeurs de l'application source. Dans la mesure du possible, le code cible doit conserver la même structure, les mêmes identifiants et les mêmes commentaires.
- Automatique. Une solution automatique rend l'approche plus accessible. Il serait plus facile d'utiliser une approche automatique sur un grand système.
Mise en œuvre des importations
En partie à cause de la complexité de la mise en place d'un outil capable de fonctionner automatiquement et de capturer tous les écrans d'applications web de cette taille, nous nous appuyons sur l'analyse statique pour créer notre modèle. Les résultats obtenus jusqu'à présent semblent indiquer que cela sera suffisant. La création du modèle d'interface graphique est divisée en deux étapes : l'extraction du modèle de code source et l'extraction du modèle d'interface graphique. Pour le méta-modèle du code source, nous utilisons le méta-modèle Java de Moose qui est fourni avec un extracteur Java.
Pour la deuxième étape de l'extraction, notre outil crée le modèle d'interface graphique à partir du modèle de code source et d'une analyse du fichier de configuration XML. Les entités que nous voulons extraire sont, tout d'abord, les pages. Nous analysons le fichier de configuration XML dans lequel sont définies les informations sur les pages. Ensuite, l'outil recherche les pages Business et les Widgets.
Une page Business est définie par une classe GWT Java qui implémente l'interface IPageMetier. Un Widget est défini par une classe qui est une sous-classe de la classe GWT Widget. Ensuite, pour les pages Business et les Widgets, l'outil cherche où leurs constructeurs sont appelés et à partir de là, il déduit et crée un lien entre le Widget et son conteneur.
Enfin, pour détecter les attributs qui appartiennent à un widget, l'outil détecte dans quelle variable Java le widget a été affecté. Ensuite, il recherche les méthodes invoquées sur cette variable. S'il invoque une méthode "setX", il crée un attribut.
