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

Nel mondo del software, esiste una divisione persistente tra il modo in cui gli esseri umani interagiscono con i computer e il modo in cui le macchine comunicano tra loro. Gli esseri umani utilizzano interfacce grafiche, cliccando pulsanti e digitando in caselle che appaiono su uno schermo. Le macchine, tuttavia, spesso preferiscono parlare un linguaggio diretto e strutturato, bypassando lo strato visivo per inviare comandi direttamente al codice sottostante. Quando un software manca di questo linguaggio diretto, diventa una "scatola nera" per gli strumenti di automazione. Questa è una sfida comune per la robotica di processo (RPA), un campo in cui i bot software vengono addestrati per eseguire compiti ripetitivi imitando le azioni umane su uno schermo. La sfida è duplice: prima, il bot deve trovare il pulsante o la voce di menu corretta in un panorama complesso e mutevole di finestre; secondo, deve sapere se l'azione appena compiuta ha effettivamente funzionato. Senza una linea di comunicazione diretta, il bot è essenzialmente cieco, cercando di indovinare se un clic è atterrato nel punto giusto o se una nuova finestra è apparsa come previsto.

Un ricercatore di nome Tiago Miranda de Leao ha affrontato questo problema costruendo un sistema per automatizzare un compito specifico e complesso: progettare mobili da cucina utilizzando un popolare applicativo Windows chiamato Mozaik Enterprise. Questo software non offre un modo diretto affinché programmi esterni possano comunicare con esso, quindi il sistema del ricercatore doveva operare interamente attraverso l'interfaccia utente, proprio come farebbe un essere umano. Il sistema è stato progettato per risolvere i due problemi principali dell'automazione: il controllo e la correttezza. Per gestire il controllo, il sistema ha prima dedicato del tempo a mappare l'intera struttura dell'interfaccia dell'applicazione, creando una mappa mentale di dove risiedessero ogni pulsante e ogni menu. Una volta costruita questa mappa, il sistema ha smesso di cercare le cose e ha invece agito su una lista di coordinate memorizzate nella cache, cliccando direttamente sulle posizioni note degli elementi dell'interfaccia. Per gestire la correttezza, il sistema ha utilizzato un modello di visione per "leggere" un disegno progettuale e ha poi utilizzato regole di codice rigide e pre-scritte per verificare se il computer avesse effettivamente costruito quanto richiesto. Il codice, e non l'intelligenza artificiale, prendeva la decisione finale sul fatto che il lavoro fosse stato completato con successo.

I risultati di questo esperimento sono stati un mix di velocità promettente e limitazioni significative. Il sistema ha mappato con successo l'interfaccia dell'applicazione, identificando quasi mille elementi distinti, e ha memorizzato le posizioni di circa seicento di essi. Quando il sistema ha tentato di passare tra diversi tab all'interno del software, la differenza tra cercare il tab e cliccare su una posizione memorizzata nella cache è stata netta. Trovare un tab attraverso il metodo standard richiedeva da ventinove a cinquantasette secondi, un processo che comportava la ricerca attraverso la struttura interna dell'applicazione ogni singola volta. Una volta che la posizione era stata memorizzata nella cache, tuttavia, passare a quello stesso tab richiedeva meno di un terzo di secondo. Ciò ha dimostrato che, per un ambiente stabile, ricordare dove si trovano le cose è molto più efficiente che cercarle ogni volta.

Tuttavia, la capacità di adattamento del sistema era fragile. Le posizioni memorizzate nella cache erano legate alle dimensioni esatte e alla forma della finestra al momento in cui è stata creata la mappa. Se la dimensione della finestra cambiava, o se la risoluzione dello schermo era diversa, le coordinate memorizzate avrebbero puntato nel posto sbagliato, e il sistema sarebbe fallito. Il ricercatore ha scoperto che il sistema non poteva ripararsi automaticamente; se il layout cambiava, l'intera mappa doveva essere ricostruita da zero. Inoltre, il sistema non controllava se i suoi clic avessero effettivamente funzionato. Riportava il successo anche se l'applicazione non rispondeva, perché non aveva modo di verificare il risultato senza guardare nuovamente lo schermo, il che avrebbe vanificato lo scopo della memorizzazione nella cache.

La parte di verifica del sistema, che controllava se il progetto corrispondeva al disegno, funzionava bene in teoria ma affrontava ostacoli nella pratica. Il sistema è stato testato con cinquecento casi sintetici in cui errori venivano deliberatamente inseriti nei dati. In questi test, il codice ha identificato correttamente ogni errore intenzionale, come mobili mancanti o tipi di elettrodomestici errati, e non ha mai generato falsi allarmi. Ha rifiutato con successo i progetti che non corrispondevano ai requisiti. Eppure, quando il sistema è stato testato su tentativi reali e non scriptati di costruire mobili, i risultati sono stati meno chiari. Cinque tentativi registrati di costruire un progetto completo sono falliti in una fase iniziale, interrompendosi prima che il prodotto finale potesse essere verificato. I log hanno mostrato che il sistema non riusciva a contare correttamente i mobili che doveva costruire, portando a un arresto immediato. Il ricercatore ha osservato che il sistema non era stato testato su una vasta gamma di disegni del mondo reale e che i pochi tentativi reali registrati erano incompleti.

Lo studio ha anche evidenziato il ruolo dell'intelligenza artificiale in questo processo. Il sistema ha utilizzato un modello di IA per interpretare i disegni progettuali, ma la decisione finale sul successo della costruzione è stata lasciata al codice. Questa separazione era intenzionale; il codice fungeva da rigoroso guardiano, assicurando che l'interpretazione dell'IA fosse controllata rispetto a regole ferree. Il ricercatore ha scoperto che, sebbene l'IA potesse descrivere i disegni, non poteva essere affidata al giudizio dell'esito da sola. Il sistema era progettato in modo che, se l'IA avesse commesso un errore, il codice lo avrebbe intercettato. Tuttavia, i registri hanno mostrato che, nei pochi tentativi reali, il sistema è fallito prima ancora di poter raggiungere la fase in cui la descrizione dell'IA veniva confrontata con il risultato finale.

In definitiva, questo lavoro fornisce un quadro chiaro di ciò che è possibile quando si automatizza un software che si rifiuta di parlare direttamente con le macchine. L'approccio di mappare l'interfaccia una volta sola e poi agire su quei ricordi è veloce ed efficace, ma è fragile. Funziona solo finché il software appare esattamente come quando è stata creata la mappa. Il sistema ha dimostrato che i controlli imposti dal codice possono verificare i risultati in modo affidabile, ma ha anche mostrato che, senza un modo robusto per gestire i cambiamenti nell'interfaccia o per recuperare dagli errori, l'automazione non può ancora sostituire un essere umano in un ambiente dinamico. Il ricercatore ha concluso che, sebbene il metodo funzioni per una versione specifica del software su una macchina specifica, non è una soluzione generale per tutte le applicazioni. Il sistema rimane una prova di concetto, dimostrando che l'automazione è possibile anche senza accesso diretto, ma sottolinea anche la difficoltà di rendere tali sistemi abbastanza robusti per il mondo reale.