Cached accessibility-tree control and code-enforced verification for design entry through a desktop application's user interface

En el mundo del software, existe una división persistente entre cómo los humanos interactúan con las computadoras y cómo las máquinas se comunican entre sí. Los humanos utilizan interfaces gráficas, haciendo clic en botones y escribiendo en cuadros que aparecen en una pantalla. Las máquinas, sin embargo, suelen preferir hablar un lenguaje directo y estructurado, omitiendo la capa visual para enviar comandos directamente al código subyacente. Cuando una pieza de software carece de este lenguaje directo, se convierte en una "caja negra" para las herramientas de automatización. Este es un obstáculo común para la automatización robótica de procesos, un campo donde los bots de software son entrenados para realizar tareas repetitivas imitando las acciones humanas en una pantalla. El desafío es doble: primero, el bot debe encontrar el botón o elemento de menú correcto en un paisaje complejo y cambiante de ventanas; segundo, debe saber si la acción que acaba de realizar realmente funcionó. Sin una línea de comunicación directa, el bot es esencialmente ciego, adivinando si un clic aterrizó en el lugar correcto o si una nueva ventana apareció como se esperaba.

Un investigador llamado Tiago Miranda de Leao abordó este problema construyendo un sistema para automatizar una tarea específica y compleja: diseñar gabinetes de cocina utilizando una popular aplicación de Windows llamada Mozaik Enterprise. Este software no ofrece una forma directa para que programas externos hablen con él, por lo que el sistema del investigador tuvo que operar enteramente a través de la interfaz de usuario, tal como lo haría un humano. El sistema fue diseñado para resolver los dos problemas principales de la automatización: control y corrección. Para manejar el control, el sistema primero dedicó tiempo a mapear toda la estructura de la interfaz de la aplicación, creando un mapa mental de dónde vivía cada botón y menú. Una vez construido este mapa, el sistema dejó de buscar cosas y, en su lugar, actuó basándose en una lista de coordenadas almacenadas en caché, haciendo clic directamente en las ubicaciones conocidas de los elementos de la interfaz. Para manejar la corrección, el sistema utilizó un modelo de visión para "leer" un dibujo de diseño y luego utilizó reglas de código estrictas y preescritas para verificar si la computadora realmente había construido lo que se solicitó. El código, no la inteligencia artificial, tomó la decisión final sobre si el trabajo fue exitoso.

Los resultados de este experimento fueron una mezcla de velocidad prometedora y limitaciones significativas. El sistema mapeó con éxito la interfaz de la aplicación, identificando casi mil elementos distintos, y almacenó las posiciones de unos seiscientos de ellos. Cuando el sistema intentó cambiar entre diferentes pestañas en el software, la diferencia entre buscar la pestaña y hacer clic en una ubicación almacenada en caché fue notable. Encontrar una pestaña mediante el método estándar tomó entre veintinueve y cincuenta y siete segundos, un proceso que implicaba buscar a través de la estructura interna de la aplicación cada vez. Una vez que la ubicación fue almacenada en caché, sin embargo, cambiar a esa misma pestaña tomó menos de un tercio de segundo. Esto demostró que, para un entorno estable, recordar dónde están las cosas es mucho más eficiente que buscarlas cada vez.

Sin embargo, la capacidad de adaptación del sistema era frágil. Las posiciones almacenadas en caché estaban ligadas al tamaño y la forma exactos de la ventana cuando se realizó el mapa por primera vez. Si el tamaño de la ventana cambiaba, o si la resolución de la pantalla era diferente, las coordenadas almacenadas en caché apuntarían al lugar equivocado, y el sistema fallaría. El investigador encontró que el sistema no podía repararse automáticamente; si el diseño cambiaba, todo el mapa tenía que reconstruirse desde cero. Además, el sistema no comprobaba si sus clics realmente funcionaban. Reportaba éxito incluso si la aplicación no respondía, porque no tenía forma de verificar el resultado sin mirar la pantalla de nuevo, lo que invalidaría el propósito de usar la memoria caché.

La parte de verificación del sistema, que comprobaba si el diseño coincidía con el dibujo, funcionó bien en teoría pero enfrentó obstáculos en la práctica. El sistema fue probado con quinientos casos sintéticos donde se inyectaron errores deliberadamente en los datos. En estas pruebas, el código identificó correctamente cada error intencionado, como gabinetes faltantes o tipos de electrodomésticos incorrectos, y nunca dio una falsa alarma. Rechazó con éxito los diseños que no coincidían con los requisitos. No obstante, cuando el sistema fue probado en intentos reales y no programados de construir gabinetes, los resultados fueron menos claros. Cinco intentos registrados de construir un diseño completo fallaron en una etapa temprana, deteniéndose antes de que el producto final pudiera ser verificado. Los registros mostraron que el sistema no pudo contar correctamente los gabinetes que debía construir, lo que provocó una parada inmediata. El investigador señaló que el sistema no había sido probado en una amplia variedad de dibujos del mundo real, y los pocos intentos reales registrados fueron incompletos.

El estudio también destacó el papel de la inteligencia artificial en este proceso. El sistema utilizó un modelo de IA para interpretar los dibujos de diseño, pero la decisión final sobre si la construcción fue exitosa se dejó al código. Esta separación fue intencional; el código actuó como un guardián estricto, asegurando que la interpretación de la IA fuera verificada contra reglas duras. El investigador encontró que, si bien la IA podía describir los dibujos, no se le podía confiar para juzgar el resultado por sí sola. El sistema fue diseñado de modo que, si la IA cometía un error, el código lo detectaría. Sin embargo, los registros most mostraron que en los pocos intentos del mundo real, el sistema falló antes de poder siquiera llegar a la etapa donde la descripción de la IA se comparaba con el resultado final.

En última instancia, este trabajo proporciona una imagen clara de lo que es posible cuando se automatiza un software que se niega a hablar directamente con las máquinas. El enfoque de mapear la interfaz una vez y luego actuar sobre esos recuerdos es rápido y efectivo, pero es frágil. Funciona solo mientras el software luzca exactamente igual a cuando se realizó el mapa. El sistema demostró que las verificaciones impuestas por el código pueden verificar los resultados de manera confiable, pero también mostró que, sin una forma robusta de manejar los cambios en la interfaz o de recuperarse de los errores, la automatización aún no puede reemplazar a un humano en un entorno dinámico. El investigador concluyó que, si bien el método funciona para una versión específica del software en una máquina específica, no es una solución general para todas las aplicaciones. El sistema sigue siendo una prueba de concepto, demostrando que la automatización es posible incluso sin acceso directo, pero también subraya la dificultad de hacer que tales sistemas sean lo suficientemente robustos para el mundo real.