Comprobación de la migración de las interfaces gráficas de usuario

Las tecnologías y los frameworks no son inmortales, es un hecho. Para un editor de software como nosotros, es regularmente una necesidad migrar un framework a otro. Si tenemos en cuenta que los grandes programas informáticos como e-sedit Por ejemplo, migrar todo el software de una sola vez es casi imposible. Muchas empresas están migrando sus sistemas de software. Y nosotros también. Aquí nos referimos a la migración de los marcos de la interfaz de usuario. Estamos migrando aplicaciones del framework GWT GUI al framework Angular GUI. Esta migración incluye un cambio de framework (GWT a Angular) y un cambio de lenguaje de programación (de Java a TypeScript). Para ello, hemos desarrollado un enfoque basado en metamodelos que migra de forma semiautomática la GUI de una aplicación. El enfoque se puede dividir en 3 pasos: extracción de código fuente, extracción de GUI, exportación. El extracción del código fuente crea un modelo del código fuente que podemos solicitar y navegar. La página web Extracción de la GUI recupera en el modelo de código fuente los widgets de la aplicación, sus atributos y su composición (para construir un DOM). Por último, el exportación recrea la GUI en el lenguaje de destino (en nuestro contexto Angular). Aquí presentamos nuestro último experimento para ayudar al equipo de e-sedit en la migración del framework de front-end Kit de herramientas web de Google (GWT) a Angular. Durante este proceso de migración, nos preguntamos:

¿Cómo podemos evaluar el éxito o el fracaso de nuestro proceso de migración?

¿Y cómo garantizar que la nueva interfaz de usuario se parezca a la antigua?

Más concretamente, en el caso de una migración de la interfaz gráfica de usuario: ¿Cómo garantizar que la nueva interfaz de usuario se parezca a la antigua? En el estudio de la investigación sobre la migración, se suele considerar que dos UI son similares si tienen un DOM parecido. Así que decidimos experimentar con esta estrategia y fue un desastre. Efectivamente, dos UI pueden tener el mismo DOM y tener dos aspectos visuales completamente diferentes. Debemos encontrar otra forma de validar la migración de la interfaz gráfica de usuario.

Validación del diseño y comparación de imágenes

El diseño puede definirse a varios niveles de granularidad, a nivel de píxeles, de widgets o de paneles. Este último es particularmente interesante porque valida que la página migrada se parezca a la original, pero no requiere que las páginas sean perfectamente idénticas. Es un comportamiento esperado cuando se migra la GUI porque la migración es también el momento de mejorar el aspecto de su aplicación sin perturbar al usuario final).
La idea es comparar el diseño de la GUI original y el diseño de la GUI migrada. La comparación del diseño no es una idea nueva. De hecho, otros campos de investigación ya han aplicado esta estrategia para clasificar el documento en diferentes categorías. Por ejemplo, un artículo científico no tiene el mismo diseño que una entrada de blog.

Primer esbozo de solución

El enfoque para validar la migración de una aplicación se divide en 5 pasos:

  1. Detección de páginas para validar: tenemos que recoger las páginas de la aplicación original y la correspondiente página migrada.
  2. Navegar por las páginas originales y las migradas: la herramienta explora las páginas mediante un navegador (Chrome, Firefox, Safari, ...).
  3. Creación de bloques: resaltamos el elemento de diseño estructural (panel, fieldset, ...) y ocultamos el otro elemento (botón, texto, etc.)
  4. Haciendo una captura de pantalla: la herramienta hace una captura de pantalla de las páginas originales y de las migradas con los bloques.
  5. Comparando: para cada par de páginas, comparamos la posición de los bloques.

Desafíos en la comparación de la disposición

A partir de nuestro experimento hemos identificado 6 retos para la validación del diseño:

  • Elementos de diseño estructural: Nuestro enfoque se basa en destacar los "Elementos de diseño estructural". Por lo tanto, es esencial poder identificar esas estructuras. Consideramos que los fieldsets son los elementos estructurales de maquetación de todas las páginas. Sin embargo, la maquetación también existe en las páginas en las que el DOM no contiene ningún fieldset.
  • Arquitectura basada en Ajax: El enfoque también se basa en la posibilidad de navegar por cada par de páginas en las aplicaciones de origen y destino. Es importante tener en cuenta que las acciones necesarias para acceder a una página pueden diferir entre las dos aplicaciones. Por ejemplo, la aplicación de origen puede ser una aplicación HTML/CSS en la que se accede a una página utilizando su URL, mientras que la aplicación migrada está escrita utilizando un framework web reciente (como Angular, Read, etc.), y el acceso a una página se realiza a través de la ejecución de acciones en la página web (acceder a la página principal por su URL, y luego hacer clic en un botón que navegará a la página a navegar).
  • Cambio sucesivo: el desplazamiento de un bloque puede provocar el desplazamiento de otros bloques y así sucesivamente. Esta situación puede dar lugar a dos imágenes completamente diferentes mientras que las diferencias de diseño son mínimas.
  • Contenido dinámico: El tamaño de los widgets también puede depender de los datos que presentan. Por ejemplo, una tabla muestra información que proviene de una base de datos. Si los datos de la base de datos evolucionan, los datos presentes en la tabla también cambiarán, y el tamaño de la tabla cambiará. Por lo tanto, las capturas de pantalla entre la aplicación de origen y la migrada serán diferentes, mientras que el diseño permanecerá inalterado.
  • Widget interactivo: Algunos widgets son interactivos. Es el caso del panel expandible, un panel que puede ser abierto o cerrado por el usuario. Si el panel se abre por defecto en la aplicación de origen y se cierra en la aplicación migrada, las capturas de pantalla resultantes pueden ser diferentes. Sin embargo, el diseño no cambia. Por lo tanto, debemos asegurarnos de que todos los widgets interactivos mantienen el mismo estado (abierto/cerrado) antes del paso de captura de pantalla.
  • Se solapan: Una interfaz de usuario se compone de elementos de diseño estructural anidados unos dentro de otros. Así, un elemento puede estar encima de otro, o debajo de otro. La posición de los elementos se denomina comúnmente z-index, y forma parte del diseño. Aunque nuestro enfoque permite determinar los elementos dentro de otros, no distingue si un elemento está por encima o por debajo de otro.

Funciones de ayuda a la validación

Además, a partir del análisis de los retos previamente definidos, reconocemos algunas de las características que serían necesarias para desarrollar soluciones elegantes y potentes para superar estos retos.

  • Identificación del bloque: En nuestro enfoque, comparamos capturas de pantalla de imágenes en las que previamente se destacan los bloques. Sin embargo, no identificamos los bloques en la imagen, "sólo" aplicamos un nuevo estilo CSS que crea los bloques. Identificar realmente los bloques permitiría realizar un análisis más preciso. Por ejemplo, se puede contar el número de bloques o comparar los píxeles de un bloque de origen con el resto de la IU migrada.
  • Trazabilidad: Si podemos identificar los bloques, una función útil será la de rastrear los bloques, es decir, qué bloque de la aplicación fuente se corresponde con cuál de la aplicación migrada. Así, se podrá comparar un bloque de la aplicación de origen con el correspondiente bloque generado en la aplicación migrada.
  • Relación de bloques: Otra buena característica sería la capacidad de calcular la relación de los bloques. En lugar de comparar la posición de los bloques en una página, se compararía la posición de los bloques entre sí. Conseguir esto sería el último paso en la validación de la migración de la maquetación.

Conclusión

Hemos realizado un primer experimento sobre la validación de la migración de la GUI de GWT a Angular. Parece que la validación de la migración del layout es esencial pero a menudo se ignora. Así, hemos propuesto un primer esbozo de solución y hemos definido los principales retos que hay que afrontar para validar la migración de layout. También identificamos los retos futuros en la validación de la migración de layout.

Más ...

Ir arriba