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

In der Welt der Software gibt es eine beständige Kluft zwischen der Art und Weise, wie Menschen mit Computern interagieren, und der Art und Weise, wie Maschinen miteinander kommunizieren. Menschen nutzen grafische Benutzeroberflächen, klicken auf Schaltflächen und tippen in Boxen, die auf einem Bildschirm erscheinen. Maschinen hingegen bevorzugen oft eine direkte, strukturierte Sprache und umgehen dabei die visuelle Ebene, um Befehle direkt an den zugrunde liegenden Code zu senden. Wenn einer Software diese direkte Sprache fehlt, wird sie für Automatisierungswerkzeuge zu einer „Black Box“. Dies ist ein häufiges Hindernis für die robotergestützte Prozessautomatisierung (Robotic Process Automation), ein Bereich, in dem Software-Bots darauf trainiert werden, repetitive Aufgaben zu erledigen, indem sie menschliche Handlungen auf einem Bildschirm nachahmen. Die Herausforderung ist zweifach: Erstens muss der Bot die richtige Schaltfläche oder das richtige Menüelement in einer komplexen, sich verändernden Landschaft von Fenstern finden; zweitens muss er wissen, ob die gerade ausgeführte Aktion tatsächlich funktioniert hat. Ohne eine direkte Kommunikationslinie ist der Bot im Wesentlichen blind und muss raten, ob ein Klick an der richtigen Stelle landete oder ob ein neues Fenster wie erwartet erschien.

Ein Forscher namens Tiago Miranda de Leao ging dieses Problem an, indem er ein System entwickelte, um eine spezifische, komplexe Aufgabe zu automatisieren: das Entwerfen von Küchenschränken mit einer populären Windows-Anwendung namens Mozaik Enterprise. Diese Software bietet keine direkte Möglichkeit für externe Programme, mit ihr zu kommunizieren, sodass das System des Forschers ausschließlich über die Benutzeroberfläche operieren musste, genau wie ein Mensch. Das System wurde entwickelt, um die zwei Hauptprobleme der Automatisierung zu lösen: Kontrolle und Korrektheit. Um die Kontrolle zu handhaben, verbrachte das System zunächst Zeit damit, die gesamte Struktur der Benutzeroberfläche der Anwendung abzubilden und eine mentale Karte zu erstellen, in der jedes Element und jedes Menü verzeichnet war. Sobald diese Karte erstellt war, suchte das System nicht mehr nach Dingen, sondern agierte stattdin auf Basis einer zwischengespeicherten Liste von Koordinaten, wobei es direkt auf die bekannten Positionen der Interface-Elemente klickte. Um die Korrektheit zu handhaben, nutzte das System ein Visionsmodell, um eine Entwurfszeichnung zu „lesen“, und verwendete dann strikte, vorgeschriebene Coderegeln, um zu überprüfen, ob der Computer tatsächlich das gebaut hatte, was angefordert worden war. Der Code, nicht die künstliche Intelligenz, traf die endgültige Entscheidung darüber, ob die Arbeit erfolgreich war.

Die Ergebnisse dieses Experiments waren eine Mischung aus vielversprechender Geschwindigkeit und erheblichen Einschränkungen. Das System schaffte es erfolgreich, die Benutzeroberfläche der Anwendung abzubilden, wobei es fast tausend verschiedene Elemente identifizierte und die Positionen von etwa sechshundert davon speicherte. Als das System versuchte, zwischen verschiedenen Tabs in der Software zu wechseln, war der Unterschied zwischen dem Suchen eines Tabs und dem Klicken auf eine zwischengespeicherte Position eklatant. Das Finden eines Tabs durch die Standardmethode dauerte zwischen neunundzwanzig und siebenundfünfzig Sekunden – ein Prozess, der jedes Mal die Suche durch die interne Struktur der Anwendung beinhaltete. Soblich die Position jedoch zwischengespeichert war, dauerte der Wechsel zu demselben Tab weniger als ein Drittel einer Sekunde. Dies demonstrierte, dass es in einer stabilen Umgebung weitaus effizienter ist, sich zu merken, wo Dinge sind, als sie jedes Mal neu zu suchen.

Die Anpassungsfähigkeit des Systems war jedoch fragil. Die zwischengespeicherten Positionen waren fest an die exakte Größe und Form des Fensters gebunden, die zum Zeitpunkt der Kartenerstellung vorlagen. Wenn sich die Fenstergröße änderte oder wenn die Bildschirmauflösung anders war, zeigten die zwischengespeicherten Koordinaten auf den falschen Ort, und das System scheiterte. Der Forscher stellte fest, dass das System nicht in der Lage war, sich selbst zu reparieren; wenn sich das Layout verschob, musste die gesamte Karte von Grund auf neu erstellt werden. Darüber hinaus prüfte das System nicht, ob seine Klicks tatsächlich funktionierten. Es meldete Erfolg, selbst wenn die Anwendung nicht reagierte, da es keine Möglichkeit hatte, das Ergebnis zu verifizieren, ohne den Bildschirm erneut zu scannen, was den Zweck des Caching zunichtemachen würde.

Der Verifizierungsteil des Systems, der prüfte, ob der Entwurf mit der Zeichnung übereinstimmte, funktionierte theoretisch gut, stieß jedoch in der Praxis auf Hürden. Das System wurde mit fünfhundert synthetischen Fällen getestet, bei denen absichtlich Fehler in die Daten injiziert wurden. In diesen Tests identifizierte der Code jeden beabsichtigten Fehler, wie etwa fehlende Schränke oder falsche Gerätetypen, korrekt und löste niemals einen Fehlalarm aus. Es lehnte Entwürfe, die nicht den Anforderungen entsprachen, erfolgreich ab. Dennoch, als das System mit realen, unskripteten Versuchen zum Bau von Schränken getestet wurde, waren die Ergebnisse weniger eindeutig. Fünf aufgezeichnete Versuche, einen vollständigen Entwurf zu bauen, scheiterten in einem frühen Stadium und stoppten, bevor das Endprodukt verifiziert werden konnte. Die Protokolle zeigten, dass das System die Schränke, die es bauen sollte, nicht korrekt zählen konnte, was zu einem sofortigen Abbruch führte. Der Forscher merkte an, dass das System nicht mit einer großen Vielfalt an realen Zeichnungen getestet worden war und die wenigen aufgezeichneten realen Versuche unvollständig waren.

Die Studie hob auch die Rolle der künstlichen Intelligenz in diesem Prozess hervor. Das System nutzte ein KI-Modell, um die Entwurfszeichnungen zu interpretieren, aber die endgültige Entscheidung darüber, ob der Bau erfolgreich war, wurde dem Code überlassen. Diese Trennung war beabsichtigt; der Code fungierte als strenger Torwächter, der sicherstellte, dass die Interpretation der KI gegen harte Regeln geprüft wurde. Der Forscher fand heraus, dass die KI zwar die Zeichnungen beschreiben konnte, man ihr jedoch nicht zutraute, das Ergebnis eigenständig zu beurteilen. Das System war so konzipiert, dass der Code einen Fehler der KI abfangen würde, falls dieser auftrat. Die Aufzeichnungen zeigten jedoch, dass das System in den wenigen realen Versuchen bereits fehlschlug, bevor es überhaupt die Phase erreichte, in der die Beschreibung der KI mit dem Endergebnis verglichen werden konnte.

Letztendlich zeichnet diese Arbeit ein klares Bild davon, was möglich ist, wenn man Software automatisiert, die sich weigert, direkt mit Maschinen zu sprechen. Der Ansatz, die Benutzeroberfläche einmal abzubilden und dann auf diesen Erinnerungen zu agieren, ist schnell und effektiv, aber er ist brüchig. Er funktioniert nur, solange die Software exakt so aussieht wie zum Zeitpunkt der Kartenerstellung. Das System bewies, dass durch Code erzwungene Prüfungen Ergebnisse zuverlässig verifizieren können, zeigte aber auch, dass die Automatisierung ohne eine robuste Methode zur Handhabung von Änderungen in der Schnittstelle oder zur Fehlerbehebung noch nicht in der Lage ist, einen Menschen in einer dynamischen Umgebung zu ersetzen. Der Forscher kam zu dem Schluss, dass die Methode zwar für eine spezifische Version der Software auf einer spezifischen Maschine funktioniert, aber keine allgemeine Lösung für alle Anwendungen darstellt. Das System bleibt ein Proof of Concept, das demonstriert, dass Automatisierung auch ohne direkten Zugriff möglich ist, aber es unterstreicht auch die Schwierigkeit, solche Systeme robust genug für die reale Welt zu machen.