Les technologies et les frameworks ne sont pas immortels, c'est un fait. Pour un éditeur de logiciel comme nous, c'est régulièrement une nécessité de migrer un framework vers un autre. Lorsque l'on considère que de grands logiciels comme e-sedit par exemple, la migration de l'ensemble du logiciel en une seule fois est presque impossible. De nombreuses entreprises procèdent à la migration de leurs systèmes logiciels. Et nous aussi ! Ici, nous parlons de la migration des cadres d'interface utilisateur. Nous faisons migrer des applications du framework GWT GUI vers le framework Angular GUI. Cette migration comprend un changement de cadre (GWT à Angular) et un changement de langage de programmation (de Java à TypeScript). Pour ce faire, nous avons développé une approche basée sur des méta-modèles qui migre de manière semi-automatique l'interface graphique d'une application. L'approche peut être divisée en 3 étapes : extraction du code source, extraction de l'interface graphique, exportation. Le site extraction du code source crée un modèle du code source que l'on peut demander et dans lequel on peut naviguer. Le site Extraction de l'interface graphique récupère dans le modèle de code source les widgets de l'application, leurs attributs, et leur composition (pour construire un DOM). Enfin, le exportation recrée l'interface graphique dans la langue cible (dans notre contexte, Angular). Nous présentons ici notre dernière expérience visant à aider l'équipe d'e-sedit à migrer du framework frontal vers Angular. Boîte à outils Web de Google (GWT) à Angulaire. Au cours de ce processus de migration, nous nous sommes interrogés :
Comment pouvons-nous évaluer le succès ou l'échec de notre processus de migration ?
Et comment s'assurer que la nouvelle interface utilisateur ressemblera à l'ancienne ?
Plus précisément, dans le cas d'une migration d'interface graphique : Comment s'assurer que la nouvelle IU ressemblera à l'ancienne ? Dans l'étude de la migration, deux IU sont souvent considérées comme similaires si elles ont un DOM similaire. Nous avons donc décidé de tenter l'expérience avec cette stratégie et ce fut un désastre. En effet, deux IU peuvent avoir le même DOM et avoir deux aspects visuels complètement différents. Nous devons trouver un autre moyen de valider la migration de l'interface graphique.
Validation de la mise en page et comparaison d'images
La mise en page peut être définie à plusieurs niveaux de granularité, au niveau du pixel, du widget ou du panneau. Le dernier niveau est particulièrement intéressant car il valide que la page migrée ressemble à la page originale mais n'exige pas que les pages soient parfaitement identiques. C'est un comportement attendu lors de la migration d'une interface graphique car la migration est aussi le moment d'améliorer l'apparence de son application sans perturber l'utilisateur final).
L'idée est de comparer la disposition de l'interface graphique originale et celle de l'interface graphique migrée. La comparaison de la mise en page n'est pas une idée nouvelle. En effet, d'autres domaines de recherche ont déjà appliqué une telle stratégie pour classer les documents en différentes catégories. Par exemple, un article scientifique n'a pas la même mise en page qu'un billet de blog.
Première ébauche de la solution
L'approche pour valider la migration d'une application est divisée en 5 étapes :
- Détection des pages à valider : nous devons rassembler les pages de l'application originale et la page migrée correspondante.
- Navigation dans les pages originales et migrées : l'outil parcourt les pages à l'aide d'un navigateur (Chrome, Firefox, Safari, ...).
- Création de blocs : nous mettons en évidence l'élément structurel de la mise en page (panneau, fieldset, ...) et masquons l'autre élément (bouton, texte, etc.).
- Je fais une capture d'écran : l'outil prend une capture d'écran des pages originales et migrées avec les blocs.
- Comparaison : pour chaque couple de pages, nous comparons la position des blocs.
Les défis de la comparaison des dispositions
Notre expérience nous a permis d'identifier 6 défis pour la validation de la mise en page :
- Éléments d'aménagement structurel: Notre approche est basée sur la mise en évidence des "éléments structuraux d'aménagement". Il est donc essentiel de pouvoir identifier ces structures. Nous avons considéré que les fieldsets sont les éléments structurels de mise en page de toutes les pages. Cependant, la mise en page existe aussi dans les pages où le DOM ne contient pas de fieldsets.
- Architecture basée sur Ajax : L'approche est également basée sur la possibilité de parcourir chaque couple de pages dans les applications source et cible. Il est important de noter que les actions nécessaires pour accéder à une page peuvent différer entre les deux applications. Par exemple, l'application source peut être une application HTML/CSS où l'on accède à une page à l'aide de son URL, alors que l'application migrée est écrite à l'aide d'un framework web récent (comme Angular, Read, etc.), et l'accès à une page se fait par l'exécution d'actions sur la page web (accéder à la page principale par son URL, puis cliquer sur un bouton qui permettra de naviguer vers la page à parcourir).
- Déplacement successif : le déplacement d'un bloc peut entraîner le déplacement d'autres blocs et ainsi de suite. Cette situation peut conduire à deux images complètement différentes alors que les différences de mise en page sont minimes.
- Contenu dynamique : La taille des widgets peut également dépendre des données qu'ils présentent. Par exemple, un tableau affiche des informations qui proviennent d'une base de données. Si les données de la base de données évoluent, les données présentes dans la table vont également changer, et la taille de la table va changer. Ainsi, les captures d'écran entre l'application source et l'application migrée seront différentes alors que la mise en page restera inchangée.
- Widget interactif : Certains widgets sont interactifs. C'est le cas du panneau extensible, un panneau qui peut être ouvert ou fermé par l'utilisateur. Si le panneau est ouvert par défaut dans l'application source, et fermé dans l'application migrée, les captures d'écran résultantes peuvent différer. Cependant, la mise en page reste inchangée. Nous devons donc nous assurer que tous les widgets interactifs conservent le même état (ouvert/fermé) avant l'étape de capture d'écran.
- Chevauchement : Une interface utilisateur est composée d'éléments de mise en page structurels imbriqués les uns dans les autres. Ainsi, un élément peut se trouver au-dessus d'un autre, ou en dessous d'un autre. La position des éléments est communément appelée z-index, et elle fait partie de la mise en page. Bien que notre approche permette de déterminer les éléments à l'intérieur des autres, elle ne permet pas de distinguer si un élément est au-dessus ou au-dessous d'un autre.
Caractéristiques d'aide à la validation
De plus, en analysant les défis définis précédemment, nous reconnaissons certaines des caractéristiques qui seraient nécessaires pour développer des solutions élégantes et puissantes pour surmonter ces défis.
- Identification du bloc : Dans notre approche, nous comparons des captures d'écran d'images où vous avez précédemment mis en évidence les blocs. Cependant, nous n'avons pas identifié les blocs dans l'image, nous appliquons "seulement" un nouveau style CSS qui crée les blocs. Identifier réellement les blocs permettrait d'effectuer une analyse plus précise. Par exemple, on peut compter le nombre de blocs ou comparer les pixels d'un bloc source avec le reste de l'interface utilisateur migrée.
- Traçabilité: Si nous pouvons identifier les blocs, une fonctionnalité utile sera de tracer les blocs, c'est-à-dire de savoir quel bloc de l'application source correspond à quel bloc de l'application migrée. Ainsi, il sera possible de comparer un bloc de l'application source avec le bloc généré correspondant dans l'application migrée.
- Relation de bloc : Une autre fonctionnalité intéressante serait la possibilité de calculer la relation entre les blocs. Au lieu de comparer la position des blocs dans une page, on compare la position des blocs d'une page à l'autre. La réalisation de cette fonctionnalité serait l'étape finale de la validation de la migration de la mise en page.
Conclusion
Nous avons mené une première expérience sur la validation de la migration de l'interface graphique de GWT vers Angular. Il apparaît que la validation de la migration de la mise en page est essentielle mais souvent ignorée. Ainsi, nous avons proposé une première ébauche de solution et défini les principaux défis à relever pour valider la migration de la mise en page. Nous avons également identifié les défis futurs de la validation de la migration de la mise en page.
