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

No mundo do software, existe uma divisão persistente entre como os humanos interagem com os computadores e como as máquinas conversam entre si. Os humanos usam interfaces gráficas, clicando em botões e digitando em caixas que aparecem na tela. As máquinas, no entanto, muitas vezes preferem falar uma linguagem direta e estruturada, ignorando a camada visual para enviar comandos diretamente ao código subjacente. Quando um software carece dessa linguagem direta, ele se torna uma "caixa preta" para ferramentas de automação. Este é um obstáculo comum para a automação de processos robóticos, um campo onde bots de software são treinados para realizar tarefas repetitivas mimetizando ações humanas na tela. O desafio é duplo: primeiro, o bot deve encontrar o botão ou item de menu correto em um cenário complexo e mutável de janelas; segundo, ele deve saber se a ação que acabou de realizar realmente funcionou. Sem uma linha direta de comunicação, o bot é essencialmente cego, adivinhando se um clique caiu no lugar certo ou se uma nova janela apareceu como esperado.

Um pesquisador chamado Tiago Miranda de Leao abordou este problema construindo um sistema para automatizar uma tarefa específica e complexa: projetar armários de cozinha usando uma popular aplicação Windows chamada Mozaik Enterprise. Este software não oferece uma maneira direta para programas externos falarem com ele, portanto, o sistema do pesquisador teve que operar inteiramente através da interface do usuário, tal como um humano faria. O sistema foi projetado para resolver os dois problemas principais da automação: controle e correção. Para lidar com o controle, o sistema primeiro passou um tempo mapeando toda a estrutura da interface da aplicação, criando um mapa mental de onde cada botão e menu residia. Uma vez construído esse mapa, o sistema parou de procurar coisas e, em vez disso, agiu com base em uma lista de coordenadas em cache, clicando diretamente nos locais conhecidos dos elementos da interface. Para lidar com a correção, o sistema utilizou um modelo de visão para "ler" um desenho de projeto e, em seguida, utilizou regras de código estritas e pré-escritas para verificar se o computador realmente construiu o que foi solicitado. O código, e não a inteligência artificial, tomou a decisão final sobre se o trabalho foi bem-sucedido.

Os resultados deste experimento foram uma mistura de velocidade promissora e limitações significativas. O sistema mapeou com sucesso a interface da aplicação, identificando quase mil elementos distintos, e armazenou as posições de cerca de seiscentos deles. Quando o sistema tentou alternar entre diferentes abas no software, a diferença entre procurar a aba e clicar em um local em cache foi gritante. Encontrar uma aba através do método padrão levou de vinte e nove a cinquenta e sete segundos, um processo que envolvia pesquisar na estrutura interna da aplicação todas as vezes. Uma vez que a localização estava em cache, no entanto, alternar para essa mesma aba levou menos de um terço de segundo. Isso demonstrou que, para um ambiente estável, lembrar onde as coisas estão é vastamente mais eficiente do que procurá-las todas as vezes.

Contudo, a capacidade de adaptação do sistema era frágil. As posições em cache estavam vinculadas ao tamanho e formato exatos da janela quando o mapa foi criado pela primeira vez. Se o tamanho da janela mudasse, ou se a resolução da tela fosse diferente, as coordenadas em cache apontariam para o lugar errado, e o sistema falharia. O pesquisador descobriu que o sistema não conseguia se reparar automaticamente; se o layout mudasse, o mapa inteiro precisava ser reconstruído do zero. Além disso, o sistema não verificava se seus cliques funcionavam. Ele reportava sucesso mesmo se a aplicação não respondesse, porque não tinha como verificar o resultado sem olhar para a tela novamente, o que invalidaria o propósito do uso de cache.

A parte de verificação do sistema, que checava se o projeto correspondia ao desenho, funcionou bem em teoria, mas enfrentou obstáculos na prática. O sistema foi testado com quinhentos casos sintéticos onde erros foram deliberadamente injetados nos dados. Nestes testes, o código identificou corretamente todos os erros pretendidos, como armários ausentes ou tipos de eletrodomésticos errados, e nunca gerou um alarme falso. Ele rejeitou com sucesso projetos que não correspondiam aos requisitos. No entanto, quando o sistema foi testado em tentativas reais e não roteirizadas de construir armários, os resultados foram menos claros. Cinco tentativas registradas de construir um projeto completo falharam em um estágio inicial, parando antes que o produto final pudesse ser verificado. Os logs mostraram que o sistema não conseguiu contar corretamente os armários que deveria construir, levando a uma interrupção imediata. O pesquisador observou que o sistema não havia sido testado em uma grande variedade de desenhos do mundo real, e as poucas tentativas reais registradas estavam incompletas.

O estudo também destacou o papel da inteligência artificial neste processo. O sistema utilizou um modelo de IA para interpretar os desenhos de projeto, mas a decisão final sobre se a construção foi bem-sucedida foi deixada ao código. Esta separação foi intencional; o código atuou como um guardião rigoroso, garantindo que a interpretação da IA fosse verificada contra regras rígidas. O pesquisador descobriu que, embora a IA pudesse descrever os desenhos, ela não podia ser confiada para julgar o resultado por conta própria. O sistema foi projetado de modo que, se a IA cometesse um erro, o código o detectaria. No entanto, os registros mostraram que, nas poucas tentativas do mundo real, o sistema falhou antes mesmo de chegar à etapa onde a descrição da IA seria comparada ao resultado final.

Em última análise, este trabalho fornece um panorama claro do que é possível ao automatizar softwares que se recusam a falar diretamente com máquinas. A abordagem de mapear a interface uma vez e depois agir com base nessas memórias é rápida e eficaz, mas é frágil. Funciona apenas enquanto o software parecer exatamente igual ao momento em que o mapa foi feito. O sistema provou que verificações impostas por código podem verificar resultados de forma confiável, mas também mostrou que, sem uma maneira robusta de lidar com mudanças na interface ou de recuperar-se de erros, a automação ainda não pode substituir um humano em um ambiente dinâmico. O pesquisador concluiu que, embora o método funcione para uma versão específica do software em uma máquina específica, não é uma solução geral para todas as aplicações. O sistema permanece como uma prova de conceito, demonstrando que a automação é possível mesmo sem acesso direto, mas também ressaltando a dificuldade de tornar tais sistemas robustos o suficiente para o mundo real.